PostgreSQL pg_stat_activity mostra COMMIT

Di recente abbiamo sostituito il nostro server di database con una macchina aggiornata con 4 CPU quad core e 32 GB di RAM. Abbiamo anche riproposto la nostra vecchia scatola in modo che fungesse da slave con replica in streaming. Entrambe le caselle eseguono CentOS 6.3 e PostgreSQL 9.2. Postgres è l'unica cosa in esecuzione su ciascuna delle scatole.

Questa configurazione è in atto da circa un mese circa, quando all'improvviso abbiamo iniziato a imbatterci in alcuni problemi mentre il traffico iniziava ad aumentare. Ciò che abbiamo iniziato a vedere è un carico della CPU estremamente elevato (a volte in alto mostra una media di carico di 270) e quando possiamo vedere pg_stat_activityvedremo che la maggior parte delle nostre connessioni sono nello COMMITstato. Se lasciato solo, alla fine questo finirà e il sistema diventerà reattivo con le connessioni che diventano IDLE. Abbiamo provato a disabilitare la replica per vedere se questo potrebbe essere il problema, ma il problema persiste ancora.

Abbiamo provato a diagnosticare ciò che sta accadendo e ci siamo persi un po '. L'output della corsa perfmostra qualcosa di simile al seguente, e non ho idea di cosa 0x347ba9rappresenti.

+  41.40%       48154  postmaster  0x347ba9         f 0x347ba9                                   ◆
+   9.55%       10956  postmaster  0x2dc820         f set_config_option                          ▒
+   8.64%        9946  postmaster  0x5a3d4          f writeListPage     
+   5.75%        6609  postmaster  0x5a2b0          f ginHeapTupleFastCollect                    ▒
+   2.68%        3084  postmaster  0x192483         f build_implied_join_equality                ▒
+   2.61%        2990  postmaster  0x187a55         f build_paths_for_OR                         ▒
+   1.86%        2131  postmaster  0x794aa          f get_collation_oid                          ▒
+   1.56%        1822  postmaster  0x5a67e          f ginHeapTupleFastInsert                     ▒
+   1.53%        1766  postmaster  0x1929bc         f distribute_qual_to_rels                    ▒
+   1.33%        1558  postmaster  0x249671         f cmp_numerics

Nessuna delle query eseguite dall'app è particolarmente complessa, con spiegazione dei piani che richiede al massimo 1 secondo (la maggior parte sono molto più veloci). Inoltre, mentre questo accade quando il traffico inizia a salire, non stiamo parlando di un enorme carico di traffico (la vecchia macchina era in grado di gestirlo abbastanza facilmente).

A questo punto sono un po 'perplesso su cosa provare dopo. Qualsiasi aiuto o suggerimento sarebbe apprezzato. Se ci sono ulteriori informazioni che potrebbero aiutare, basta chiedere e posso modificare la domanda.

Configurazione del disco:

Controller RAID Perc 6i
5 unità SAS 15K da 146 GB
Configurato come RAID-1 2x146GB per WAL e RAID-5 3x146GB per sistema e dati

Aggiornare:

Di seguito è riportato l'output di VMStat quando il sistema funziona normalmente e quando la CPU si avvia. Quando c'è un problema, gli interrupt sembrano salire alle stelle.

Durante il normale funzionamento:

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ ---timestamp---
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 18938590 303763 21947154    0    0    28    52 7466 12649  2  1 97  0  0   2013-01-14 16:03:25 EST
 0  0      0 18938396 303763 21947154    0    0     0    19 7107 12679  2  0 98  0  0   2013-01-14 16:03:35 EST
 1  0      0 18938904 303763 21947162    0    0     0    54 7042 12708  1  1 99  0  0   2013-01-14 16:03:45 EST
 1  0      0 18938520 303763 21947260    0    0    33    66 7120 12738  1  1 99  0  0   2013-01-14 16:03:55 EST

Quando l'utilizzo della CPU è elevato:

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ ---timestamp---
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
343 0      0 32680468 226279 11339612    0    0     0   214 26692 12225 80  20  0  0  0   2013-01-11 16:45:53 EST
374 1      0 32673764 226291 11340345    0    0     0    77 54893 11572 80  20  0  0  0   2013-01-11 16:46:03 EST
383 0      0 32616620 226304 11340956    0    0     0   102 55540 12922 82  18  0  0  0   2013-01-11 16:46:13 EST
315 0      0 32602038 226320 11341378    0    0     0    79 54539 12441 82  18  0  0  0   2013-01-11 16:46:23 EST

postgresql

— jcern
fonte

Che tipo di dischi ha la nuova scatola? Succede su entrambi i nodi o solo su uno di essi?

— Trygve Laugstøl,

@trygvis - Ho aggiornato la domanda con le specifiche del disco. Il problema si sta verificando sul nodo principale. Non ho cercato di promuovere lo Slave e indirizzare il traffico verso di esso, quindi non sono sicuro che si tratti di un problema anche lì nelle stesse circostanze. Come schiavo, la macchina non sembra avere alcun problema.

— jcern

Prendi in considerazione l'uso dello perfstrumento per eseguire una profilazione a livello di sistema e una profilazione PostgreSQL. Scopri dove si sta verificando l'utilizzo della CPU. A proposito, la formattazione del tuo secondo vmstatè irrimediabilmente alterata e le colonne del primo sono disallineate, quindi è difficile da leggere. Prova per vedere se l'aggiunta di commit_delaycose migliora. Controlla se il tuo controller RAID ha una cache di write-back con batteria e se non lo ha, prendine uno. È trascorso molto tempo iowait? Questo sembra essere l'utilizzo della CPU in alcuni rapporti, ma non lo è.

— Craig Ringer,

@CraigRinger il controller ha una cache di scrittura alimentata a batteria, che è attualmente abilitata. In attesa di iostat è rimasto nelle cifre da singole a doppie basse. Continueremo a provare altri profili con perf. Ho anche corretto la formattazione del secondo VMStat, grazie per averlo sottolineato.

— jcern

Dopo ulteriori diagnosi e alcuni googling, ci siamo imbattuti in questo articolo che descriveva molti degli stessi sintomi che stavamo vivendo. La causa principale del loro problema (e da quello che possiamo dire, anche il nostro) era legata Transparent Huge Pagesall'implementazione.

Dopo aver disabilitato Transparent Huge Pagescon questo comando:

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled

Il problema sembra essere stato risolto. Abbiamo eseguito un carico di lavoro maggiore nelle ultime due settimane e il problema non è riemerso. I contesti e gli interrupt del sistema sono costantemente 1/10 di quello che erano stati e anche il tempo medio di sistema è diminuito.

Non sono sicuro che sia la soluzione per tutti, ma lo inserisco qui come possibile causa nel caso in cui possa aiutare qualcun altro a risolvere un problema simile.

— jcern
fonte