Uf, nije bas lako naci sta to tada radi.

Ali ajde ovako probaj da nadjes neki proces koji je u "D" stanju, garant je zbog njega, vidi sta kaze dmesg, a i stavi vmstat 1 u nekom prozoru da gledas.

Ali da ti kazem ja ovako ljudski, uradi backup, startuj smart i prebaci sve na drugu masinu.

90% verovatnoce da je otisao disk ili kontroler ili pak se nesto .... Sve mi to lici na to :).

Hmz, reinstalacija nije moguca, u pitanju je dedicated server :)
Ukoliko pak mogu da dokazem da je hardware u pitanju, mogu da trazim da zamene deo koji ne valja, ali dakako moram imati dobru osnovu za to.

E, sad, sta znaci 'proces u 'D' stanju'? Da to gledam u top-u?
dmesg kaze svasta po nesto, ali koliko mi se cini ne prijavljuje nigde greske (hardwerske ili bilo koje druge).

posmatracu sa vstat 1 kada ponovo primetim da se zakuca.

Ajde ovako jedno pitanje, ono sto sumnjam da moze biti. Apache (PHP) uploaduje fajlove, izmedju 20 i 100 MB velike. PHP funkcionise tako da prvo fajl smesta u /tmp a odatle ga kopira na drugu (stalnu) lokaciju. Moze li biti, da recimo 4 korisnika istovremeno zavrse upload, da onda disk treba da prebaci 400 MB podataka i da CPU ceka zbog toga?! Ono, mozda bash trazim nesto sto nije, mozda sam i odvalio nesto, ali ne znam sta da radim vise :(

Poz,
Sale

Da to moze da bude, ono wa je ustvari iowait (to jest procesor ceka da se zavrsi rad sa diskom). U tom slucaju ce vmstat 1 da ti da objasnjenje, pusti i posmatraj dosta dugo.

D u ps je : Uninterruptible sleep (usually IO) Obicno se javi na kratko kada je disk zagusen, ali i na duze ako j e disk otisao (bila jedna masina na kojoj se scsi kontorler otkaci tako sa vremena na vreme i posle 5 minuta dodje sebi (load skoci na 200-300), nekada se zagusi potpuno, samo reboot -f -n radilo :).

Ok, sada znam gde da trazim uzrok i eventualno da optimalizujem proces PHP-a pisanja na disku...

Posto ne znam kada je tacno zagusenje, videcu da zapisujem output vmstat -1 negde, pa da ga pregledam 24 casa kasnije. Ako neko zna elegantije resenje, slusam :)

Poz,
Sale

PS. sta se moze jos uciniti povodom optimalnije upotrebe diska? Koji procesi su zahtevni po disk (od cesto koriscenih) i slicno? Posto imam 2 diska u serveru, mogu li videti koliko je jedan / oba zauzeti, pa da eventualno raspodelim svrljanje na 2 (posto verujem da se jedan sada ubija od rada, dok drugi zvrji prazan)...

Daklem, definitivno je IO (hdd) krivac za kocenje celokupnog rada servera. Evo sta je vmstat pokazao:

r b swpd free buff cache si so bi bo in cs us sy id wa
1 2 144972 2820 12444 135788 0 0 3092 157 1671 2263 2 2 0 96

Dakle, kada je wait na 96%, bo (blocks received) je otisao na 3000+. Poredjenja radi, kada je server 'miran' slika je ovakva:

r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 144972 33532 6276 116348 0 0 13 131 1197 885 0 1 99 0

Logicno, sledece pitanje je, sta mogu da ucinim povodom ovoga? Verovatno je kriv PHP koji uploadovan fajl prebacuje iz tmp direktorijuma u drugi direktorijum. Tu se radi o fajlovima od 20 do 100 MB velicine.

Ja cu da pogledam moze li PHP da optimalizuje ovaj proces, ali mi treba i generalni savet oko ovoga :)

Poz,
Sale

Za pocetak vidi sta kaze hdparam -tT /dev/[sh]d[a-f] koji ti je vec disk.

Ako je rezultat normalan, kod mene je recimo:



Ako je to u redu, onda da vidimo filesystem, koji je za pocetak da krenemo i u tom pravcu.

Znaci detektovali smo spor rad diska, i izbacili smo da je u pitanju greska (dmesg je cist).
Preostaje da je disk neki stari pa samim tim spor, ili mozda filesystem zeza. Dakle koji je fs tu ? I sta to radi taj PHP, prost upload ili ...

Naravno ima jos jedna situacija kada disk poludi, ali to ne na svim kernelima i svim fs-ovima, ali simulacija je sledeca: pustim sa axelom da dovlacim nesto u 20 konekcija, recimo neki iso image. axel otvori 20 konekcija, i napravi veeeeeeeeeliki file (velicine tog iso-a), ali pazi sada: kada kucas sa ls *.iso dobijes velikuuuuuu velicinu :), a kada kucas du *.iso dobijes malooooooooo. To jest ako creiras file pa se telujes na 1Gb, on ce nekako da ga popuni nulama (ne fizicki nego ...). i kasnije kada radis popunjavanje, on ce dosta sporo da radi (ne znam sta radi, ali rezlutat je da dobijes na kraju file, koji je ok, ali se strasno sporo cita i kopira (kao da su "sektori" izpremestani). E da nije taj slucaj.

I naravno zadnji ali malo verovatan, mozda ti ukljucena neka online kompresija na file systemu.

E sada videh, ti ustvari radis mv iz /tmp-a negde drugde, a kako to nije isti fs, onda on kopira pa brise, zar nije najlakse da za pocetak /tmp izlinkujes odma na particiju gde zelis da iskopira krajni rezlutat :).

P.S. Ovo ce te kostati definitno rucka :).


_{[Ovu poruku je menjao chupcko dana 27.02.2006. u 22:45 GMT+1]}

Umesto da /tmp bude na harddisku, mozes i da mountujes tmpfs (ovo naravno ako masina ima dovoljno RAMa). Nece biti problema koje sada imas, a sa druge strane, postedeces sebe posla oko povremenog ciscenja /tmp-a.

Evo ovako, ovo su rezultati hdparm:



2 x sam ih radio...

Sto se tice raspodele, pojma nemam kako je to uradjeno :S Drugi disk je naknadno stavljan... df -h daje sledece:



a mount:



Uopste ne iskljucujem da je totalno i sve pogresno postavljeno, posto sam jos amater za ove stvari :)

tmpfs nisam koristio do sada... i mount-e ne razumem jos u potpunosti, ali citam dosta ovih dana o tome :)

Poz,
Sale

ps. kako da vidim jel ukljucena kompresija fs-a? I kako je, teoretski, idealno da drzim umesto /tmp ? thx ;)