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:


Pozdrav,
alex.

P.S - ukoliko ne mozes da se snadjes sa citanjem izlaza komande strace sacuvaj deo i posalji ovde na analizu.

Hvala.
Probacu.
Moram da sacekam da se *** nevolja zakuca, pa da ga pratim sa strace po PID.
Poslacu izlaz na analizu.
Zahvaljujem se u napred!

Dakle, evo ga mali gad OPET.
Ovog puta imam i razne karakteristike, pa ako moze pomoc, bilo bi super :
*********************
[root@mail root]# ps -axf|grep httpd
14122 ? R 16:40 \_ /usr/sbin/httpd
*********************
[root@mail root]# lsof -p 14122
httpd 14122 apache cwd DIR 8,4 4096 1360258 /usr/share/squirrelmail/src
httpd 14122 apache 16u sock 0,0 15962790 can't identify protocol
httpd 14122 apache 17r REG 8,4 15996 1360265 /usr/share/squirrelmail/src/download.php
httpd 14122 apache 18uW REG 8,4 2518 213623 /tmp/sess_f128ab7f13b72475d00b6dce2a710dde
httpd 14122 apache 19u IPv4 15962793 TCP moj.mail.server:49016->moj.mqail.server:imap (CLOSE_WAIT)
********************
[root@mail root]# ps u 14122
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
apache 14122 22.9 1.2 23348 12648 ? R 08:47 18:02 /usr/sbin/httpd
********************
[root@mail root]# pstack 14122
14122: /usr/sbin/httpd
----- Thread 14122 -----
0x405167ea: _fini + 0x3902a (28, 84a32fc, 8, 40523c99, 861e2e4, 83edae0) + 20
0x405313f4: _fini + 0x53c34 (84b7b5c, 84a320c, 5, bfffb7f4, 4, bfffb7f8) + 50
0x4051db79: _fini + 0x403b9 (84a22a4, bfffb84c, 1, 85b640c, 4, bfffb84c) + 550
0x40523209: _fini + 0x45a49 (84a3008, 2, 2, 0, 4, bfffbdbc) + 980
0x40520c6d: _fini + 0x434ad (8609290, 2, 4, 0, 0, bfffc75c) + 2210
0x40520c6d: _fini + 0x434ad (8378144, 2, 72697571, 6d6c6572, 826a384, bfffe9b4) + 10
0x4052d6b6: _fini + 0x4fef6 (8, 0, 3, 0, bffffb00, 0) + 1110
0x4053bf7a: _fini + 0x5e7ba (bffffb00, 845ae90, 808baab, 40149130, 82c88d4, 845c3e8) + 50
0x405387bd: _fini + 0x5affd (845ae20, 845af68)
0x0807169c: ap_pass_brigade + 0x2c (845ae20, 845af68, 3e7c, 82c8138, 82bfc90, ffffffff) + 20
0x08078e27: default_handler + 0x2a7 (82c8170, 0, 80ef608, 0, 82c8170, 845a680)
0x08065bf5: ap_run_handler + 0x35 (82c8170, 3b, 0, 82c8170, 82c8170, 0) + 20
0x0806620d: ap_invoke_handler + 0xbd (82c8170, 0, 4, 82c8170, 810943c, 82c8170)
0x080629c6: ap_process_request + 0x76 (82c8170, 4, 82c8170, 402f0857, 0, 82bbae8) + 10
0x0805e0ac: ap_process_http_connection + 0x10c (82bbae8, 82bba18, 40240c0d, 82bbae8, bffffc88, 82b9ab8)
0x0806f0d5: ap_run_process_connection + 0x35 (82bbae8, 82bba18, 82bba18, 8, 82b9a88, 82bfc90) + 30
0x08064238: child_main + 0x3f8 (8, 1, 1, 0, 0, 0) + 10
0x08064394: make_child + 0xb4 (809ddb0, 8, 0, 0, 0, 0) + d0
0x08064639: perform_idle_server_maintenance + 0x179 (809c010, bffffdf8, bffffe00, 809c010, 809ddb0, 80879a9) + 40
0x08064cd0: ap_mpm_run + 0x610 (809c010, 80c60b8, 809ddb0, 809ddb0, 4212aa40, 2) + 40
0x0806ac5f: main + 0x6bf (1, bffffed4, bffffedc, 400124b8, 1, 805db80)
0x420158d4: __libc_start_main + 0xa4 (806a5a0, 1, bffffed4, 805b6b4, 80852a8, 4000a950) + 40000138
***********************
[root@mail root]# netstat -anp|grep 14122
tcp 0 0 10.x.x.x:49016 10.x.x.x:143 CLOSE_WAIT 14122/httpd
************************
10.x.x.x je adresa mog servera.
Ovde su samo delovi izvestaja (inace bi bilo strana i strana!).
Ima li neko nekih dobrih ideja?

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

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

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