Me encuentro con un problema por el cual tengo dos conexiones de un usuario a mi servidor PostgreSQL que se han estado ejecutando durante aproximadamente 4 horas y han estado en estado de confirmación durante bastante tiempo (al menos 1 hora que lo he estado viendo) . Estas conexiones están bloqueando la ejecución de otras consultas, pero no están bloqueadas.
Aquí están las dos conexiones en cuestión.
postgres=# select * from pg_stat_activity where usename = 'xxxxx';
datid | datname | procpid | usesysid | usename | current_query | waiting | xact_start | query_start | backend_start | client_addr | client_port
-------+---------+---------+----------+---------+---------------+---------+-------------------------------+-------------------------------+-------------------------------+---------------+-------------
20394 | xxxxxx | 17509 | 94858 | xxxxx | COMMIT | f | 2014-01-30 05:51:11.311363-05 | 2014-01-30 05:51:12.042515-05 | 2014-01-30 05:51:11.294444-05 | xx.xx.xxx.xxx | 63531
20394 | xxxxxx | 9593 | 94858 | xxxxx | COMMIT | f | 2014-01-30 06:45:17.032651-05 | 2014-01-30 06:45:17.694533-05 | 2014-01-30 06:45:16.992576-05 | xx.xx.xxx.xxx | 63605
PID 9593 es el más problemático que otros usuarios bloquean con este. Por lo que el usuario admite, truncó su tabla, luego hizo inserciones en lotes de 1,000 confirmados después de cada lote.
Actualmente este PID muestra los siguientes bloqueos:
postgres=# select * from pg_locks where pid = 9593;
locktype | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction | pid | mode | granted
---------------+----------+----------+------+-------+------------+---------------+---------+-------+----------+--------------------+------+---------------------+---------
relation | 20394 | 29173472 | | | | | | | | 261/0 | 9593 | AccessExclusiveLock | t
relation | 20394 | 27794470 | | | | | | | | 261/0 | 9593 | RowExclusiveLock | t
relation | 20394 | 27794470 | | | | | | | | 261/0 | 9593 | ShareLock | t
relation | 20394 | 27794470 | | | | | | | | 261/0 | 9593 | AccessExclusiveLock | t
virtualxid | | | | | 261/503292 | | | | | 261/0 | 9593 | ExclusiveLock | t
transactionid | | | | | | 503213304 | | | | 261/0 | 9593 | ExclusiveLock | t
No puedo matar este PID (no ocurre nada cuando ejecuto el comando kill). No estoy seguro de qué hacer para diagnosticar esto más a fondo y obviamente resolverlo.
¿Alguna entrada a alguien?
Ejecutando PostgreSQL 8.4 en el servidor Ubuntu Linux.
EDITAR:
Cuando encontré otras conexiones en un estado similar en el que se colgaba la confirmación, busqué más y encontré lo siguiente en los registros del servidor:
Jan 30 02:29:45 server001 kernel: [3521062.240540] postgres D 0000000000000000 0 23220 8154 0x00000004
Jan 30 02:29:45 server001 kernel: [3521062.240550] ffff8800174c9d08 0000000000000082 ffff88041cd24728 0000000000015880
Jan 30 02:29:45 server001 kernel: [3521062.240559] ffff8806c678b110 0000000000015880 0000000000015880 0000000000015880
Jan 30 02:29:45 server001 kernel: [3521062.240567] 0000000000015880 ffff8806c678b110 0000000000015880 0000000000015880
Jan 30 02:29:45 server001 kernel: [3521062.240575] Call Trace:
Jan 30 02:29:45 server001 kernel: [3521062.240582] [<ffffffff810da010>] ? sync_page+0x0/0x50
Jan 30 02:29:45 server001 kernel: [3521062.240590] [<ffffffff81528488>] io_schedule+0x28/0x40
Jan 30 02:29:45 server001 kernel: [3521062.240596] [<ffffffff810da04d>] sync_page+0x3d/0x50
Jan 30 02:29:45 server001 kernel: [3521062.240603] [<ffffffff815289a7>] __wait_on_bit+0x57/0x80
Jan 30 02:29:45 server001 kernel: [3521062.240610] [<ffffffff810da1be>] wait_on_page_bit+0x6e/0x80
Jan 30 02:29:45 server001 kernel: [3521062.240618] [<ffffffff81078540>] ? wake_bit_function+0x0/0x40
Jan 30 02:29:45 server001 kernel: [3521062.240627] [<ffffffff810e4480>] ? pagevec_lookup_tag+0x20/0x30
Jan 30 02:29:45 server001 kernel: [3521062.240634] [<ffffffff810da665>] wait_on_page_writeback_range+0xf5/0x190
Jan 30 02:29:45 server001 kernel: [3521062.240644] [<ffffffff81053668>] ? try_to_wake_up+0x118/0x340
Jan 30 02:29:45 server001 kernel: [3521062.240651] [<ffffffff810da727>] filemap_fdatawait+0x27/0x30
Jan 30 02:29:45 server001 kernel: [3521062.240659] [<ffffffff811431b4>] vfs_fsync+0xa4/0xf0
Jan 30 02:29:45 server001 kernel: [3521062.240667] [<ffffffff81143239>] do_fsync+0x39/0x60
Jan 30 02:29:45 server001 kernel: [3521062.240674] [<ffffffff8114328b>] sys_fsync+0xb/0x10
Jan 30 02:29:45 server001 kernel: [3521062.240682] [<ffffffff81012042>] system_call_fastpath+0x16/0x1b
He visto entradas similares después de una alta carga de E / S. Todavía no estoy seguro si la mala suerte o realmente alguna conexión.
—
frlan
Sospecho fuertemente un disco o falla del subsistema de E / S en el servidor.
—
Craig Ringer el
@ CraigRinger: creo que tienes razón. Lo extraño es que a las 2 a.m. recibí estas alertas en el archivo de registro y desde entonces, todo el día no recibí más mensajes en los registros; sin embargo, las conexiones de la base de datos todavía se cuelgan como si PostgreSQL no se recuperara de esas fallas. Voy a hacer una actualización del sistema operativo y tal esta noche (con kernel de 4 años)
—
ETL
@ETL
—
Craig Ringer
dmesgtambién: busque errores de E / S, tiempos de espera, errores de HBA, etc. Realice una copia de seguridad nueva y verifique sus discos, sistema de ataque, etc.
Debe haber otro mensaje justo encima de ese postgres D ... llame a trace printk, el que diría, por ejemplo, bloqueo de CPU, proceso atascado durante más de 120 segundos, etc. Eso indicará más claramente cuál es el problema, aunque el seguimiento es ya está bastante claro: parece un fsync (2). ¿Parece que el dispositivo subyacente está roto o es demasiado lento?
—
Josip Rodin