Optymalizacja importu osm2pgsql dla danych OSM

Obecnie buduję instancję na EC2, na której można zaimportować całą migawkę Planet.osm danych z całej Ziemi dla niektórych projektów, nad którymi pracujemy. Rozwinąłem dużą instancję Ubuntu x64 i dołączyłem mnóstwo osobnego miejsca do przechowywania na wolumenie EBS dla bazy danych Postgres i zmodyfikowałem go, aby przechowywać tam dane PGSQL.

Teraz serwer ma problem osm2pgsqlz importowaniem migawki ... Po kilku próbach z różnymi konfiguracjami pamięci i tak dalej, proces nadal wyświetla komunikat „Zabity” po przejściu przez większość czasu; raz został zabity podczas „przechodzenia przez oczekujące sposoby”, a następnym razem, po nieznacznym dostosowaniu wąskiej pamięci podręcznej, osiągnął „sposoby przetwarzania” przed wypadnięciem. Z tego, co przeczytałem, wynika to ogólnie z problemów z pamięcią.

Oto moja ostatnia próba uruchomienia importu:

osm2pgsql -v -U osm -s -C 4096 -S default.style -d osm /data/osm/planet-latest.osm.bz2

A oto specyfikacje dużej instancji w EC2:

Duża instancja 7,5 GB pamięci, 4 jednostki obliczeniowe EC2 (2 rdzenie wirtualne z 2 jednostkami obliczeniowymi EC2 każda), 850 GB pamięci instancji lokalnej, platforma 64-bitowa

Moje pytanie brzmi - czy są jakieś dobre zasoby testowe do określenia wymagań dostrajania dla osm2pgsql i Postgres? Szybkość importu nie jest nawet dla mnie tak ważna, chciałbym być w stanie upewnić się, że proces zakończy się bezpiecznie, nawet jeśli zajmie to 4 lub 5 dni ... Przeczytałem „ Optymalizację renderowania ” Fredericka Ramma łańcuch ”(PDF) z zeszłorocznego SOTM, ale czy są jeszcze inne dobre opinie / zasoby?

Jak wynika z dokumentacji , może to wymagać więcej niż 256 GB pamięci RAM.

Nie wiem dużo o EC2, ale możesz wypróbować tryb slim (--slim) lub Osmosis .

Jest ciekawy post: http://weait.com/content/build-your-own-openstreetmap-server Mówi: „musisz używać trybu slim”.

Z powodu ograniczeń pamięci nawet nie próbowałem użyć osm2pgsql do załadowania danych routingu planet.osm. Zamiast tego użyłem osm2po:

http://osm2po.de/

Większość dokumentacji jest w języku niemieckim, ale przy odrobinie eksperymentów udało mi się ją uruchomić. Trwa kilka dni na dedykowanym Quad 2 Core (ale używa tylko jednego wątku).

Natknąłem się na następujące, szukając czegoś innego http://aws.amazon.com/datasets/2844 - Nie jestem pewien, czy to ci pomoże, czy nie, ale może to być punkt wyjścia.

Czy masz rozwiązanie innego problemu niż użycie starego, wstępnie wygenerowanego pakietu? Wydaje mi się, że mam bardzo podobny problem w instancji EC2. Używam planety PBF z http://download.bbbike.org/osm/

time ./osm2pgsql -S default.style --slim -d gis -C 7000 --hstore /mnt/planet/planet-latest.osm.pbf
osm2pgsql SVN version 0.70.5
...(creating db tables)
Reading in file: /mnt/planet/planet-latest.osm.pbf
Processing: Node(741920k) Way(0k) Relation(0)Killed

real    276m47.695s

Aktualizacja: wydaje się, że znalazłem rozwiązanie - po zmniejszeniu zadanej pamięci do 6 GB (parametr -C 6000) proces działa (przynajmniej pracował już kilka dni, mam nadzieję, że zakończy się dzisiaj).

Wydaje się, że instancja m1.large z pamięcią 7,5 GB jest nieco za mała, aby zmieścić wszystkie węzły w pamięci (co obecnie powinno wymagać około 11 GB). Osm2pgsql wydaje się wymagać mniej niż 700 MB dodatkowego do wymaganej pamięci, więc w przypadku -C 7000 brakuje mu pamięci, ale w przypadku -C 6000 (lub ewentualnie również -C 6500) działa.

Sugeruję również użycie wyższej instancji pamięci z co najmniej 15 GB pamięci RAM, powinno to znacznie przyspieszyć import. Lub nawet podwójną bardzo dużą instancję pamięci, która kosztowałaby podwójnie, ale powinna być w stanie wykonać pełny import planet w trybie innym niż slim w ciągu <5 godzin (około 3-4 razy szybciej niż w trybie slim). Tak byłoby faktycznie taniej.

Mam osm2pgsql do pracy na EC2 przy użyciu mniejszej mocy procesora i więcej pamięci RAM. Nie udało się to z powodu problemów z pamięcią, dopóki nie podniosłem instancji do bardzo dużej pamięci z 17 gigawatami pamięci RAM.