Я столкнулся с проблемой, из-за которой у меня есть два подключения пользователя к моему серверу 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 | 63605PID 9593 является наиболее проблемным, который другие пользователи блокируют этим. Насколько допускает пользователь, он обрезал свою таблицу, а затем делал вставки партиями по 1000 фиксаций после каждой партии.
В настоящее время этот 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). Я не уверен, что делать, чтобы диагностировать это дальше и, очевидно, решить эту проблему.
Любой вклад кого-нибудь?
Запуск PostgreSQL 8.4 на сервере Ubuntu Linux.
РЕДАКТИРОВАТЬ:
Когда я обнаружил другие соединения в аналогичном состоянии, в котором зависание фиксации, я посмотрел дальше и обнаружил следующее в журналах сервера:
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
Я видел похожие записи после высокой нагрузки ввода / вывода. До сих пор не уверен, везет ли вам или действительно какая-то связь.
—
Фрлан
Я сильно подозреваю сбой диска или подсистемы ввода-вывода на сервере.
—
Крейг Рингер
@CraigRinger - думаю, ты прав. Странно то, что в 2 часа ночи я получил эти предупреждения в файле журнала и с тех пор весь день не получал больше сообщений в журналах - однако соединения с базой данных по-прежнему зависают, как будто PostgreSQL не восстанавливается после этих сбоев. Собираюсь сегодня вечером сделать обновление ОС и такое (работает ядро 4 года).
—
ETL
Также проверяйте @ETL
—
Крейг Рингер,
dmesg- ищите ошибки ввода-вывода, тайм-ауты, ошибки HBA и т. Д. Возьмите свежую резервную копию и проверьте свои диски, подсистему raid и т. Д.
Над этим должно быть еще одно сообщение, которое postgres D ... вызывает трассировку printk, то есть сообщение, например, «Блокировка процессора», «зависание процесса более 120 секунд» и т. Д. Это будет более четко указывать на проблему, хотя трассировка уже достаточно ясно - это выглядит как fsync (2). Похоже, базовое устройство сломано или слишком медленно?
—
Иосип Роден