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

27

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

Теперь на сервере возникают проблемы с использованием osm2pgsqlдля импорта снимка ... После нескольких попыток с различными конфигами памяти и еще чем-то, процесс продолжает выводить "Killed" после прохождения большей части пути; как только он был убит во время «прохождения отложенных путей», а в следующий раз, после небольшой настройки тонкого кэша, он достиг «путей обработки» перед тем, как выйти из строя. Из того, что я прочитал, это, как правило, из-за проблем с памятью.

Вот моя последняя попытка запустить импорт:

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 прошлого года, но есть ли другие хорошие мнения / ресурсы?

postgis openstreetmap postgresql mapnik optimization colemanm
источник
Разве не было бы очень дорого делать это на EC2?
Пабло
Не дешево поддерживать его работу, но промежуточный план состоит в том, чтобы ускорить его, сгенерировать набор тайлов, затем закрыть его и использовать этот набор на некоторое время, пока нам не понадобятся обновления. Это все еще намного дешевле, чем покупка огромного сервера ...
Colemanm
1
Интересный! Я никогда не пробовал это на моей старой XP-Home-Box. Это действительно работает? Я спрашиваю, потому что он был написан для преобразования выдержек из Geofabrik или Cloudmade не для всей планеты. Планета, кажется, неверный XML. Как вы решили эту проблему?
@Carsten При переносе вашего ответа в форму комментария я случайно удалил комментарий @jvangeld. Вот оно: Привет Карстен, добро пожаловать на GIS.se. Это замечательно, когда разработчики приходят сюда, чтобы помочь людям с их программами. Но ваш ответ здесь, вероятно, был бы лучше как комментарий к посту @ winwaed. Опять же, здорово, что ты здесь!
whuber

Ответы:

8

Как сказано в документации , для этого может потребоваться более 256 ГБ оперативной памяти.

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

Есть интересный пост: http://weait.com/content/build-your-own-openstreetmap-server Там написано: «Вы должны использовать режим Slim».

Pablo
источник
Да, я также понимаю, что для обновления требуется тонкий режим.
Коулманм
4

Из-за ограничений памяти я даже не пытался использовать osm2pgsql для загрузки данных маршрутизации planet.osm. Вместо этого я использовал osm2po:

http://osm2po.de/

Большая часть документации на немецком языке, но с небольшим количеством экспериментов мне удалось заставить это работать. Занимает несколько дней на выделенном Core 2 Quad (но он использует только один поток).

winwaed
источник
2

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

Ян Тертон
источник
Это может определенно сработать прямо сейчас, хотя это с 2009 года ...
Colemanm
2

Вы получили решение для вашей проблемы, кроме использования старого предварительно сгенерированного пакета? Кажется, у меня очень похожая проблема в 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 раза быстрее, чем в худом режиме). Так было бы на самом деле дешевле.

JaakL
источник
1

Я получил osm2pgsql для работы на EC2, используя меньше процессоров и больше оперативной памяти. Это не удалось из-за проблем с памятью, пока я не увеличил экземпляр до очень большого объема памяти с 17 гигабайтами оперативной памяти.

datdo
источник