मैं एक ऐसे मुद्दे पर चल रहा हूँ जिसके तहत मेरे पास एक उपयोगकर्ता से मेरे 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 सबसे अधिक समस्याग्रस्त है जिसे अन्य उपयोगकर्ता इस एक के द्वारा अवरुद्ध कर देते हैं। जहां तक उपयोगकर्ता स्वीकार कर रहा है, उसने अपनी तालिका को काट दिया, फिर प्रत्येक बैच के बाद 1,000 कमिट के बैचों में आवेषण किया।
वर्तमान में यह पीआईडी निम्नलिखित ताले दिखाता है:
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मैं इस पीआईडी को नहीं मार सकता (कुछ भी नहीं होता है जब मैं हत्या आदेश जारी करता हूं)। मुझे यकीन नहीं है कि आगे इसका निदान करने के लिए क्या करना चाहिए और स्पष्ट रूप से इसका समाधान करना चाहिए।
कोई इनपुट किसी को?
Ubuntu लिनक्स सर्वर पर 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
मैंने उच्च I / O लोड के बाद समान प्रविष्टियों को देखा है। अभी भी यकीन नहीं है कि दुर्भाग्य या वास्तव में कुछ कनेक्शन।
—
फ्रलान
मुझे सर्वर पर डिस्क या I / O सबसिस्टम की गलती का संदेह है।
—
क्रेग रिंगर
@ क्रेगिंगर - मुझे लगता है कि आप सही हैं। अजीब बात यह है कि 2AM पर मुझे लॉग फ़ाइल में ये अलर्ट मिले और तब से, पूरे दिन लॉग में अधिक संदेश नहीं मिले - हालाँकि, डेटाबेस कनेक्शन अभी भी लटका हुआ है जैसे कि PostgreSQL उन दोषों से उबर नहीं पाया। OS का अद्यतन करने के लिए जा रहा है और आज रात (4 साल पुराना कर्नेल चला रहा है)।
—
ईटीएल
@ETL चेक
—
क्रेग रिंगर
dmesgभी - I / O एरर, टाइमआउट, HBA एरर आदि की तलाश करें। एक नया बैकअप लें, और अपने डिस्क्स, रेड सबसिस्टम आदि को चेक करें
इसके ऊपर एक और संदेश होना चाहिए जो D को पोस्ट करता है ... कॉल ट्रेस प्रिंट, वह जो कहेगा जैसे CPU लॉक, 120 सेकंड से अधिक के लिए अटक गई प्रक्रिया, आदि। यह अधिक स्पष्ट रूप से इंगित करेगा कि समस्या क्या है, हालांकि ट्रेस है पहले से ही काफी स्पष्ट है - जो fsync (2) जैसा दिखता है। ऐसा लगता है कि अंतर्निहित डिवाइस टूट गया है या बहुत धीमा है?
—
जोसिप रॉडिन