Je rencontre un problème par lequel j'ai deux connexions d'un utilisateur à mon serveur PostgreSQL qui fonctionnent depuis environ 4 heures et sont en état de validation depuis un certain temps (au moins 1 heure que je l'ai regardé) . Ces connexions bloquent l'exécution d'autres requêtes mais elles-mêmes ne sont pas bloquées.
Voici les deux connexions en question.
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
Le PID 9593 est le plus problématique que d'autres utilisateurs obtiennent bloqué par celui-ci. Pour autant que l'utilisateur le reconnaisse, il a tronqué sa table, puis a fait des insertions par lots de 1 000 validations après chaque lot.
Actuellement, ce PID affiche les verrous suivants:
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
Je ne peux pas tuer ce PID (rien ne se passe lorsque j'émets la commande kill). Je ne sais pas quoi faire pour diagnostiquer cela plus avant et évidemment résoudre cela.
Une entrée quelqu'un?
Exécution de PostgreSQL 8.4 sur un serveur Ubuntu Linux.
ÉDITER:
Comme j'ai trouvé d'autres connexions dans un état similaire où la validation était suspendue, j'ai regardé plus loin et trouvé les éléments suivants dans les journaux du serveur:
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
J'ai vu des entrées similaires après une charge d'E / S élevée. Je ne sais toujours pas si la malchance ou vraiment une connexion.
—
2014
Je soupçonne fortement une panne de disque ou de sous-système d'E / S sur le serveur.
—
Craig Ringer
@CraigRinger - Je pense que vous avez raison. Ce qui est étrange, c'est qu'à 2 heures du matin, j'ai reçu ces alertes dans le fichier journal et depuis lors, toute la journée n'a plus reçu de messages dans les journaux - cependant, les connexions à la base de données sont toujours suspendues comme si PostgreSQL ne se remettait pas de ces erreurs. Je vais faire une mise à jour du système d'exploitation et autres ce soir (avec un noyau de 4 ans).
—
ETL
Vérification @ETL
—
Craig Ringer
dmesgégalement - recherchez les erreurs d'E / S, les délais d'expiration, les erreurs HBA, etc. Faites une nouvelle sauvegarde et vérifiez vos disques, sous-système de raid, etc.
Il doit y avoir un autre message juste au-dessus de ce postgres D ... appelez trace printk, celui qui dirait par exemple verrouillage du processeur, processus bloqué pendant plus de 120 secondes, etc. Cela indiquera plus clairement quel est le problème, bien que la trace soit déjà assez clair - qui ressemble à un fsync (2). On dirait que le périphérique sous-jacent est cassé ou trop lent?
—
Josip Rodin