9 votos

Postmaster utiliza excesivo de CPU y Disco Escribe

el uso de PostgreSQL 9.1.2

Estoy viendo el uso excesivo de CPU y grandes cantidades de escrituras a disco desde el administrador de tareas. Esto ocurre incluso mientras mi aplicación está haciendo casi nada (10s de inserciones por MINUTO). Hay un razonable número de conexiones abiertas.

He estado tratando de determinar lo que en mi aplicación está causando esto. Estoy bastante newb con postgresql, y no ha conseguido hasta ahora en cualquier lugar. Me he convertido en algunas de las opciones de registro en mi archivo de configuración, y miró a las conexiones en el pg_stat_activity tabla, pero todos ellos son de inactividad. Sin embargo, cada una conexión consume aproximadamente el 50% de la CPU, y la escritura de ~15 M/s a disco (lectura de la nada).

Estoy básicamente el uso de la bolsa de postgresql.conf con muy pocos ajustes. Agradecería cualquier consejo o consejos sobre lo que puede hacer el seguimiento de este hacia abajo.

Aquí está una muestra de lo superior/iotop me muestra:

Cpu(s): 18.9%us, 14.4%sy,  0.0%ni, 53.4%id, 11.8%wa,  0.0%hi,  1.5%si,  0.0%st
Mem:  32865916k total,  7263720k used, 25602196k free,   575608k buffers
Swap: 16777208k total,        0k used, 16777208k free,  4464212k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                          
17057 postgres  20   0  236m  33m  13m R 45.0  0.1  73:48.78 postmaster                                                                                                                       
17188 postgres  20   0  219m  15m  11m R 42.3  0.0  61:45.57 postmaster                                                                                                                       
17963 postgres  20   0  219m  16m  11m R 42.3  0.1  27:15.01 postmaster                                                                                                                       
17084 postgres  20   0  219m  15m  11m S 41.7  0.0  63:13.64 postmaster                                                                                                                       
17964 postgres  20   0  219m  17m  12m R 41.7  0.1  27:23.28 postmaster                                                                                                                       
18688 postgres  20   0  219m  15m  11m R 41.3  0.0  63:46.81 postmaster                                                                                                                       
17088 postgres  20   0  226m  24m  12m R 41.0  0.1  64:39.63 postmaster                                                                                                                       
24767 postgres  20   0  219m  17m  12m R 41.0  0.1  24:39.24 postmaster                                                                                                                       
18660 postgres  20   0  219m  14m 9.9m S 40.7  0.0  60:51.52 postmaster                                                                                                                       
18664 postgres  20   0  218m  15m  11m S 40.7  0.0  61:39.61 postmaster                                                                                                                       
17962 postgres  20   0  222m  19m  11m S 40.3  0.1  11:48.79 postmaster                                                                                                                       
18671 postgres  20   0  219m  14m   9m S 39.4  0.0  60:53.21 postmaster                                                                                                                       
26168 postgres  20   0  219m  15m  10m S 38.4  0.0  59:04.55 postmaster  


Total DISK READ: 0.00 B/s | Total DISK WRITE: 195.97 M/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND                                                                                                                        
17962 be/4 postgres    0.00 B/s   14.83 M/s  0.00 %  0.25 % postgres: aggw aggw [local] idle
17084 be/4 postgres    0.00 B/s   15.53 M/s  0.00 %  0.24 % postgres: aggw aggw [local] idle
17963 be/4 postgres    0.00 B/s   15.00 M/s  0.00 %  0.24 % postgres: aggw aggw [local] idle
17188 be/4 postgres    0.00 B/s   14.80 M/s  0.00 %  0.24 % postgres: aggw aggw [local] idle
17964 be/4 postgres    0.00 B/s   15.50 M/s  0.00 %  0.24 % postgres: aggw aggw [local] idle
18664 be/4 postgres    0.00 B/s   15.13 M/s  0.00 %  0.23 % postgres: aggw aggw [local] idle
17088 be/4 postgres    0.00 B/s   14.71 M/s  0.00 %  0.13 % postgres: aggw aggw [local] idle
18688 be/4 postgres    0.00 B/s   14.72 M/s  0.00 %  0.00 % postgres: aggw aggw [local] idle
24767 be/4 postgres    0.00 B/s   14.93 M/s  0.00 %  0.00 % postgres: aggw aggw [local] idle
18671 be/4 postgres    0.00 B/s   16.14 M/s  0.00 %  0.00 % postgres: aggw aggw [local] idle
17057 be/4 postgres    0.00 B/s   13.58 M/s  0.00 %  0.00 % postgres: aggw aggw [local] idle
26168 be/4 postgres    0.00 B/s   15.50 M/s  0.00 %  0.00 % postgres: aggw aggw [local] idle
18660 be/4 postgres    0.00 B/s   15.85 M/s  0.00 %  0.00 % postgres: aggw aggw [local] idle

Actualización: Una gran parte de la escritura de archivo parece ser de algún temporal (?) archivos en la $PG_DATA/base/ directorio. Mi comprensión de la estructura de archivos aquí es que cada tabla es básicamente almacena como un archivo cuyo nombre es el OID de la tabla. Sin embargo, hay un montón de archivos con el nombre tnn_nnnnnnn, y es que estos archivos que parecen ser escrito (tal vez escrito más) constantemente. ¿Cuáles son estos archivos? Hay ~4700 de los archivos, y todos son de 8 kb de tamaño:

-rw-------. 1 postgres postgres     8192 Jul  3 23:08 t12_1430975
-rw-------. 1 postgres postgres     8192 Jul  3 23:08 t16_1432736
-rw-------. 1 postgres postgres     8192 Jul  3 23:08 t28_1439066
-rw-------. 1 postgres postgres     8192 Jul  3 23:08 t24_1436243
-rw-------. 1 postgres postgres     8192 Jul  3 23:08 t24_1436210
-rw-------. 1 postgres postgres     8192 Jul  3 23:08 t19_1393372
-rw-------. 1 postgres postgres     8192 Jul  3 23:08 t28_1439051
-rw-------. 1 postgres postgres     8192 Jul  3 23:08 t8_1430334

Actualización: Ejecución de strace en el administrador de procesos, básicamente, muestra una gran cantidad de e/S de archivo de cosas:

open("base/16388/t24_1435947_fsm", O_RDWR) = -1 ENOENT (No such file or directory)
open("base/16388/t24_1435947_vm", O_RDWR) = -1 ENOENT (No such file or directory)
open("base/16388/t24_1435947", O_RDWR)  = 9
lseek(9, 0, SEEK_END)                   = 8192
ftruncate(9, 0)                         = 0
lseek(9, 0, SEEK_END)                   = 0
open("base/16388/t24_1435941", O_RDWR)  = 18
lseek(18, 0, SEEK_END)                  = 0
write(9, "\0\0\0\0\0\0\0\0\1\0\0\0000\0\360\37\360\37\4 \0\0\0\0b1\5\0\2\0\0\0"..., 8192) = 8192
lseek(18, 0, SEEK_END)                  = 0
close(9)                                = 0
open("base/16388/t24_1435947", O_RDWR)  = 9
lseek(9, 0, SEEK_END)                   = 8192
close(18)                               = 0
close(9)                                = 0
open("base/16388/t24_1435944_fsm", O_RDWR) = -1 ENOENT (No such file or directory)
open("base/16388/t24_1435944_vm", O_RDWR) = -1 ENOENT (No such file or directory)
open("base/16388/t24_1435944", O_RDWR)  = 9
lseek(9, 0, SEEK_END)                   = 0
close(9)                                = 0

Actualización: Así que este problema no parece ser todo lo relacionado con las tablas temporales. Hemos cambiado nuestro programa de instalación para las tablas temporales son "normales" de las tablas, y toda la actividad del disco se fue, y el rendimiento es de vuelta a donde yo esperaba que fuera. Ahora, este cambio fue sólo una rápida y sucia de la prueba: si realmente vamos a cambiar el uso de las tablas normales, tenemos problemas con la concurrencia, y la limpieza. Son tablas temporales realmente que mal, o estamos abusando de ellos?

Actualización: Algo más de fondo. Estoy haciendo uso de un in-house desarrollado declaración de la replicación basada en el middleware. Es bastante madura y ha estado en uso en un número de proyectos a lo largo de un número de años, pero el uso de MySQL. Sólo hemos estado trabajando con PostgreSQL durante el último año o dos. Estábamos esencialmente el uso de las tablas temporales como parte del mecanismo de replicación. Cada vez que una nueva conexión se ha establecido, vamos a crear una tabla temporal para cada tabla en la base de datos. Con 10-20 (de larga duración) y las conexiones de ~50 tablas, esto puede equivaler a una gran cantidad de tablas temporales. Todas las tablas temporales que se han creado con:

CREATE TEMPORARY TABLE... ON COMMIT DELETE ROWS;

La semántica de las tablas temporales encaja muy bien con nuestro esquema de replicación, y simplifica mucho el código que hemos tenido que utilizar para MySQL, pero parece que la aplicación no justo así. A partir de los bits de la investigación que he hecho, no creo que las tablas temporales fueron realmente significaba para la función a la que estábamos usando.

Yo no soy el experto in-house (ni de lejos) sobre este tema, sólo un usuario de la misma, por lo que mi explicación puede no ser 100% exacto, pero creo que está bastante cerca.

1voto

Chida Puntos 1926

Su PostgreSQL configuración es la forma que fuera. Este era sospechoso de su mensaje inicial,

 Cpu(s): 18.9%us, 14.4%sy,  0.0%ni, 53.4%id, 11.8%wa,  0.0%hi,  1.5%si,  0.0%st
 Mem:  32865916k total,  7263720k used, 25602196k free,   575608k buffers
 Swap: 16777208k total,        0k used, 16777208k free,  4464212k cached

De 32 GB en su servidor, ~25 GB es gratis excluyendo ~575MB de búfer.

Desde su postgresql.conf archivo,

 shared_buffers = 32MB                   # min 128kB                               
 #temp_buffers = 8MB                     # min 800kB
 #max_prepared_transactions = 0          # zero disables the feature
 ...
 #work_mem = 1MB                         # min 64kB
 #maintenance_work_mem = 16MB            # min 1MB
 #max_stack_depth = 2MB   

Estoy asumiendo que esta es una base de datos dedicada. Si es así, el cambio a los siguientes parámetros y restart/reload,

 shared_buffers = 16GB                   # min 128kB                               
 temp_buffers = 128MB                     # min 800kB
 #max_prepared_transactions = 0          # zero disables the feature
 ...
 work_mem = 8MB                         # min 64kB
 maintenance_work_mem = 64MB            # min 1MB
 max_stack_depth = 4MB   

Me dejan saber cómo cambia su rendimiento y se puede ajustar según sea necesario.

Respecto a las tablas unlogged, si el temporal tablas contienen datos temporales que es efímero y, como usted ha mencionado, se creó en la sesión, es mejor usar tablas unlogged.

Usted puede truncar las tablas sesión posterior si que es aceptable.

Más info aquí -- http://michael.otacoo.com/postgresql-2/unlogged-table-performance-in-postgresql-9-1/

No estoy seguro de por qué usted necesita de tablas temporales para la replicación. No se puede usar PostgreSQL streaming de replicación?

0voto

codethulhu Puntos 1678

El uso de tablas temporales y tener larga conexiones (probablemente la agrupación de conexiones) puede ser una carga si el servidor no está preparado para ello. Uno de PostgreSQL parámetro puede intentar jugar con es temp_buffers que controla la memoria RAM asignada a las tablas temporales. Los búferes temporales son asignados por conexión y el valor predeterminado (8MB) es probablemente demasiado bajo para su sitio.

Tal vez usted también necesita cambiar un poco el comportamiento de la aplicación cliente, dependiendo de cómo usted utiliza sus tablas temporales. Hay una pregunta similar, con una bonita respuesta de Stack Overflow.

0voto

Chida Puntos 1926

Podría publicar su postgresql.conf archivo? Su postgresql parecen ser significativamente bajo optimizado.

Podría también post:

  • Si usted está usando tablas unlogged para sus tablas temporales?

  • Cuántos discos y en qué configuración de RAID?

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: