Sto riscontrando un problema in base al quale ho due connessioni da un utente al mio server PostgreSQL che sono state in esecuzione per circa 4 ore e sono in stato di commit da un po 'di tempo (almeno 1 ora che l'ho guardato) . Queste connessioni bloccano l'esecuzione di altre query ma non sono bloccate.
Ecco le due connessioni in questione.
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 è il più problematico a cui altri utenti vengono bloccati da questo. Per quanto l'utente sta ammettendo, ha troncato la sua tabella, quindi ha fatto inserimenti in lotti di 1.000 commit dopo ogni lotto.
Attualmente questo PID mostra i seguenti blocchi:
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 | tNon riesco a uccidere questo PID (non succede nulla quando invio il comando kill). Non sono sicuro di cosa fare per diagnosticare ulteriormente questo problema e ovviamente risolverlo.
Qualche input qualcuno?
Esecuzione di PostgreSQL 8.4 sul server Ubuntu Linux.
MODIFICARE:
Mentre trovavo altre connessioni in uno stato simile in cui il commit era sospeso, ho guardato oltre e ho trovato quanto segue nei registri del server:
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
Ho visto voci simili dopo un elevato carico di I / O. Ancora non sono sicuro se sfortuna o davvero qualche connessione.
—
dal
Sospetto fortemente un errore del disco o del sottosistema I / O sul server.
—
Craig Ringer,
@CraigRinger - Penso che tu abbia ragione. La cosa strana è che alle 2 del mattino ho ricevuto questi avvisi nel file di registro e da allora, tutto il giorno non ho ricevuto più messaggi nei registri, tuttavia, le connessioni al database sono ancora bloccate come se PostgreSQL non si fosse ripreso da quei guasti. Stasera farò un aggiornamento del sistema operativo e simili (con kernel di 4 anni).
—
ETL
@ETL check
—
Craig Ringer
dmesgtoo - cerca errori I / O, timeout, errori HBA, ecc. Effettua un nuovo backup e controlla i tuoi dischi, il sottosistema raid, ecc.
C'è bisogno di un altro messaggio proprio sopra che postgres D ... chiama trace printk, quello che direbbe ad esempio blocco della CPU, processo bloccato per oltre 120 secondi, ecc. Ciò indicherà più chiaramente qual è il problema, sebbene la traccia sia già abbastanza chiaro - sembra un fsync (2). Sembra che il dispositivo sottostante sia rotto o troppo lento?
—
Josip Rodin,