Server bloccato causa postgresql deadlock (credo)

[Michele Petrazzo]

Buon pomeriggio,
oggi mi è successa una brutta cosa: un server (in produzione) mi si è
bloccato e non rispondeva più, ne rete (ssh/ping), ne console seriale o
fisica. Bello bloccato direi...

Andando a frugare nei log dei vari software in produzione / demoni, ho
potuto vedere che il problema è nato (credo, non ne sono sicuro) da
postgresql v. 8.3

Nei log vedo, qualche minuto prima del problema:

ERROR: deadlock detected
CEST DETAIL: Process 3497 waits for ShareLock on transaction 8104365;
blocked by process 3514.

Altra informazione utile, credo, è che munin mi dice che da un po' prima
(circa 1 ora, dal grafico non si capisce molto bene) netstat, numero di
processi, vmstat running load sono aumentati vertiginosamente fino a
quando il tutto si è bloccato. Netstat, da 20 a 200, processi: 120 ->
400, vmstat running: 1 -> 40, load: 1 (neanche) -> 30.

Non vi chiedo di dirmi perché il tutto è successo :), ma secondo voi
cosa si può fare per evitare che se per un qualsiasi motivo un software
o qualsiasi altro accrocchio che gira sul server fa casini, non mandi a
donnine il server intero?

debian con kernel 2.6.30

Michele

[Davide Bianchi]

Post by Michele Petrazzo
cosa si può fare per evitare che se per un qualsiasi motivo un software
o qualsiasi altro accrocchio che gira sul server fa casini, non mandi a
donnine il server intero?

Tenere il server spento e' l'unico modo sicuro. Sorry, ma non e' che
tu possa fare molto. Se vuoi usare il server dovrai assumerti qualche
rischio.

Davide

[Michele Petrazzo]

Post by Davide Bianchi

Post by Michele Petrazzo
cosa si può fare per evitare che se per un qualsiasi motivo un software
o qualsiasi altro accrocchio che gira sul server fa casini, non mandi a
donnine il server intero?

Tenere il server spento e' l'unico modo sicuro.

Esagerato!
E chi usa sistemi windows, cosa dovrebbe fare allora? ;)

Post by Davide Bianchi
Sorry, ma non e' che tu possa fare molto.

Ma non si può dire al kernel ( o a qualche demone), che ne so, non
eseguire più nuovi processi se il load avarage è maggiore di X, oppure
non aprire più socket se ne hai già aperte Y?

Post by Davide Bianchi
Se vuoi usare il server dovrai assumerti qualche
rischio.

Ma se li limito ad un numero basso, magari dormo (più) contento!

Post by Davide Bianchi
Davide

Michele

[Renaissance]

Post by Michele Petrazzo

Post by Davide Bianchi
Sorry, ma non e' che tu possa fare molto.

Ma non si può dire al kernel ( o a qualche demone), che ne so, non
eseguire più nuovi processi se il load avarage è maggiore di X, oppure
non aprire più socket se ne hai già aperte Y?

Non e' quello il problema, se tu sai cosa voglia dire "dead lock", ed
il fatto che affligge particolarmente proprio i dbms.

bye G.L.

[Michele Petrazzo]

Post by Renaissance

Post by Michele Petrazzo

Post by Davide Bianchi
Sorry, ma non e' che tu possa fare molto.

Ma non si può dire al kernel ( o a qualche demone), che ne so, non
eseguire più nuovi processi se il load avarage è maggiore di X, oppure
non aprire più socket se ne hai già aperte Y?

Non e' quello il problema, se tu sai cosa voglia dire "dead lock",

considerando che siamo su .sys e non su iniziare, direi di si.

Post by Renaissance
ed il fatto che affligge particolarmente proprio i dbms.

Concordo.
Ma pensavo che un semplice deadlock su servizio (che in questo caso è un
dbms) non potesse mandare a signorine un intero sistema.
A dirla tutta, può essere anche che non sia stato quello, ma sta di
fatto che qualcosa, in user space, ha bloccato l'intero sistema. E
questo non è bene!

Post by Renaissance
bye G.L.

[Renaissance]

Post by Michele Petrazzo

Post by Renaissance
Non e' quello il problema, se tu sai cosa voglia dire "dead lock",

considerando che siamo su .sys e non su iniziare, direi di si.

Post by Renaissance
ed il fatto che affligge particolarmente proprio i dbms.

Concordo.
Ma pensavo che un semplice deadlock su servizio (che in questo caso è un
dbms) non potesse mandare a signorine un intero sistema.
A dirla tutta, può essere anche che non sia stato quello, ma sta di
fatto che qualcosa, in user space, ha bloccato l'intero sistema. E
questo non è bene!

Ehm, il deadlock si verifica quando accade che due processi concorrenti
aspettano vicendevolmente che uno rilasci una risorsa "critica" (cioe'
una risorsa che puo' essere rilasciata ed utilizzata solo a un processo
per volta) che necessita all'altro. Naturalmente le risorse sono gestite
dal *sistema operativo*. Si incorre cosi' in una situazione di stallo,
che non dipende dai processi/thread in user space... (a meno che, ad
esempio, nel dbms non si implementi qualche meccanismo che prevenga il
deadlock fra i suoi processi e i suoi thread, ma qui mi fermo perche' e'
materia a me poco consona) :-)
Esistono algoritmi predittivi di situazioni di dead lock, ma AFAIK
molto difficilmente vengono adottati nei sistemi operativi odierni per
via dell'eccessivo overhead che ne risulterebbe. E immagino che sarebbe
altrettanto o piu' sconveniente implementarli in user space nel dbms...
Certamente il sovraccarico, con le conseguenti ingenti richieste di
servizio al sistema operativo, rende piu' probabile incorrere nei
deadlock.
D'accordo con te comunque che sia strano che un deadlock, che dovrebbe
solo "incantare" due o piu' processi, impalli cosi' il resto del
sistema...

bye G.L.

[Michele Petrazzo]

Post by Renaissance

Post by Michele Petrazzo
Ma pensavo che un semplice deadlock su servizio (che in questo caso è
un dbms) non potesse mandare a signorine un intero sistema.
A dirla tutta, può essere anche che non sia stato quello, ma sta di
fatto che qualcosa, in user space, ha bloccato l'intero sistema. E
questo non è bene!

Ehm, il deadlock si verifica quando accade che due processi concorrenti
aspettano vicendevolmente che uno rilasci una risorsa "critica" (cioe'
una risorsa che puo' essere rilasciata ed utilizzata solo a un processo
per volta) che necessita all'altro. Naturalmente le risorse sono gestite
dal *sistema operativo*. Si incorre cosi' in una situazione di stallo,
che non dipende dai processi/thread in user space... (a meno che, ad
esempio, nel dbms non si implementi qualche meccanismo che prevenga il
deadlock fra i suoi processi e i suoi thread, ma qui mi fermo perche' e'
materia a me poco consona) :-)

Aspiterina. Hai ragione. Mi ero incartato e le informazioni sparse alla
rinfusa nel cranio su delle specifiche di postgresql che avevo letto mi
avevano tratto in inganno...
Avevo confuso la non possibilità di utilizzare più processi
contemporaneamente per una stessa query con non usare più processi (da
parte di pg) per diverse query, che è quello che viene fatto normalmente
e quindi ricadiamo comunque a livello di os...

Post by Renaissance
Certamente il sovraccarico, con le conseguenti ingenti richieste di
servizio al sistema operativo, rende piu' probabile incorrere nei
deadlock.

Ma pg, come da specifiche (file transactions.pdf) dice che se non riesce
a ricevere il lock perché trova il dead-lock, ritorna e segnala
l'errore. Non è che blocca tutto...
Chissà, forse è proprio un problema di postgresql. Vado a documentarmi
su come si fa a riavviarlo / "sbloccarlo" nel caso di deadlock!

Post by Renaissance
D'accordo con te comunque che sia strano che un deadlock, che dovrebbe
solo "incantare" due o piu' processi, impalli cosi' il resto del
sistema...

Non ho trovato la soluzione, ma almeno un po' di solidarietà... Almeno
qualcosa!

Post by Renaissance
bye G.L.

Ciao

[CtRiX]

Post by Michele Petrazzo
Ma pg, come da specifiche (file transactions.pdf) dice che se non riesce
a ricevere il lock perché trova il dead-lock, ritorna e segnala
l'errore. Non è che blocca tutto...
Chissà, forse è proprio un problema di postgresql. Vado a documentarmi
su come si fa a riavviarlo / "sbloccarlo" nel caso di deadlock!

Perdi tempo.
Postgres non deadlocka e se lo facesse, non tirerebbe giù la macchina.

[Vide]

Post by Michele Petrazzo
Altra informazione utile, credo, è che munin mi dice che da un po' prima
(circa 1 ora, dal grafico non si capisce molto bene) netstat, numero di
processi, vmstat running load sono aumentati vertiginosamente fino a
quando il tutto si è bloccato. Netstat, da 20 a 200, processi: 120 ->
400, vmstat running: 1 -> 40, load: 1 (neanche) -> 30.

Swap? Perchè quando a un server che sta lavorando per bene finisce la swap
(per un memory leak o simile), succedono generalmente brutte cose.

[Michele Petrazzo]

Altra informazione utile, credo, è che munin mi dice che da un po'
prima (circa 1 ora, dal grafico non si capisce molto bene) netstat,
numero di processi, vmstat running load sono aumentati
vertiginosamente fino a quando il tutto si è bloccato. Netstat, da
20 a 200, processi: 120 -> 400, vmstat running: 1 -> 40, load: 1
(neanche) -> 30.

Swap? Perchè quando a un server che sta lavorando per bene finisce
la swap (per un memory leak o simile), succedono generalmente brutte
cose.

Nulla di significante, anzi. L'unica che è aumentata da praticamente
qualche decina di mega a 700/800 è quella indicata come apps da munin

Michele

[Vide]

Post by Michele Petrazzo
Nulla di significante, anzi. L'unica che è aumentata da praticamente
qualche decina di mega a 700/800 è quella indicata come apps da munin

Ci metteresti la mano sul fuoco? Il log del kernel dice qualcosa di
interessante?

[Michele Petrazzo]

Post by Vide

Post by Michele Petrazzo
Nulla di significante, anzi. L'unica che è aumentata da
praticamente qualche decina di mega a 700/800 è quella indicata
come apps da munin

Ci metteresti la mano sul fuoco?

Quella di munin, si! :)

Post by Vide
Il log del kernel dice qualcosa di interessante?

Ho il log girato su un syslog server esterno alla macchina stessa e la
non c'era nulla.

[CtRiX]

Post by Michele Petrazzo
ERROR: deadlock detected
CEST DETAIL: Process 3497 waits for ShareLock on transaction 8104365;
blocked by process 3514.

Il lock di postgres è conseguenza di quanto successo prima.
Controlla, come ti hanno suggerito, la memoria nel caso tu ne abbia
utilizzata troppa.

Poi di limiti ne puoi impostare quanti ne vuoi.
Postgres ha una impostazione sulle connessioni massime, apache pure, i
server di posta pure.

Se poi usi un virtual server in hosting da qualche parte e la SAN va a
donne perdute, non c'è nulla che tu possa fare, però.

[Michele Petrazzo]

ERROR: deadlock detected CEST DETAIL: Process 3497 waits for
ShareLock on transaction 8104365; blocked by process 3514.

Il lock di postgres è conseguenza di quanto successo prima.
Controlla, come ti hanno suggerito, la memoria nel caso tu ne abbia
utilizzata troppa.
Poi di limiti ne puoi impostare quanti ne vuoi.

A livello di os?

Postgres ha una impostazione sulle connessioni massime, apache pure,
i server di posta pure.

Ok. Ma stiamo parlando sempre a livello applicativo. Ma visto che io non
so che applicativo è stato (se è stato un applicativo), credo sia
inutile mettere dei limiti a caso in giro.
Tanto più che ho diverse decine di applicativi scritti da noi che girano
sul quel server. E no, non sono loro, visto che sono attivi da qualche anno.

Michele

[CtRiX]

Post by Michele Petrazzo

ERROR: deadlock detected CEST DETAIL: Process 3497 waits for
ShareLock on transaction 8104365; blocked by process 3514.

Il lock di postgres è conseguenza di quanto successo prima. Controlla,
come ti hanno suggerito, la memoria nel caso tu ne abbia utilizzata
troppa.
Poi di limiti ne puoi impostare quanti ne vuoi.

A livello di os?

Anche. Ulimit è tuo amico.

[Michele Petrazzo]

Post by Michele Petrazzo

Il lock di postgres è conseguenza di quanto successo prima. Controlla,
come ti hanno suggerito, la memoria nel caso tu ne abbia utilizzata
troppa.
Poi di limiti ne puoi impostare quanti ne vuoi.

A livello di os?

Anche. Ulimit è tuo amico.

Vado. Ma chissà se riuscirò a simulare il carico per vedere se ulimit
taglia o blocca qualcosa. Indagherò.

[Manlio Perillo]

Post by Michele Petrazzo
Buon pomeriggio,
oggi mi è successa una brutta cosa: un server (in produzione) mi si è
bloccato e non rispondeva più, ne rete (ssh/ping), ne console seriale o
fisica. Bello bloccato direi...
Andando a frugare nei log dei vari software in produzione / demoni, ho
potuto vedere che il problema è nato (credo, non ne sono sicuro) da
postgresql v. 8.3
ERROR: deadlock detected
CEST DETAIL: Process 3497 waits for ShareLock on transaction 8104365;
blocked by process 3514.

Io cercherei di risalire a chi apparteneva quel processo, o almeno quale
applicativo ha effettuato la query in quella transazione.

Post by Michele Petrazzo
Altra informazione utile, credo, è che munin mi dice che da un po' prima
(circa 1 ora, dal grafico non si capisce molto bene) netstat, numero di
processi, vmstat running load sono aumentati vertiginosamente fino a
quando il tutto si è bloccato. Netstat, da 20 a 200, processi: 120 ->
400, vmstat running: 1 -> 40, load: 1 (neanche) -> 30.

Non è che magari un tuo qualche applicativo ha cominciato a creare molte
connessioni al database, mandando tutto in stallo?

Al database accedono solo applicazioni web?
Hai controllato se una di queste applicazioni ha ricevuto molte richieste?

Post by Michele Petrazzo
[...]

Ciao Manlio

[Michele Petrazzo]

Post by Manlio Perillo

ERROR: deadlock detected CEST DETAIL: Process 3497 waits for
ShareLock on transaction 8104365; blocked by process 3514.

Io cercherei di risalire a chi apparteneva quel processo, o almeno
quale applicativo ha effettuato la query in quella transazione.

Nel pezzo di log che non ho postato c'era effettivamente un "bella"
query, nostra, che mi ha fatto risalire al programma incriminato. Ma è
un "semplice" update con tanti, tanti dati.

Post by Manlio Perillo

Altra informazione utile, credo, è che munin mi dice che da un
po' prima (circa 1 ora, dal grafico non si capisce molto bene)
netstat, numero di processi, vmstat running load sono aumentati
vertiginosamente fino a quando il tutto si è bloccato. Netstat,
1 (neanche) -> 30.

Non è che magari un tuo qualche applicativo ha cominciato a creare
molte connessioni al database, mandando tutto in stallo?

Abbiamo ragionato su questo e non credo, anche se... Più o meno tutti
gli script fanno delle query limitate in numero, agiscono di conseguenza
ed il programma si chiude.
Forse, e dico forse, pg andando in deadlock, bloccava (senza però
mandare in timeout) tutti i processi seguenti e quindi si, poi tutto è
esploso.
A parte mettere un timeout (chissà se si può, poi) a livello di codice,
quello che mi fa rimanere perplesso è che l'os abbia continuato
imperterrito a far eseguire processi, fino all'implosione.

Altra cosa che mi fa pensare, anche se non legata, è che su un altro
piccolo (ma veramente limitato di risorse) ho un apache che fa vedere
qualche pagina web dinamica (no, non è pubblico) e nel log:
Jun 8 09:01:19 kernel: Out of memory: kill process 12998 (apache2)
score 24863 or a child
Jun 8 09:01:19 kernel: Killed process 27897 (apache2)
<-cut->
poi c'è un oom-killer ed un Call Trace:

Quindi il kernel è capace di killare processi.... Ma perché nell'altro
server non l'ha fatto?! Argh!

Post by Manlio Perillo
Al database accedono solo applicazioni web? Hai controllato se una
di queste applicazioni ha ricevuto molte richieste?

Niente servizi web.
Tanti dati raccolti continuamente e tanti programmi che a scadenze
regolari macinano, e macinano...

[CtRiX]

Post by Michele Petrazzo
Forse, e dico forse, pg andando in deadlock, bloccava (senza però
mandare in timeout) tutti i processi seguenti e quindi si, poi tutto è
esploso.

1) se postgres ha un deadlock, il problema è dell'applicazione che lo
usa, non di postgres (mi è accaduto oggi con unprogramma multithread
pesante)
2) quando postgres deadlocka, le funzioni chiamate ritornano un errore.
Se il programma che usa postgres non gestisce l'errore, il problema non è
di postgres.

Post by Michele Petrazzo
A parte mettere un timeout (chissà se si può, poi) a livello di codice,
quello che mi fa rimanere perplesso è che l'os abbia continuato
imperterrito a far eseguire processi, fino all'implosione.

3) è normale che un processo senza limiti, se continua a succhiare
memoria, ti secchi la macchina.
Interviene l'oom-killer che uccide a casaccio e ti sega praticamente
tutto.

Post by Michele Petrazzo
Quindi il kernel è capace di killare processi.... Ma perché nell'altro
server non l'ha fatto?! Argh!

Se non l'ha fatto, allora il problema non è il consumo di memoria.

[Giuseppe Della Bianca]

CtRiX wrote:

]zac[

Post by CtRiX
3) è normale che un processo senza limiti, se continua a succhiare
memoria, ti secchi la macchina.
Interviene l'oom-killer che uccide a casaccio e ti sega praticamente
tutto.

]zac[

In realtà non è casaccio, di solito chiude i programmi che stanno usando più
memoria/risorse, peccato che nella maggior parte dei casi siano i programmi
che si ritengono fondamentali per servizi erogati dal server (in sintesi db,
mail, http, ecc., server).

[CtRiX]

Post by Giuseppe Della Bianca
In realtà non è casaccio, di solito chiude i programmi che stanno usando
più memoria/risorse, peccato che nella maggior parte dei casi siano i
programmi che si ritengono fondamentali per servizi erogati dal server
(in sintesi db, mail, http, ecc., server).

Eh, teoricamente!
Fra il dire e il fare c'è di mezzo "e il"...
anche la priorità dei processi ha la sua importanza, ad ogni buon conto,
più della memoria.

Le policy dell'oom-killer comunque cambiano di kernel in kernel, anche
queste più o meno a casaccio, e ho deciso che l'oom-killer non serve ad
una banana e che fa più danni che altro.

[Giuseppe Della Bianca]

CtRiX wrote:

]zac[

Post by CtRiX
Le policy dell'oom-killer comunque cambiano di kernel in kernel, anche
queste più o meno a casaccio, e ho deciso che l'oom-killer non serve ad
una banana e che fa più danni che altro.

Non usare il oom-killer è sicuramente un modo sicuro per avere il kill a
casaccio, visto che dipende dal primo programma che allocato il primo byte
in eccesso.


Mi è capitato più volte che un programma incominciasse a occupare sempre più
memoria fino ad usarla tutta e cercando di andare oltre, e il oom-killer ha
sempre chiuso quel programma.


Il punto di tutto è che individuare il programma da chiudere è come il
lavoro dello scheduler, per quanto basato su regole precise, per natura
stessa del problema, è impossibile che la soluzione adottata vada bene per
tutte i casi possibili.


Tirando le somme, se c'è un programma che ha un netto sovrauso delle risorse
rispetto agli altri programmi il oom-killer fa il suo lavoro come da
desiderio dell'utente, se invece l'uso delle risorse è più omogeneo fra i
vari programmi ... beh allora il kill SEMBRA casuale ... mentre invece è che
non c'è un metodo perfetto per compiere la scelta.

[enoquick]

Post by Michele Petrazzo
Buon pomeriggio,
oggi mi è successa una brutta cosa: un server (in produzione) mi si è
bloccato e non rispondeva più, ne rete (ssh/ping), ne console seriale o
fisica. Bello bloccato direi...
Andando a frugare nei log dei vari software in produzione / demoni, ho
potuto vedere che il problema è nato (credo, non ne sono sicuro) da
postgresql v. 8.3
ERROR: deadlock detected
CEST DETAIL: Process 3497 waits for ShareLock on transaction 8104365;
blocked by process 3514.
Altra informazione utile, credo, è che munin mi dice che da un po' prima
(circa 1 ora, dal grafico non si capisce molto bene) netstat, numero di
processi, vmstat running load sono aumentati vertiginosamente fino a
quando il tutto si è bloccato. Netstat, da 20 a 200, processi: 120 ->
400, vmstat running: 1 -> 40, load: 1 (neanche) -> 30.
Non vi chiedo di dirmi perché il tutto è successo :), ma secondo voi
cosa si può fare per evitare che se per un qualsiasi motivo un software
o qualsiasi altro accrocchio che gira sul server fa casini, non mandi a
donnine il server intero?
debian con kernel 2.6.30
Michele

Oltre a limitare le risorse dei processi, come suggerito da vari post
sopra, e tenendo conto che i syslog non si leggono spesso e quindi si
interviene quando qualche utente si lamenta, si puo configurare syslog
in modo che in caso succeda un problema invii una email o un sms a uno o
piu responsabili.
Altra soluzione, ma piu costosa , due macchine in cluster;
se una delle due si impalla l' altra continua a funzionare.

[Michele Petrazzo]

Post by enoquick
Oltre a limitare le risorse dei processi, come suggerito da vari post
sopra, e tenendo conto che i syslog non si leggono spesso e quindi si
interviene quando qualche utente si lamenta, si puo configurare syslog
in modo che in caso succeda un problema invii una email o un sms a uno o
piu responsabili.

E che cosa dovrei vedere?
I log li vedo non molto molto spesso, ma non così di rado. Così come le
statistiche di munin.

Post by enoquick
Altra soluzione, ma piu costosa , due macchine in cluster;
se una delle due si impalla l' altra continua a funzionare.

E se ti dico che c'era, ma visto che la prima funzionava bene e non si
*era* mai bloccata è stata usata da un'altra parte?!

[enoquick]

Post by Michele Petrazzo

Post by enoquick
Oltre a limitare le risorse dei processi, come suggerito da vari post
sopra, e tenendo conto che i syslog non si leggono spesso e quindi si
interviene quando qualche utente si lamenta, si puo configurare syslog
in modo che in caso succeda un problema invii una email o un sms a uno o
piu responsabili.

E che cosa dovrei vedere?
I log li vedo non molto molto spesso, ma non così di rado. Così come le
statistiche di munin.

Mi sono sbattuto per darti una risposta ragionevole ed aiutarti
e tu pretendi che il sottoscritto conosca la tua situazione nonchè abbia
una palla di cristallo per capire il tuo mondo
PLONK

Post by Michele Petrazzo

Post by enoquick
Altra soluzione, ma piu costosa , due macchine in cluster;
se una delle due si impalla l' altra continua a funzionare.

E se ti dico che c'era, ma visto che la prima funzionava bene e non si
*era* mai bloccata è stata usata da un'altra parte?!

Idem

[Michele Petrazzo]

Post by enoquick
Oltre a limitare le risorse dei processi, come suggerito da vari
post sopra, e tenendo conto che i syslog non si leggono spesso e
quindi si interviene quando qualche utente si lamenta, si puo
configurare syslog in modo che in caso succeda un problema invii
una email o un sms a uno o piu responsabili.

E che cosa dovrei vedere? I log li vedo non molto molto spesso, ma
non così di rado. Così come le statistiche di munin.

Mi sono sbattuto per darti una risposta ragionevole ed aiutarti e tu
pretendi che il sottoscritto conosca la tua situazione nonchè abbia
una palla di cristallo per capire il tuo mondo PLONK

Non so cosa posso aver detto di tanto sgarbato, ma credimi non era mia
volontà.
La domanda "E che cosa dovrei vedere", era fatta perché effettivamente
non so che cosa cercare in più di quello che ho già visto, cioè tutti i
log...

Michele