Imam RH 8.0 i Apache 2.0.40-8, sa sertifikatom webmail-u, i povremeno se javlja problem childe procesa Apache-a koji (bez nekog vidnog razloga) pocinje da "jede" procesorsko vreme (do 99%), i zakoci ceo server. Proces STOJI tako aktivan na 99% CPU time dok se ne ubije.
Ima li neko ideju sta to prouzrokuje.
Probaj stari apache (1.3.x), 2.x još nije sasvim završen i prijavljuju ljudi razne probleme, leakove i generalno veću glad za resursima koju je doneo novi dizajn.
Ne mogu.
Tako je kako je.
Ima li neka alatka da provali KO/STA povlaci taj jedan proces koji vuce CPU time kao lud?
Nadjem ja PID, ali u /proc/PID bas i nema nekih informacija o tome sta je taj proces startovalo...
Ako ima php skripti na sajtu, probaj da smanjiš maximum execution time na nivou phpa na 2-3 sekunde.
Ukoliko ni to ne pomogne i apache procesi i dalje ostaju zakucani, a nema nekog drugog server skripting jezika ili aplikacije koja se pokreće kroz cgi u apacheu, rekao bih da si baš naišao na neku nekompatibilnost u web serveru i da je to samo potvrda onoga što svi po apache mailing listama pričaju, a to je da 2.x ne ide na production servere još uvek.
Instaliraj strace i proveri sta taj proces sto jede resurse radi. Mozda je u pitanju programerska greska u nekoj od PHP skripti ili nesto slicno. Ja sam imao slican problem na jednom serveru i uz pomoc gorespomenute alatke sam otkrio da jedna od skripti iscitava podatke iz baze u beskonacnoj petlji.
Upotreba:
# strace -p <process id>
Pozdrav,
alex.
P.S - ukoliko ne mozes da se snadjes sa citanjem izlaza komande strace sacuvaj deo i posalji ovde na analizu.
Potpis
Pokusacu sa objasnjenjem koje se zasniva samo na tome da sam video ovo /usr/share/squirrelmail/src/download.php u listingu koji si dao.
Mozda ti neki korisnik skida attachment cija se velicina meri u megabajtima, pa se PHP ili Squirrelmail malo zaglupe (a zato se Apache zaglavi).
Potpis
Ne bih smeo da se zakunem ali cini mi se da se i meni javljao taj problem prilikom download-a vecih fajlova (naprimer 10 MB) dok je za PHP max memory (per script) parametar bio postavljen na oko 16 MB. cini mi se da povecavanje memorije koju moze da koristi PHP resava problem (dok ne probas sa jos vecim fajlom).
E sad, sve ovo ne bi trebalo da se desava vec PHP treba "kulturno" da pukne ali moguce da je kombinacija Apache 2.0 i nekog PHP-a izazivala ovaj problem.
Evo provereno i u praksi, mem za PHP je 64m, attachment je bio oko 55M, dakle oko 70 posle base64 encoding-a, httpd se zakucao ko bombona, uzo jedan CPU na 100% i ne pusta ... kill -HUP <pid> je pomoglo
Potpis
Uspeli smo da resimo problem tako sto smo podigli verziju Apache-a na 2.0.40, posle velike kolicine procvera da nam to nece zeznuti sistem...
Cisto da se zna da tako problem biva resen.
Ali sada naravno imamo novi :-)))
Videti novi thread!!!