Сколько дней ждать osm2pgsql ?

[IlVin]

Здравствуйте, гуру!
В качестве хобби решил заняться картографией.
Первый этап [Скачать Planet OSM] преодолел за 5 часов.
А вот на втором этапе [Загнать Planet OSM в Postgres] завис

Скажите пожалуйста сколько в свежей Planet OSM точек, полилиний и областей - по этим данным я будут рассчитывать количество лет работы osm2pgsql (Бенчмарки в вике я читал, но они для старой Planet OSM)

Из оборудования: 4 ядра, 4 гига памяти, SATA жесткий диск.
1,2 млрд точек загнал в БД со скростью 70 к/s
А вот полилинии показывают удручающую производительность в 0.15 k/s - за 2-е суток посчиталось всего 30 000 k.

К покупке SSD я уже созрел, но вот вопрос - какой емкости покупать сей недешевый девайс?
БД в текущий момент занимает 90 гигабайт, но она не полная.
Каков объем БД с полной Planet OSM?

С почтением,
Илья Винокуров.

[Aleksandr Dezhin]

30 млн. линий - это четверть от их общего количества, то есть на веи еще 8 дней у вас уйдет, но вообще 0.15 k/s это очень мало, у нас получается около 2 к/s на обрезанном дампе, если я ничего не путаю, скорее всего действительно диск виноват, ну и памяти маловато.

Вообще лучше у Komzpa в IRC спросить, у него по идее под рукой база должна быть.

[IlVin]

То, что диск виноват - к гадалке не ходи: ядра курят.
Максимальная загрузка ядер - 5..15 процентов, а диск стрекочет так, что страшно к компьютеру подойти...
Дамп не обрезанный.
Памяти мало, но в мой домашний десктоп большее количество уже не воткнешь - заняты все 4 слота.
Выход вижу в покупке SSD.

[IlVin]

Немного расскажу как я ускорил обработку планеты.
Так как мой GIS проект из разряда "хобби", на которое бюджет не предусмотрен, я столкнулся с жесткой нехваткой средств.
При выборе что купить - или 8 гигов ОЗУ (у меня только 4 и занимают все слоты) или быстрый SSD чаша весов склонилась в сторону SSD - дешевле.
Денег хватило только на бу-шный 80Гб SSD 320 серии...
Инсталляция прошла успешно И я стал осваивать ZFS.
На удивление рулежка ZFS легка и приятна!

А теперь немного сухой конфигурации:
PC: Core2Duo 6600
RAM: 4Gb
SSD: 80Gb
OS: FreeBSD-Amd (Это кодовое обозначение x64)

Тюним:
1) /boot/loader.conf

Код: Выделить всё

# PostgreSQL
kern.ipc.semmns="1024"
kern.ipc.semmni="256"

# ZFS
aio_load="yes"
vm.kmem_size="512M"
vm.kmem_size_max="512M"
vfs.zfs.arc_max="64M"
vfs.zfs.vdev.cache.size="5M"

vfs.zfs.prefetch_disable="1"
vfs.zfs.txg.timeout="5"

2) /etc/sysctl.conf

Код: Выделить всё

# shared memory
kern.ipc.shm_use_phys=1
kern.ipc.shmall=393216
kern.ipc.shmmax=1610612737

3) Тюним ZFS:

Код: Выделить всё

zpool create DB /dev/SSD
zfs create DB/pgsql
zfs set compression=on DB/pgsql
zfs set atime=off DB/pgsql

4) Тюним Postgres (postgresql.conf)

Код: Выделить всё

shared_buffers = 1024MB
work_mem = 128MB
maintenance_work_mem = 256MB
fsync = off
synchronous_commit = off
wal_sync_method = fsync
checkpoint_segments = 16
silent_mode = on
autovacuum = off

xlog базы данных вынес на отдельный диск и сделал симлинк

5) PostGIS 1.5
6) bzcat /home/PlanetOSM/planet-110928.osm.bz2 | osm2pgsql -d gis -U gis -m -s -H localhost /dev/stdin

После суток работы этой адской строки наблюдаю ситуацию:
Processing: Node(1217841k 85.1k/s) Way(72509k 1.30k/s) Relation(0 0.00/s)

Не зря я сделал компрессионный раздел - БД сейчас занимает 105 гигабайт в FS и 54 гигабайта на SSD. Еще доступно 22 гигабайта SSD (примерно 40 гигабайт FS).

Что было не дотюнено:
По умолчанию размер блока в ZFS получился 128 килобайт. Это много для БД с большим количеством рандомных выборок малого размера. Думаю, что результат был бы лучшим, если бы я задал размер блока в пределах 32 килобайт.

Ну и как всегда: Процессор курит! idle 50..60 процентов.
iostat на SSD показывает 600..900 tps и 30..50 Мб/с

С почтением,
Илья Винокуров.

[Максим Дубинин]

интересно, у нас тоже freebsd, ssd и т.д.

на сколько ускорилось таки? с 0.15к/с до 1.30?

[IlVin]

Сейчас веи закончились:
Processing: Node(1217841k 85.1k/s) Way(109718k 1.50k/s) Relation(253440 16.91/s)
Производительность по веям увеличилась в 10 раз (да и по iostat примерно столько же выходит).

Вопрос - сколько Relation?
Судя по отчетам в бенчмарках к osm2pgsql, их должно быть - 1180000.
Т.е. посчитаются за 20 часов...

Итого может быть 44 часа на все.
За такое время в бенчмарках серверы с 16 гигами памяти планету считали, причем у них планета прошлогодняя - в 2 раза меньшая... А система с 16 гигами ого-го-го как стоит (мать десктопная не потянет столько) по сравнению с SSD. А кто-то жалуется, что SSD дорогие...

Итак, делаем вывод: Для планеты нужен SSD и минимум 4Gb памяти (2 гига для osm2pgsql и 2 для всего остального).
А база, между тем, до 120 гигов раздулась. А у меня осталось всего 14 гигов на SSD ~ 28 гигов в FS...

Ссылка: http://wiki.openstreetmap.org/wiki/Osm2pgsql/benchmarks

[IlVin]

Processing: Node(1217841k 85.1k/s) Way(109718k 1.50k/s) Relation(1114739 27.37/s) parse time: 128429s

Node stats: total(1217841367), max(1447570595) in 14304s
Way stats: total(109718429), max(131557810) in 73235s
Relation stats: total(1114739), max(1767603) in 40733s

[IlVin]

И после этих строк у меня получился облом
Не хватило места на моем бюджетном SSD...

Но дурная голова рукам покоя не дает - почитав мануал zpool, обнаружил интересную штуку - добавление к пулу кэширующих девайсов!
zpool add DB cache /dev/adXX
Организовал пул на 500 гиговом HDD и добавил в качестве кэширующего 80 гиглвый SSD. Посмотрим, что получится

[IlVin]

Добавление кэширующего девайса ничего не дало - Начальная скорость рассчета вэев 0.09 к/с.
Вероятно нет попадания в кэш.
Сделал такой пул:
zpool create -O compression=gzip-2 -O recordsize=16K -O atime=off DB /dev/ad16

На данный момент compressratio = 3.50
Включил автовакуум - место на диске очень дефицитно - может в процессе работы он чего-нибудь насобирает...

Есть еще мысль добавить в пул обычный диск, когда места будет не хватать...

[IlVin]

Последняя настройка zfs показала следующие результаты:
compressratio 2.77x

Processing: Node(1217841k 72.8k/s) Way(109718k 1.90k/s) Relation(1114739 35.43/s) parse time: 105978s

Node stats: total(1217841367), max(1447570595) in 16721s
Way stats: total(109718429), max(131557810) in 57639s
Relation stats: total(1114739), max(1767603) in 31461s

Going over pending ways
processing way (4356k) at 0.56k/s

recordsize делать меньше 16K не имеет смысла, т.к. из-за этого страдает степень сжатия, но и 16K мне кажется слишком маленьким размером, так как tps вырос в 2 раза, но при этом пропускная способность увеличилась только в 1,5 раза. Думаю, что recordsize = 32K будет оптимальным для данной задачи.

Так же степень сжатия gzip стоит увеличить до 4, так как при 2, процессор тратит на компрессию/декомпрессию в среднем 15..20%, при этом idle 50..60%

На данный момент на SSD свободно 28Gb, автовакуум включен. Если опять места не хватит, буду испытывать такую настройку zfs:

zpool create -O compression=gzip-4 -O recordsize=32K -O atime=off DB /dev/ad16

Добавлять HDD в пул не буду - интересно хватит ли места на SSD

[Aleksandr Dezhin]

Включил автовакуум - место на диске очень дефицитно - может в процессе работы он чего-нибудь насобирает...

Не насобирает, т.к. первоначальная загрузка никаких значение не изменяет, а только вставляет новые записи в свежесозданные таблицы.

[Aleksandr Dezhin]

Так же степень сжатия gzip стоит увеличить до 4, так как при 2, процессор тратит на компрессию/декомпрессию в среднем 15..20%, при этом idle 50..60%

А с точки зрения загруженности конкретных ядер что получается? У нас на сервере сейчас база с б-СССР на двух SSD в RAID-0 работает, при загрузке все равно больше 2-3 ядер она не нагружает, хотя тут я могу что-то путать.

[IlVin]

На моем домашнем сервере установлен Core2Duo 6600. Все 2 ядра полностью загружаются только при парсинге точек.
Сейчас считаются Relation

Код: Выделить всё

last pid: 52750;  load averages:  0.47,  0.51,  0.54                      up 8+09:20:03  09:54:47
50 processes:  2 running, 48 sleeping
CPU: 13.5% user,  0.0% nice, 14.8% system,  1.3% interrupt, 70.4% idle
Mem: 904M Active, 613M Inact, 677M Wired, 110M Cache, 367M Buf, 80M Free
Swap: 36G Total, 28M Used, 36G Free

  PID USERNAME   THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
46917 pgsql        1  48    0  1080M  1060M sbwait  1 281:52  7.47% postgres
46911 root         1  47    0  1875M   843M select  1 351:32  5.37% osm2pgsql
46918 pgsql        1  45    0  1082M  1062M sbwait  0  34:41  2.88% postgres
46915 pgsql        1  45    0  1097M   524M CPU1    0   2:30  2.49% postgres
46914 pgsql        1  45    0  1095M  1067M sbwait  1  41:27  0.98% postgres
46916 pgsql        1  44    0  1095M  1061M sbwait  1   7:13  0.20% postgres

Код: Выделить всё

# iostat -d ad16 1
            ad16
  KB/t tps  MB/s
 29.18 538 15.34
 24.12 1284 30.23
 15.01 500  7.34
 14.55 397  5.64
 27.96 810 22.12
 24.32 1203 28.57
 24.28 1166 27.65
 24.73 1143 27.60
 21.04 1421 29.20
 25.38 966 23.95
 25.96 1296 32.86
 23.91 1158 27.03
 25.93 1341 33.96
 21.51 1448 30.42
 22.05 1230 26.48
 21.11 553 11.41

Идея с увеличением recordsize до 32K и компрессии до 4 оказалась ошибочной - производительность чуть снизилась.

Проблема в другом - предыдущий расчет не завершился из-за нехватки свопа [4GB]- система отстрелила постгрес из-за этого и я так и не понял кому потребовалось много памяти на этапе после

Код: Выделить всё

Going over pending ways
processing way (12179k)

Запустил процесс сначала и увеличил своп до 36GB - хоть посмотрю кто страдает прожорливостью...

Есть еще одна безумная идея - отдать SSD под своп и увеличить shared_buffers до 60GB.

[bim2010]

Я пробовал выполнять парсинг OSM без использования osm2pgsql.
Писал на visual studio. Эмпирически нашел оптимальный для MS VS размер файла для обработки - 600 -650 MB.
Нарезал дамп на куски и обработал их последовательно.
Успеха!

[IlVin]

При обработке planet-111130.osm.bz2 появились 2 исключения

Код: Выделить всё

Standard exception processing way_id 1082366: TopologyException: side location conflict at 822832 8.30585e+06
Standard exception processing way_id 1792031: TopologyException: side location conflict at -734926 5.24355e+06

Это смертельно?