PostgreSQL pg_stat_activity muestra COMMIT

11

Recientemente reemplazamos nuestro servidor de base de datos con una máquina actualizada con 4 CPU de cuatro núcleos y 32 Gb de ram. También reutilizamos nuestra vieja caja para servir como esclavo con la replicación de transmisión. Ambas cajas ejecutan CentOS 6.3 y PostgreSQL 9.2. Postgres es lo único que se ejecuta en cada una de las cajas.

Esta configuración ha estado vigente durante aproximadamente un mes, cuando de repente comenzamos a encontrarnos con algunos problemas cuando el tráfico comenzó a aumentar. Lo que hemos comenzado a ver es una carga de CPU extremadamente alta a veces (la parte superior muestra un promedio de carga de 270), y cuando podamos mirar pg_stat_activity, veremos que la mayoría de nuestras conexiones están en el COMMITestado. Cuando se deja solo, esto finalmente terminará y el sistema se volverá receptivo con las conexiones IDLE. Hemos intentado deshabilitar la replicación para ver si ese podría ser el problema, pero el problema aún persiste.

Hemos intentado diagnosticar lo que está sucediendo y estamos un poco perdidos. El resultado de la ejecución perfmuestra algo similar a continuación, y no tengo idea de lo que 0x347ba9representa.

+  41.40%       48154  postmaster  0x347ba9         f 0x347ba9                                   ◆
+   9.55%       10956  postmaster  0x2dc820         f set_config_option                          ▒
+   8.64%        9946  postmaster  0x5a3d4          f writeListPage     
+   5.75%        6609  postmaster  0x5a2b0          f ginHeapTupleFastCollect                    ▒
+   2.68%        3084  postmaster  0x192483         f build_implied_join_equality                ▒
+   2.61%        2990  postmaster  0x187a55         f build_paths_for_OR                         ▒
+   1.86%        2131  postmaster  0x794aa          f get_collation_oid                          ▒
+   1.56%        1822  postmaster  0x5a67e          f ginHeapTupleFastInsert                     ▒
+   1.53%        1766  postmaster  0x1929bc         f distribute_qual_to_rels                    ▒
+   1.33%        1558  postmaster  0x249671         f cmp_numerics

Ninguna de las consultas realizadas por la aplicación es particularmente compleja, con planes explicativos que toman como máximo 1 segundo (la mayoría son mucho más rápidos). Además, si bien esto sucede cuando el tráfico comienza a aumentar, no estamos hablando de una gran carga de tráfico (la máquina anterior solía ser capaz de manejarlo con bastante facilidad).

En este punto, estoy un poco perplejo sobre qué probar a continuación. Cualquier ayuda o sugerencias serán apreciadas. Si hay alguna información adicional que pueda ayudar, solo pregunte y puedo enmendar la pregunta.

Configuración de disco:

  • Controlador RAID Perc 6i
  • 5 unidades de disco duro SAS 146K 15K
  • Configurado como 2x146GB RAID-1 para WAL y 3x146GB RAID-5 para Sistema y Datos

Actualizar:

A continuación se muestra la salida de VMStat cuando el sistema funciona normalmente y cuando la CPU se dispara. Cuando hay un problema, las interrupciones parecen dispararse.

Durante el funcionamiento normal:

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ ---timestamp---
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 18938590 303763 21947154    0    0    28    52 7466 12649  2  1 97  0  0   2013-01-14 16:03:25 EST
 0  0      0 18938396 303763 21947154    0    0     0    19 7107 12679  2  0 98  0  0   2013-01-14 16:03:35 EST
 1  0      0 18938904 303763 21947162    0    0     0    54 7042 12708  1  1 99  0  0   2013-01-14 16:03:45 EST
 1  0      0 18938520 303763 21947260    0    0    33    66 7120 12738  1  1 99  0  0   2013-01-14 16:03:55 EST

Cuando el uso de la CPU es alto:

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ ---timestamp---
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
343 0      0 32680468 226279 11339612    0    0     0   214 26692 12225 80  20  0  0  0   2013-01-11 16:45:53 EST
374 1      0 32673764 226291 11340345    0    0     0    77 54893 11572 80  20  0  0  0   2013-01-11 16:46:03 EST
383 0      0 32616620 226304 11340956    0    0     0   102 55540 12922 82  18  0  0  0   2013-01-11 16:46:13 EST
315 0      0 32602038 226320 11341378    0    0     0    79 54539 12441 82  18  0  0  0   2013-01-11 16:46:23 EST
postgresql jcern
fuente
¿Qué tipo de discos tiene la nueva caja? ¿Está sucediendo esto en ambos nodos o solo uno de ellos?
Trygve Laugstøl
@trygvis - Actualicé la pregunta con las especificaciones del disco. El problema está sucediendo en el nodo maestro. No he tratado de promover el Esclavo y dirigir el tráfico hacia él, por lo que no estoy seguro de si es un problema allí también en las mismas circunstancias. Como esclavo, la máquina no parece experimentar ningún problema.
jcern
2
Considere usar la perfherramienta para hacer algunos perfiles en todo el sistema y algunos perfiles de PostgreSQL. Vea dónde se produce el uso de la CPU. Por cierto, el formato de su segundo vmstatestá irremediablemente destrozado, y las columnas del primero están desalineadas, por lo que es difícil de leer. Prueba para ver si agregar un commit_delaymejora las cosas. Compruebe si su controlador RAID tiene una memoria caché de reescritura respaldada por batería y si no la tiene, obtenga una. ¿Pasa mucho tiempo adentro iowait? Esto parece ser el uso de la CPU en algunos informes, pero en realidad no lo es.
Craig Ringer
@CraigRinger el controlador tiene un caché de escritura respaldado por batería, y eso está habilitado actualmente. A la espera de iostat permaneció en los dígitos dobles simples a bajos. Continuaremos probando más perfiles con perf. También arreglé el formato del segundo VMStat, gracias por señalarlo.
jcern

Respuestas:

11

Después de más diagnósticos y algunas búsquedas en Google, encontramos este artículo que describía muchos de los mismos síntomas que estábamos experimentando. La causa raíz de su problema (y de lo que podemos decir, el nuestro también) estaba relacionado con la Transparent Huge Pagesimplementación.

Después de deshabilitar Transparent Huge Pagescon este comando:

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled

El problema parece haberse resuelto. Hemos estado trabajando con una mayor carga de trabajo durante las últimas dos semanas y el problema no ha resurgido. Los contextos e interrupciones del sistema son consistentemente 1/10 de lo que habían sido y el tiempo promedio del sistema también ha disminuido.

No estoy seguro de si es la solución para todos, pero lo publico aquí como una posible causa en caso de que pueda ayudar a alguien más a resolver un problema similar.

jcern
fuente