Problemas de rendimiento de Postgres

Question

Estamos ejecutando Postgres 9.1.3 y recientemente hemos comenzado a tener problemas de rendimiento en uno de nuestros servidores.

Nuestras consultas corrieron bien por un tiempo, pero a partir del 1 de agosto, se han reducido drásticamente. Parece que la mayoría de las consultas problemáticas son consultas Select (las consultas con count (*) son especialmente malas), pero en general, la base de datos se está ejecutando muy lento.

Corrimos this consulta en el servidor y estos fueron los cambios que hemos realizado en el archivo de configuración por defecto (Nota: El servidor funcionó muy bien con estos cambios antes, por lo que, es probable que no importan mucho):

 name   |            current_setting 
---------------------------+--------------------------------------------------------------------------------------------------------------- 
version     | PostgreSQL 9.1.2 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51), 64-bit 
autovacuum    | off 
bgwriter_delay   | 20ms 
checkpoint_segments  | 6 
checkpoint_warning  | 0 
client_encoding   | UTF8 
default_statistics_target | 1000 
effective_cache_size  | 4778MB 
effective_io_concurrency | 2 
fsync      | off 
full_page_writes   | off 
lc_collate    | en_US.UTF-8 
lc_ctype     | en_US.UTF-8 
listen_addresses   | * 
maintenance_work_mem  | 1GB 
max_connections   | 100 
max_stack_depth   | 2MB 
port      | 5432 
random_page_cost   | 2 
server_encoding   | UTF8 
shared_buffers   | 1792MB 
synchronous_commit  | off 
temp_buffers    | 16MB 
TimeZone     | US/Eastern 
wal_buffers    | 16MB 
wal_level     | minimal 
wal_writer_delay   | 10ms 
work_mem     | 16MB 
(28 rows) 

Time: 210.231 ms 

Normalmente, cuando surgen problemas como este, lo primero que la gente recomienda es aspirar y lo hemos intentado. Analizamos al vacío la mayor parte de la base de datos, pero no ayudó.

Utilizamos Explain en algunas de nuestras consultas y notamos que Postgres recurría a escaneos secuenciales aunque las tablas tenían índices.

Desactivamos el análisis secuencial para forzar al planificador de consultas a usar índices, pero tampoco ayudó.

Luego probamos la consulta this para ver si teníamos mucho espacio en disco sin utilizar que Postgres estaba atravesando para encontrar lo que estaba buscando. Desafortunadamente, aunque algunas de nuestras tablas sí tenían un poco de volumen, no parecía lo suficientemente importante como para ralentizar el rendimiento general del sistema.

Creemos que la ralentización podría estar relacionada con E/S, pero no podemos encontrar los detalles. ¿Postgres es tonto y, si es así, qué parte? ¿Hay algo mal con la VM, o tal vez algo malo con el hardware físico en sí?

¿Ustedes tienen alguna otra sugerencia para cosas que podamos probar o ver?

EDIT:

lo siento por no actualizar esto antes. Me quedé atrapado en otras cosas.

En esta máquina en particular, nuestro rendimiento mejoró enormemente al realizar una pequeña modificación en la configuración de la máquina virtual.

Hay una configuración que trata con el almacenamiento en caché de IO. Originalmente se estableció en ON. Supusimos que constantemente el almacenamiento en caché estaba ralentizando las cosas y teníamos razón. Lo apagamos, y las cosas mejoraron drásticamente.

Curiosamente, la mayoría de nuestros otros servidores ya tenían esta configuración desactivada.

Hay otros problemas, y estoy seguro de que tomaremos muchas de sus sugerencias, por lo tanto, muchas gracias por ayudar.

Answer 1

Es difícil estar seguro, pero creo que tiene razón al desconfiar de los problemas de E/S. Lo que puede suceder es que a medida que las tablas se hacen más grandes o las conexiones aumentan, los éxitos de caché comienzan a disminuir. Eso aumenta las demandas de E/S y ralentiza todo. Mientras tanto, llegan más consultas, empeorando el problema. La situación es complicada para usted porque los discos virtuales no necesariamente se comportan igual que los físicos.

En primer lugar se tendrá que medir la actividad real en la máquina virtual (a través de vmstat o iostat tal vez). En segundo lugar, haz lo mismo en el hardware real. Finalmente, ejecute algunas herramientas estándar de ancho de banda de disco en ambas (en particular, mezclas de lectura/escritura aleatorias). Ahora podrá decir qué parte de su E/S disponible se está utilizando.

En cuanto a los planes de consulta, sin los detalles del esquema y explicar el resultado de análisis que nadie puede decir.

La lista de correo postgresql.org es útil incluso si solo es para los archivos. Además, el libro vinculado a continuación es excelente.

http://www.packtpub.com/postgresql-90-high-performance/book

Answer 2

(consultas con la cuenta (*) son especialmente malo),

usted debe buscar en window functions

De lo contrario, no tenemos idea sin ver el esquema correspondiente y sus consultas.

Answer 3

Su mayor problema es esta línea:

 
autovacuum    | off 

Encenderlo no curará el problema de inmediato, pero debe evitar que las cosas erosionando aún más. Casi no hay casos en que sea una buena idea apagar esto. La principal excepción es una gran carga masiva seguida de un ANÁLISIS DE CONGELACIÓN DE VACÍO explícito, después de lo cual el autovacío debe volverse a encender. Con el autovacuo desactivado, verá que el rendimiento se degradará, tal como lo hizo. Una vez que la base de datos ha entrado en tan mala forma, requiere un mantenimiento más agresivo que el autovacuum puede proporcionar para su recuperación.

 
checkpoint_segments  | 6 

El aumento que esto ayudará a las modificaciones de datos, pero no va a hacer mucho para mejorar la velocidad de SELECT declaraciones.

 
fsync      | off 
full_page_writes   | off 

Estas configuraciones le dicen a PostgreSQL que acelere las escrituras a expensas de la persistencia. Si su hardware o sistema operativo (o máquina virtual) se bloquea o es abruptamente asesinado, su base de datos se dañará y su mejor opción será restaurar desde su última copia de seguridad conocida. (Por supuesto, ya que el hardware puede fallar en cualquier momento, si se preocupan por la pérdida de los datos, usted tiene una buena estrategia de copia de seguridad en su lugar.)

 
maintenance_work_mem  | 1GB 

Esto es demasiado alta para una máquina virtual de 8 GB. Siempre puede impulsarlo en una sola conexión antes de ejecutar un mantenimiento pesado en esa conexión.

 
wal_writer_delay   | 10ms 

expertos Incluso experimentados tienen problemas para adaptarse a este algo que consigue un mejor rendimiento que el valor predeterminado. Casi siempre es mejor dejarlo solo.

Su mejor opción en este momento es utilizar pg_dumpall para volcar el clúster de base de datos para algún otro medio, empezar con un initdb fresca y de restauración. Como superusuario de base de datos, ejecute VACUUM FREEZE ANALYZE (generalmente no se recomienda FREEZE, excepto después de una carga masiva como esa), y ejecute con autovacuum activado.

le recomiendo que se obtiene una copia del libro "PostgreSQL 9.0 de alto rendimiento" de Greg Smith, y la leyó con cuidado. (Divulgación completa, fui uno de los revisores técnicos del libro, pero no obtuve dinero de las ventas.) Una de las primeras cosas que recomienda es obtener números de referencia sobre la velocidad de su RAM y su disco incluso antes de instalar PostgreSQL, de esa manera sabrá a qué se enfrenta.

Answer 4

También encendía la aspiradora automática. Hay algunas variables que puede establecer que controlan cuánto va a interferir el vacío. Con la cantidad de RAM que tienes, debes tener tus búferes compartidos configurados entre 2048MB y 3276MB. Si tiene una gran cantidad de RAM adicional que su sistema no parece estar utilizando y que no necesita en otro lugar, probablemente debería establecerla más cerca del extremo superior. También es posible que desee ver su tamaño máximo de segmento con sysctl. Su maintenance_work_mem es muy alto, pero si está haciendo principalmente mantenimiento, entonces supongo que no es tan malo como pensé.