|
Zastoj dok PHP skripta radi
Naleteo sam svega par puta na ovu situaciju, prilično retko, i nisam uspeo da izguglam ništa smisleno na ovu temu, pa reko' možda neko može da uleti klizeći ovde....
Imam server (klasika lamp platforma) koji, dok jedna skripta trči (bilo da je cron ili webpage), zakuca server i ostale stranice na sajtu servira po 2 minute... :1027: Pretpostavljam da je nešto na Linux/Apache nivou, da treba negde reći serveru da alocira te resurse malo bolje... :1007: Mora da kažem nešto čoveku, riba me sve u 16 zato što mu moj (prilično zahtevan) skript zakucava server, pita me kako da popravi... :lost: Ako iko ima neku ideju gde se ovo podešava, bio bih mu/joj krajnje zahvalan. |
Meni ovo lici na problem sa zakucavanjem baze (pogotovu ako ti se strane generisu dinamicki). Da pogodim, script radi nesto sa mysql bazom? :)
Ako to nije slucaj, mozes pokrenuti script sa "nice" komandom, mada bih ja radije ustanovio sto script zauzima toliko resursa (memory leak? etc). |
I meni je na to mirisalo odmah... Prvo je koristio externu bazu (na G-linku u internoj mreži), sad je baza na localhost-u... opet isto.
Skripta radi svašta: drma ogroman broj upita na bazu, šalje gomilu mejlova, povlači koješta preko HTTPa... Skripta jeste zahtevna, to stoji. Ali na svim ostalim serverima radi lepo malo sporije, a ostatak serva fercera kako treba. Ovo sam video kod njih par samo... :1089: Nažalost, skripta verovatno neće trpeti nikakve korenite izmene, s obzirom na to da se pokazala da radi kako treba na ogromnom broju instalacija... :( |
dva najbrza hak-a:
- spomenuti nice - sleep() :) |
Već radi i sleep(). :)
Samo, kod sleep-a je problem što onda skripta ne radi ništa. A čim prođe sleep....opet zakuca :( |
Pogledaj kolika je potrosnja memorije. Ako radi sa bazom onda guta svu raspolozivu memoriju. Jedno od rjesenja je dodavanje memorije. Pogledaj kolika je zauzetost procesora.
Pregledaj upite za bazu i da li su pravilno indeksirani. Ako mozes neke upite preciznije odredi ili limitiraj sa nekim uslovom. Pregledaj bazu i vidi da li mozes neke podatke koji se cesto upisuju odvojiti u posebnu tabelu, a kasnije u odredjenim razmacima prebacivati u tabelu sa koje citas. Pogledaj koliko je dopusteno maksimalno istovremenih konekcija ka bazi i koliko se u odredjenom trenutku ostvaruje. Ako je malo slobodno povecaj i preko 500, sa lakocom MySQL to izdrzava. Ovo su bez preciznih podatak neki scenariji i rjesenja mogucih uzroka. |
Pokušao sam već sve to... Upiti su optimizovani odavno, a i (napomenuo sam, mislim, ranije) da se isto ponašao i kada je baza na drugom serveru. Tada bi valjda vukao njegovu memoriju, ne web serverovu, ne? :(
Pogledaću ovo za broj konekcija ka bazi ali mislim da ima dovoljno... Skripta pravi 2 konekcije. U principu, pitanje nije uopšte gde/da li skripta škripi (zato sam stavio ovo u hosting, a ne php forum). Pitanje je kako reći serveru da čak i ako ima neku ultra-mega-giga skriptu koja mora da trči, kako da ostavi dovoljno mesta da se sva deca igraju? Zna li neko neki setting koji bi Apache-u (ili u Linuxu, za procese?) rekao da ostavi dovoljno ostalima, a ne da na jedan proces da svu svoju energiju? Ovo sam iskopao do sad: http://httpd.apache.org/docs/1.3/mod...html#rlimitcpu Ono što sam primetio u ovoj instanci je da ima MPM modul uključen, prefork i worker mu se pominju u conf-u... sad babram na tu stranu. |
prvo utvrdi sta se zapravo desava kad pokrenes skriptu.... sta kaze top, sta kaze free -m jel swapuje, ako se skripta pokrece preko apacha sta kaze /etc/init.d/httpd fullstatus (sa ukljucenim extended informacijama), takodje u mysqlu sta kaze SHOW FULL PROCESSLIST
Bitno je da vidis koji resurs je problematican (cpu, memorija, konekcije, file descriptori..), i da li je uopste u tome problem, ili mozda sam server nije ispravan, disk previse spor, etc. Moze da bude sve i svasta, ako kazes da se desava samo na tom jednom serveru. Proveri velicine bafera datih mysql-u, i podesavanje za memory limit php-u |
Možda komšijin mali traži Severinu u tom momentu...
dao si informacija toliko da pitanje izgleda ovako "Interesuje me ****** jer nisam ***** a kada ***** nema ***** osim ***** ulaz *****. Šta vi mislite o tome? |
Već sam napomenuo ranije, imam klijenta (srećom u mojoj vremenskoj zoni i još tehnički potkovan, pa konačno imam nekoga od koga mogu da tražim bilo šta smisleno) koji ima vrlo vrlo redak i specifičan problem koji očigledno leži u nekom podešenju servera. Dobio sam FTP pristup folderu skripte i uvid u conf fajlove apache-a, php-a i mysql-a. Tražio sam još koješta, čekam odgovor. Ovde ne mogu da kačim ništa preterano specifično:
- Ubuntu 5.7 - Apache 2.2.8 - PHP 5.2.4 - MySQL 5.0.26 na lokalnoj mašini, dedicated Ubuntu box sa 8GB RAM-a, od toga 4GB za MySQL kad je bio externi (ne znam verziju tamo) Javiću kad dobijem neke smislene odgovore koji isključuju bilo šta gore navedeno. Ako odgovori uopšte, ne javlja se od popodne... Nekad (ovakvi klijenti) kad nađu rešenje jednostavno ne odgovore više na tiket. I tako mi je probio timeframe koji mogu da odvojim za njega, refundiraću ga svakako ako ne radi, samo mi ćef da znam zašto koči... pitah ovde samo zato što me je zagolicala tema, iako je suludo i ovo vreme koje sam do sad potrošio na jedan problem koji se dešava u tako niskom broju slučajeva. Rekoh, možda neko zna kako/gde reći serveru da ne dozvoli jednom procesu da upucava ceo serv... Izvinjavam se ako nekome ne prija način na koji sam postavio pitanje - nisam bio u prilici sa posla da pišem previše i da se cimam oko ovoga. Sad sam kući, sad opušteno. :1042: U svakom slučaju imamo sad ovde neke vrlo korisne savete, fino popisane. Thanks svima! |
Ako se to ne desava pri svakom pokretanju te skripte moguce je da postoji i neka druga skripta na tom serveru i da se pokretanje ove dvije ili bar njihovih dijelova poklopi i na taj nacin ubije server.
Mislim da je najvaznije ovo sto je rekao ivanhoe - utvrditi prvo sta je problem tj gdje je blokada pa onda dalje. |
Do sad utvrđeno:
- ni jedan proces nije preko 3% u vreme rada skripte - nema sporih upita. kaže da odradi rafal u par sekundi, pa ćuti 15-20 sekundi, u rafalu su svi ok - ssh mu radi na oba serva (web i db) bez ikakvih problema dok skripta tera, samo web interfejs je zakucan - sar/top pokazuje idle 80-90% - request na TXT fajl na serveru (ne ide kroz PHP) se prevlači sporije u toku rada skripte nadam se da nisam propustio nešto... tražio sam gomilu stvari, dobio sam (naravno) samo par šturih odgovora... Skripta mu ima 4+ fsockopena otvorena u isto vreme, a možda i više, vrlo je moguće da je samo zagušio mrežu svetski... :( |
Citat:
|
a koji je status apache-a dok skripta radi?
jel ta gomila http upita ide na isti host ili negde u svet? |
Mislim da je problem kompleksniji od odgovora tipa "učini to i to..."
Verovatno imaš više stvari koje utiču na performanse. Da li ti radi samo jedan takav kron u isto vreme? Kakvo je zauzeće memorije. Možeš li to da meriš i ukoliko preveliš određeni nivo da isključiš skriptu. Pokretanjem sledećeg krona bi trebalo da nastavi gde je prethodna stala. Ukoliko se kucaju i ostale skripte - veb strane mogao bi u tim skriptama da ograničiš vreme trajanja na najniže moguće - recimo 4 sec. Ukoliko počnu da pucaju bolje je da imaš manji broj korisnika bez odgovora, nego ceo server koji neće moći da se oporavi dugo vremena posle... |
@bluesman:
I fsockopen i stream_set_timeout imaju 15. Izgleda da u tom (socketi) zecu čuči grm. :1016: @kodi: Ma nije, ceo server je u tip top kondiciji dok skripta tera... Namestio ga čovek da tera bez ikakvih pauza, ova jedna što sam je koristio za test cepa oko 2h, svaki dan po jednom. :) Upiti sa web serva su uglavnom u internoj mreži. @agvozden: Nije kron, web skripta je u pitanju, i Apache je u igri... :1089: Dobra je ideja za ostale skraćivanje rada ostalim skriptama. Do kraja je ispalo, dakle, da server sasvim lepo radi sve, da ima minimalan iowait (isključio čovek mogućnost grešaka po hardu odmah), nema pikova ni u memoriji ni na procesoru, ma ništa... :( Ali zato ima otvorena 4 soketa na internu mrežu, plus 2, je li, za mysql (isto interno), plus po koji tu i tamo kad radi get fajlova iz sveta. Na jedan od ova četiri uvek tera podatke praktično bez ikakvih pauza (sem što odradi provere i upite). Radi po 100 u cugu pre promene soketa. Čoveku je u interesu da radi posao što pre, da ne čeka ništa... Naravno, taj komp u mreži na čiji soket baca isto to šalje dalje, u svet... Sve u svemu, začin C. Kad se sve sabere i oduzme, tona traffica. :( Javiću ako dobijem još neki zanimljiv info. Sutra ću se verovatno igrati još malo oko njega, pingovati ga dok radi, njakati ga malo, i tako... Hvala svima još jedared. :1016: |
klijent odgovorio danas. kaže rešio je problem. :)
fsockopen-i su koristili istu internet konekciju kao i web server, nisu koristili posebnu kao što je trebalo, pa mu gušili protok ka sajtu, logično. Ispade ništa specijalno. :( S druge strane, bitno da je rešeno. :) Hvala svima još jednom na pomoći. |
Super da si rijesio problem.
Pade mi na pamet da biste mozda mogli napraviti kakav logging sistem za to proceduru tipa 'zavrsio prvi dio', 'zavrsio drugi dio' .... tako da lakse mozes lokaliozvati problematican dio. |
uh -- sorry, tek sad videh ovo, promace mi... :(
pa imamo mi logging sistem, ali on radi sve (samo) ono sto mozes iz PHP skripte... skripta je radila fsockopen() i tu se njen posao/nadleznost zavrsava... to kako radi fsockopen (tj koji socket ce koristiti) je na nivou iznad, na to ne mozemo da uticemo... osim da imamo neki poseban proces koji radi exece i perverzije i guli sistemske logove, ili nesto, da bi ocitao da li je van PHPa sve u redu... :( ako neko ima neki predlog/resenje za ovo, a da je u PHPu, please do tell! :))) |
| Vreme je GMT +2. Trenutno vreme je 19:04. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.