PostgreSQL事务提交数小时

我遇到一个问题，从用户到我的PostgreSQL服务器有两个连接，它们已经运行了大约4个小时，并且处于提交状态已经有一段时间了（我一直在观察它至少1个小时）。这些连接阻止了其他查询的运行，但它们本身并未被阻止。

这是有问题的两个连接。

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是最有问题的一种，其他用户也被这一问题阻止。就用户允许的程度而言，他将自己的表截断，然后在每批之后以1,000次提交的方式批量插入。

当前，此PID显示以下锁定：

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

我无法终止此PID（发出kill命令时什么也没有发生）。我不确定该怎么做才能进一步诊断并明显解决此问题。

任何输入有人吗？

在Ubuntu Linux服务器上运行PostgreSQL 8.4。

编辑：

当我发现其他连接处于挂起提交的类似状态时，我进一步查看并在服务器日志中找到以下内容：

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

postgresql linux postgresql-8.4

— ETL
source

高I / O负载后，我看到了类似的条目。仍然不确定是运气不好还是真的有联系。

— frlan 2014年

我强烈怀疑服务器上的磁盘或I / O子系统故障。

— Craig Ringer 2014年

@CraigRinger-我认为你是对的。奇怪的是，在凌晨2点，我在日志文件中收到了这些警报，从那以后，整天都没有在日志中收到更多消息-但是，数据库连接仍然挂起，就好像PostgreSQL无法从那些故障中恢复一样。今晚要进行OS等更新（运行4岁的内核）。

— ETL

@ETL检查dmesg太-寻找I / O错误，超时，HBA错误等取新鲜备份，并检查您的磁盘，RAID子系统等

— 克雷格·林格

在postgres D ...上方需要有另一条消息，称为跟踪printk，该消息将表示例如CPU锁定，进程卡滞超过120秒等。这将更清楚地表明问题出在哪里，尽管跟踪是已经很清楚了-看起来像fsync（2）。看起来基础设备坏了还是太慢？

— Josip Rodin 2015年

从那以后，我已升级到9.4版和一个全新的服务器，因此无法进一步调试。但是我相信问题出在驱动器上。我发现一个坏的驱动器没有被机器报告为坏。

— ETL
source