Newsgroup: it.comp.os.linux.sys
Titolo: Zombi

Ciao a tutti,
ho un sistema che effettua circa 10.000 controlli di rete via snmp ogni 5 
minuti. Guardando con top vedo picchi di 300/400 task ed un numero di zombie 
che varia da poche unita' a diverse decine.
Il sistema ha 2,5GB di ram e ne usa 2GB, 4 processori che con top variano 
tra 5% e 20% in sy.
Sto impazzando a cercare tracce di malfunzionamenti ma non riesco a trovare 
niente.
Avete qualche suggerimento?
Grazie
-- 
************** (.)_(.) **************
 Un amico � uno che sa tutto di te e,
 nonostante questo, gli piaci
(E. Hobbard)
Non amo mischiare il divertimento
con la vita di tutti i giorni ma questo e' un caso
che credo debba essere portato alla
conoscenza di tutti perche' tutti possono fare la stessa fine
(
http://www.arezzonotizie.it/index.php?option=com_content&task=view&id=68808&Itemid=2
)

 Avete qualche suggerimento?
10000/300 ~= 33
Che tu veda da qualche unità a qualche decina di processi zombie è 
normale quando un sistema effettua dei fork().
L'importante è che questi zombie dopo poco spariscano e non rimangano li 
appesi all'infinito.
Di grazia, di che programma si tratta ?

 Di grazia, di che programma si tratta ?
Sono script perl che interrogano diversi aspetti di apparati di rete. Sono 
circa 2800 apparati tra router, switch, access point, call manager, alcuni 
server, unity, ed altre cose un po' strane per una media di 5/6 controlli 
per ogni oggetto. Gli script sono volutamente piccoli e veloci, ma sempre di 
una notevole mole di lavoro si parla.
Ciao
-- 
************** (.)_(.) **************
 Un amico è uno che sa tutto di te e,


 Sbaglio?
Probabilmente il sistema e` talmente carico che top (o ps o chi per loro) 
hanno visto gli zombi prima che il sistema potesse ripulire la tabella dei 
processi. Qualche secondo dopo probabilmente quello zombi era sparito (e 
magari ce n'erano altri).
Se spariscono da soli, vai tranquillo. :)
Bye.

 Sbaglio?
Uno zombie e' un processo figlio che e' terminato, ma il padre non ha ancora 
eseguito wait() o equivalente per leggere l'exit status ("reaping", con una 
metafora un po' macabra).
Non so come sia organizzato il tuo sistema, ma per esempio se tu esegui "ps" 
in un momento in cui alcuni figli sono terminati ma il padre non ha ancora 
fatto wait(), vedrai degli zombie. Se, come hai detto, poi spariscono, 
allora potrebbe semplicemente essere che il padre non fa wait() in modo 
sincrono, oppure lo fa in un certo ordine (non corrispondente all'ordine di 
terminazione dei figli), etc. L'importante e' che alla fine, in un tempo 
ragionevole, tutti gli zombie vengano "reaped".
Questo in generale, poi come dicevo dipende da cosa il codice fa nello 
specifico.

 Sbaglio?
Si.
(hint: "what is a zombie process" su google e premi "mi sento fortunato")

 Sbaglio?
Sì, stai sbagliando. L'errore non è nella forma delle parole (la definizione 
di zombi va bene) ma nella loro comprensione; è normale che un processo 
possa diventare uno zombi e ciò non comporta una condizione di errore. Un
processo ha bisogno di un certo tempo ragionevole per terminare 
correttamente e se fa dei fork od alloca delle risorse deve comunicare ai 
processi figli di terminare ed al sistema operativo di liberare le risorse 
ed una volta fatto può terminare senza aspettare che i sottoprocessi 
terminino o che le risorse siano liberate perché questo non gli è richiesto.
Quindi può capitare che diventi uno zombi; è una condizione da segnalare ma 
non causa di per sé un errore.
 

 ha scritto nel messaggio 
news:4ac5d363$0$1100$4faf...@reader3.news.tin.it...

Ok mi e' chiaro dove ho sbagliato e quindi, se stavolta ho compreso bene, 
non trovo problemi perche' probabilmente non ce ne sono.
Grazie a tutti


 Grazie
Per eliminare il problema eviterei l'uso di tanti processi; invece 
cercherei un programma che effettua query SNMP in modo asincrono, usando 
un solo processo/thread.
Saluti  Manlio Perillo

"Manlio Perillo" <manlio_p...@SPAMlibero.it> ha scritto nel messaggio 
news:tNkxm.74106$9f6....@twister1.libero.it...

Comunque farebbe tante fork per ogni interrogazione per cui non credo che 
risolverebbe il problema (che poi non sembra essere un problema).
Ciao
-- 
************** (.)_(.) **************
 Un amico è uno che sa tutto di te e,


 risolverebbe il problema (che poi non sembra essere un problema).
No, farebbe UNA fork (o forse nessuna; dipende dall'implementazione) per 
ogni interrogazione, attendendo che tale interrogazione finisca prima di 
passare alla successiva.
Probabilmente pero' tale approccio non parallelo richiederebbe troppo tempo 
per completare l'intera serie di check.

 passare alla successiva.
Ops chiedo scusa, avevo letto "sincrono" anziche' "asincrono". Comunque 
rimane il fatto che non necessariamente dovrebbe usare tante fork, potrebbe 
fare tutto in un singolo processo/thread come gia' detto.

 fare tutto in un singolo processo/thread come gia' detto.
No scusa il presupposto deve rimanere valido altrimenti non serve. Ho 10.000 
in 5 minuti quindi, anche spalmandoli omogenamente nel tempo deve farne + di 
30 al secondo. Considerando che per quanto veloci un paio di secondi durano, 
deve effettuare comunque circa 100 thread.
-- 
************** (.)_(.) **************
 Un amico � uno che sa tutto di te e,




Dipende anche dal sistema/linguaggio/framework che usi.
Ad esempio con Twisted Python, usi un solo thread.
Con Erlang, il runtime può mappare N "processi" Erlang su M threads (o 
anche su Q processi in server distribuiti).
Quel che importa, comunque, è che con tali sistemi ottimizzi i tempi di 
latenza, evitando di sprecare preziose risorse del kernel.
In Twisted il supporto a SNMP è disponibile tramite un package separato; 
in Erlang è disponibile di default in OTP:
http://www.trapexit.org/SNMP_Quick_Start
Non sono in grado dare maggiori informazioni all'OP, sia perchè non 
conosco SNMP, sia perchè non uso Erlang; ma è probabile che trovi un 
programma Erlang che faccia al caso suo.
Ciao  Manlio

 secondi durano, deve effettuare comunque circa 100 thread.
No, deve fare 30 poll/query/whatever al secondo, che possono benissimo 
essere fatte con un singolo processo/thread con I/O multiplexing o altri 
metodi.