Оптимізація імпорту osm2pgsql для даних OSM

Наразі я будую екземпляр на EC2, за допомогою якого можна імпортувати весь знімок на Planet.osm даних про цінність Землі для деяких проектів, над якими ми працюємо. Я запустив великий екземпляр Ubuntu x64 і додав багато окремого сховища в томі EBS для бази даних Postgres і змінив його для розміщення даних PGSQL там.

Тепер сервер має проблеми osm2pgsqlз імпортом знімка ... Після декількох спроб з різними конфігураціями пам'яті та що-небудь ще, процес продовжує виводити "Убитий" після проходження більшої частини шляху; одного разу він був убитий під час "переходу на очікувані шляхи", і наступного разу, трохи відрегулювавши тонкий кеш, він досяг "способів обробки" перед тим, як вийти з ладу. З того, що я читав, це, як правило, пов’язано з проблемами пам'яті.

Ось моя остання спроба запустити імпорт:

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

Ось специфікації для великого екземпляра на EC2:

Великий екземпляр 7,5 Гб оперативної пам’яті, 4 обчислювальні блоки EC2 (2 віртуальних ядра з 2 обчислювальними блоками EC2), 850 ГБ локального сховища, 64-розрядна платформа

Моє запитання - чи існують якісь хороші орієнтири для визначення вимог до настройки для osm2pgsql та Postgres? Швидкість імпорту для мене навіть не така важлива, я просто хотів би переконатися, що процес закінчується безпечно, навіть якщо це займе 4 або 5 днів ... Я читав " Оптимізація візуалізації " Фредеріка Рамма ланцюжок "(PDF) документа з минулорічного SOTM, але чи є інші хороші думки / ресурси?

Як свідчить документація , для цього вам може знадобитися більше 256 Гб оперативної пам’яті.

Я мало знаю про EC2, але ви можете спробувати тонкий (- тонкий) режим або спробувати Osmosis .

Є цікава публікація: http://weait.com/content/build-your-own-openstreetmap-server У ній написано: "Ви повинні використовувати режим тонкого струму".

Через обмеження пам’яті я навіть не намагався використовувати osm2pgsql для завантаження маршрутизаційних даних planet.osm. Натомість я використав osm2po:

http://osm2po.de/

Більшість документації є німецькою мовою, але, трохи експериментуючи, мені вдалося змусити її працювати. Займає кілька днів на спеціальному Core 2 Quad (але він використовує лише одну нитку).

Я натрапив на таке, шукаючи щось інше http://aws.amazon.com/datasets/2844 - я не впевнений, допоможе вам це чи ні, але це може бути відправною точкою.

Ви отримали рішення для своєї проблеми, окрім використання старого попередньо створеного пакету? У мене, схоже, дуже схоже питання в екземплярі EC2. Я використовую планету pbf з 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

Оновлення: схоже, я знайшов рішення - після зменшення запитуваної пам’яті до 6 ГБ (параметр -C 6000) процес працює (принаймні, працював уже кілька днів, завершу сьогодні, я сподіваюся).

Здається, що екземпляр m1.large із 7,5 ГБ пам’яті трохи замалий, щоб вмістити всі вузли в пам’ять (на що зараз потрібно близько 11 ГБ). Схоже, що для osm2pgsql потрібно менше 700 Мб додаткової необхідної пам’яті, тому з -C 7000 у нього не вистачає пам’яті, але з -C 6000 (або, можливо, також -C 6500) він працює.

Також я б запропонував використовувати більш високий екземпляр пам'яті, принаймні 15 Гб оперативної пам’яті, це повинно зробити імпорт набагато швидшим. Або навіть подвоїти надзвичайно великий екземпляр пам’яті, який коштуватиме вдвічі, але повинен бути в змозі здійснити повний імпорт планети в нетонкому режимі протягом <5 годин (приблизно в 3-4 рази швидше, ніж у тонкому режимі). Так було б насправді дешевше.

Я отримав osm2pgsql для роботи на EC2, використовуючи менше процесора та більше оперативної пам’яті. Це не вдалося через проблеми з пам'яттю, поки я не збільшив екземпляр до великої пам’яті великої пам’яті з 17 гігами оперативної пам’яті.