Newsgroup: it.comp.os.linux.sys
Titolo: Server bloccato causa postgresql deadlock (credo)

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

 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. 
-- 
Vide

 
Michele

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

 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ò.

 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.
-- 
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen

 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?
-- 
Vide


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

 bye G.L.

 A livello di os?
Anche. Ulimit è tuo amico.
 

 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...


 [...]
Ciao  Manlio


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.

 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.


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


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

 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?!

 bye G.L.
Ciao

 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.

 server non l'ha fatto?! Argh!
Se non l'ha fatto, allora il problema non è il consumo di memoria.
 


Idem


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

 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).

 (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.

 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.