몇 시간 동안 PostgreSQL 트랜잭션 커밋

약 4 시간 동안 실행되고 꽤 오랜 시간 동안 커밋 상태에 있었던 사용자에서 PostgreSQL 서버로 두 개의 연결이있는 문제가 발생했습니다 (최소한 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
소스

높은 I / O로드 후 비슷한 항목을 보았습니다. 운이 좋지 않은지 아니면 실제로 어떤 연결인지 확실하지 않습니다.

— frlan

서버의 디스크 또는 I / O 하위 시스템 오류가 의심됩니다.

— Craig Ringer

@CraigRinger-당신이 옳다고 생각합니다. 이상한 점은 오전 2시에 로그 파일에 이러한 경고가 표시되고 그 이후로 하루 종일 로그에 더 많은 메시지가 표시되지 않는다는 것입니다. 그러나 PostgreSQL이 이러한 결함으로부터 복구되지 않은 것처럼 데이터베이스 연결이 여전히 중단됩니다. OS 및 오늘 밤 (4 세 커널 실행) 업데이트를하려고합니다.

— ETL

@ETL 점검 dmesg– I / O 오류, 시간 초과, HBA 오류 등을 찾으십시오. 새로운 백업을 수행하고 디스크, 급습 서브 시스템 등을 확인하십시오.

— Craig Ringer

postgres D ... call trace printk와 같은 또 다른 메시지가 필요합니다. 예를 들어 CPU 잠금, 120 초 이상 프로세스가 멈춤 등이 있습니다. 추적은 문제가 무엇인지 더 명확하게 나타냅니다. 이미 상당히 명확합니다-fsync (2)처럼 보입니다. 기본 장치가 고장 났거나 너무 느리게 보입니까?

— Josip Rodin

이후 버전 9.4 및 완전히 새로운 서버로 업그레이드하여 더 이상 디버깅 할 수 없습니다. 그러나 나는 문제가 드라이브에 있다고 믿습니다. 기계에 의해 불량으로보고되지 않은 불량 드라이브를 발견했습니다.

— ETL
소스