Demasiada E / S generada por el proceso de recopilación de estadísticas de Postgres

10

Estoy usando XenServer con varias máquinas virtuales que tienen bases de datos locales de postgres. Incluso cuando no se utilizan todas las aplicaciones y las bases de datos están inactivas, cada vm provoca un tráfico de red de almacenamiento constante que degrada el rendimiento del dispositivo de almacenamiento iscsi.

Después de ejecutar iotop, noté que el proceso del proceso de recopilación de estadísticas de postgres está escribiendo constantemente en el disco a una velocidad de aproximadamente 2 MByte / s.

Luego deshabilité la recopilación de estadísticas editando /etc/postgresql/8.4/main/postgresql.conf:

#------------------------------------------------------------------------------
# RUNTIME STATISTICS
#------------------------------------------------------------------------------

# - Query/Index Statistics Collector -

track_activities = off
track_counts = off
...

como se sugiere en http://www.postgresql.org/docs/8.4/static/runtime-config-statistics.htm .

Esto eliminó la escritura continua, pero ¿hay alguna desventaja al desactivar el seguimiento de estadísticas?

¿O debería colocar el directorio pg_stat_tmp en un disco ram para evitar el tráfico del disco / red?

El sistema es un Debian 6.0.7 actualizado (compresión) con postgres 8.4 y aproximadamente 20 bases de datos con aproximadamente 50 tablas, el tamaño total del archivo de volcado es inferior a 100 MByte.

— nn4l
fuente

7

Como la actualización de PostgreSQL no es una opción, he intentado colocar el directorio pg_stat_tmp en un sistema de archivos tmpfs, lo que produjo una mejora significativa en el rendimiento. Ahora estoy ejecutando esto en unas pocas docenas de sistemas durante un par de meses sin inconvenientes notables.

Para hacer esto, simplemente monte pg_stat_tmp con tmpfs en su archivo / etc / fstab:

# <file system> <mount point>                                <type>  <options>  <dump>  <pass>
tmpfs           /var/lib/postgresql/8.4/main/pg_stat_tmp     tmpfs   defaults,noatime,mode=1777,uid=postgres,gid=postgres,nosuid,nodev 0 0

— nn4l
fuente

Hice esto para Postgresql 9.1. Uno de mis servidores tenía una escritura continua de 1 MB / s durante todo el día. Esto lo hizo caer a casi nada. Está aprobado por los documentos , por cierto: "... Señalar esto en un sistema de archivos basado en RAM disminuirá los requisitos físicos de E / S y puede mejorar el rendimiento"

— Halfgaar

0

Actualice PostgreSQL. Como mínimo absoluto, asegúrese de estar en la última versión 8.4; si eso no lo soluciona y es práctico hacerlo, probablemente debería actualizar a 9.2. Al menos algunos problemas relacionados con el recopilador de estadísticas se han abordado desde 8.4 y llegarán al final de su vida útil en aproximadamente un año . Puede encontrar más información buscando en los archivos de la lista de correo pgsql-general .

No debería tener demasiados problemas para actualizar de 8.4 a 9.2, aunque, como de costumbre, debe leer la sección de actualización de las notas de la versión para cada versión .0 entre (9.0, 9.1 y 9.2). Presta especial atención a standard_conforming_stringsy bytea_output.

— Craig Ringer
fuente

0

El mismo problema aqui. También deshabilité track_*y así sucesivamente.

El efecto secundario es que autovacuumestá utilizando estos datos recopilados para iniciar.

Entonces, me encargo de programar todas las noches a vacuumdb.

Otra solución es establecer lo autovacuum_naptimesuficientemente alto como para tener el sistema en reposo.

— Gelma
fuente