การทำธุรกรรม PostgreSQL กระทำเป็นเวลาหลายชั่วโมง


11

ฉันพบปัญหาโดยที่ฉันมีการเชื่อมต่อสองรายการจากผู้ใช้ไปยังเซิร์ฟเวอร์ 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) ฉันไม่แน่ใจว่าต้องทำอย่างไรเพื่อวินิจฉัยปัญหานี้เพิ่มเติมและแก้ไขปัญหานี้อย่างชัดเจน

มีใครเข้าบ้างไหม?

ใช้งาน 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

ฉันเห็นรายการที่คล้ายกันหลังจากโหลด I / O สูง ยังไม่แน่ใจว่าโชคร้ายหรือการเชื่อมต่อบางอย่างจริงๆ
frlan

2
ฉันสงสัยอย่างยิ่งว่าดิสก์หรือระบบย่อย I / O ผิดปกติบนเซิร์ฟเวอร์
Craig Ringer

@ CraigRinger - ฉันคิดว่าคุณพูดถูก สิ่งที่แปลกคือเวลา 2:00 น. ฉันได้รับการแจ้งเตือนเหล่านี้ในล็อกไฟล์และตั้งแต่นั้นมาทั้งวันก็ไม่ได้รับข้อความเพิ่มเติมในล็อก - อย่างไรก็ตามการเชื่อมต่อฐานข้อมูลยังคงค้างอยู่ราวกับว่า PostgreSQL ไม่สามารถกู้คืนจากความผิดพลาดเหล่านั้นได้ กำลังจะอัปเดตระบบปฏิบัติการและคืนนี้ (ใช้เคอร์เนลอายุ 4 ปี)
ETL

@ETL ตรวจสอบdmesgด้วย - มองหาข้อผิดพลาด I / O หมดเวลาข้อผิดพลาด HBA ฯลฯ สำรองข้อมูลใหม่และตรวจสอบดิสก์ระบบย่อยการโจมตี ฯลฯ
Craig Ringer

จำเป็นต้องมีข้อความอื่นด้านบนที่ postgres D ... call trace printk, สิ่งที่จะพูดเช่น CPU lock, กระบวนการติดค้างนานกว่า 120 วินาที, ฯลฯ ซึ่งจะแสดงให้เห็นอย่างชัดเจนว่าปัญหาคืออะไรถึงแม้ว่าการติดตามจะเป็น ค่อนข้างชัดเจนอยู่แล้ว - ดูเหมือน fsync (2) ดูเหมือนว่าอุปกรณ์ที่ใช้งานไม่ได้หรือช้าเกินไป?
Josip Rodin

คำตอบ:


1

ฉันได้อัปเกรดเป็นรุ่น 9.4 และเซิร์ฟเวอร์ใหม่ทั้งหมดแล้วดังนั้นฉันจึงไม่สามารถแก้ไขข้อบกพร่องนี้ได้อีก แต่ฉันเชื่อว่าปัญหาเกิดขึ้นกับไดรฟ์ ฉันพบไดรฟ์ที่ไม่ดีซึ่งไม่ได้รายงานว่าเครื่องเสีย

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.