Actualización de la base de datos mediante osmosis y osm2pgsql demasiado lenta

Question

Tengo una caja con la configuración de hardware actual:

CPU: Intel Xeon E3-1220 V2 3.1 GHz
RAM: 10gb
Hard Disk: Western Digital WD10EZRX SATA Hard Drive

OS: Centos 6.5 64 bit
DB: PostgreSQL 9.3.2

y PostgreSQL tiene la siguiente configuración

shared_buffers = 1024MB
work_mem = 256MB
maintenance_work_mem = 4096MB
fsync = off
synchronous_commit = off
checkpoint_segments = 100

He importado todos los datos de OSM Europe a la base de datos PGSQL con el siguiente comando:

osm2pgsql -c -d gps -U gps --cache 8000 --number-processes 4 --slim europe-latest.osm.bz2

y tardó 6 días en completarse... es mucho pero está bien...

ahora quiero mantener mi base de datos actualizada con el combo de osmosis + osm2pgsql cmds:

osmosis --read-replication-interval workingDirectory=/osmosisworkingdir/ --simplify-change --write-xml-change - | \
osm2pgsql --append -d gps -U gps --cache 8000 --number-processes 4 -s -

Bueno... ¡esto lleva más de un día para alinear los cambios de un solo día! ¡Eso hace imposible mantener mi DB local alineada!

¿Estoy haciendo algo mal? ¿Debo actualizar mi memoria RAM? ¿Por qué la actualización es TANTO más pesada que cargar los datos por primera vez?

Answer 1

Hay algunos problemas.

El primero es el hardware. Su unidad es una unidad WD Green, que es generalmente es alrededor de 5400 RPM que es un muy unidad lenta, más lenta que las típicas unidades de consumo de 7200 RPM.

Una de las tareas más importantes de la actualización es la obtención de las posiciones de los nodos. Se trata de un acceso aleatorio, en el que tu disco es pésimo.

Una opción es utilizar el --flat-nodes que utilizará un archivo binario de 20 GB para almacenar las ubicaciones de los nodos en lugar de una tabla en la base de datos. Esto puede suponer un aumento significativo del rendimiento en los discos duros, ya que se basa más en el acceso secuencial que en las tablas de la base de datos.

No necesitas ni te beneficias de que 8000MB de memoria se utilicen para la caché del nodo cuando se actualiza. 1000 es probablemente suficiente. Esto, dependiendo de la configuración de sobrecompromiso, permitirá que se utilice más memoria para el almacenamiento en caché del contenido de la base de datos.

Su PostgreSQL work_mem y maintenance_work_mem son demasiado altos para una máquina con 10GB. Probablemente me decantaría por work_mem = 64MB y maintenance_work_mem = 1024MB e incluso eso podría ser alto.

No has dicho de dónde has sacado europe-latest.osm.bz2, pero supongo que es un extracto de Geofabrik. Si es así, se hacen difusiones diarias que permiten actualizar la base de datos sólo con los datos de Europa. Para hacer esto, necesitarías editar el archivo osmosis configuration.txt para cambiar baseUrl a baseUrl=http://download.geofabrik.de/europe-updates . También tendría que editar state.txt con el número de secuencia correcto, que puede encontrar mirando las fechas en http://download.geofabrik.de/europe-updates/000/000/ . Una vez que encuentre el archivo de estado adecuado, puede descargarlo, por ejemplo, con curl -o /osmosisworkingdir/state.txt http://download.geofabrik.de/europe-updates/000/000/416.state.txt .

El cambio a los diffs diarios de geofabrik debería reducir la cantidad de datos que se añaden.

Por último, ya que tienes que reimportar para --flat-nodes, debes asegurarte de descargar un nuevo extracto de Europa, y asegurarte de descargar PBF, no XML bzipped.

Su nuevo comando de importación debería ser algo así como

osm2pgsql -c -d gps -U gps --cache 8000 --number-processes 4 --slim \ --flat-nodes europe_nodes.bin europe-latest.osm.pbf

Su comando de actualización sería algo así como

osmosis --read-replication-interval workingDirectory=/osmosisworkingdir/ \ --simplify-change --write-xml-change - | \ osm2pgsql --append -d gps -U gps --cache 1000 --number-processes 4 --slim \ --flat-nodes europe_nodes.bin -

Por supuesto, el mayor aumento de velocidad posible es probablemente el de utilizar un área más pequeña que toda Europa.

Incluso con todo esto, renderizar azulejos de una unidad de 5400RPM nunca va a ser rápido.

Answer 2

Sin optimizar su cadena de herramientas está perdido. Echa un vistazo aquí:

http://www.geofabrik.de/media/2012-09-08-osm2pgsql-performance.pdf

para algunos detalles. No se trata sólo de la RAM, SSD en lugar de discos duros SATA puede acelerar mucho también.

Answer 3

Para añadir:

• utilizar la última versión de Postgres (ahora 11). Postgres tiene mejoras de rendimiento con cada versión.

• Por favor, mantenga fsync=on. synchronuous_commit=off da el mismo aumento de rendimiento, pero fsync=off hace que su DB no sea tolerante a fallos.