Tôi đang gặp phải một vấn đề trong đó tôi có hai kết nối từ người dùng đến máy chủ PostgreSQL của tôi đã chạy được khoảng 4 giờ và đã ở trạng thái cam kết trong một thời gian khá lâu (ít nhất là 1 giờ tôi đã xem nó) . Các kết nối này đang chặn các truy vấn khác chạy nhưng bản thân chúng không bị chặn.
Đây là hai kết nối trong câu hỏi.
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 là vấn đề khó giải quyết nhất mà người dùng khác bị chặn bởi cái này. Theo như người dùng thừa nhận, anh ta đã cắt ngắn bảng của mình, sau đó thực hiện chèn theo lô 1.000 cam kết sau mỗi đợt.
Hiện tại, PID này hiển thị các khóa sau:
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 | tTôi không thể giết PID này (không có gì xảy ra khi tôi ban hành lệnh kill). Tôi không biết phải làm gì để chẩn đoán thêm và rõ ràng là giải quyết vấn đề này.
Bất kỳ ai nhập?
Chạy PostgreSQL 8.4 trên máy chủ Ubuntu Linux.
BIÊN TẬP:
Khi tôi tìm thấy các kết nối khác trong trạng thái tương tự nơi cam kết bị treo, tôi nhìn xa hơn và tìm thấy những điều sau trong nhật ký máy chủ:
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
Tôi đã thấy các mục tương tự sau khi tải I / O cao. Vẫn không chắc chắn cho dù xui xẻo hay thực sự một số kết nối.
—
frlan
Tôi nghi ngờ một lỗi hệ thống con đĩa hoặc I / O trên máy chủ.
—
Craig Ringer
@CraigRinger - Tôi nghĩ bạn đúng. Điều kỳ lạ là vào lúc 2 giờ sáng, tôi nhận được các thông báo này trong tệp nhật ký và kể từ đó, cả ngày không nhận được nhiều tin nhắn hơn trong nhật ký - tuy nhiên, các kết nối cơ sở dữ liệu vẫn bị treo như thể PostgreQuery không phục hồi được từ các lỗi đó. Sẽ thực hiện cập nhật HĐH và tối nay (chạy kernel 4 tuổi).
—
ETL
@ETL
—
Craig Ringer
dmesgcũng kiểm tra - tìm lỗi I / O, thời gian chờ, lỗi HBA, v.v. Hãy sao lưu mới và kiểm tra đĩa của bạn, đột kích hệ thống con, v.v.
Cần phải có một thông báo khác ngay phía trên rằng postgres D ... gọi theo dõi printk, một trong đó sẽ nói ví dụ như khóa CPU, quá trình bị kẹt trong hơn 120 giây, v.v. Điều đó sẽ cho thấy rõ hơn vấn đề là gì, mặc dù dấu vết là đã khá rõ ràng - trông giống như một fsync (2). Hình như thiết bị cơ bản bị hỏng hoặc quá chậm?
—
Josip Rodin