Php-cgi 100% Cpu

[Gość normanos]

Uh, już 3ci dzień walczę z nowym serwerem, po kolei wyeliminowałem wszystkie znane mi przyczyny i znowu jestem w punkcie wyjścia

Ale po kolei:

 

Serwer:

AMD Athlon 1,9GHz, 1GB RAM 80HDD SATA

 

Stosunkowo bardzo mały ruch, 1 główny skrypt.

100% CPU /usr/bin/php-cgi /var/www/serwis/index.php

 

I teraz:

- profiling (Xcache/KCacheGrind) zupełnie wykluczył problem skryptów

- testowanie na PHP 5.2.0-etch z paczki, potem 5.2.1, a na koniec ręcznie skompilowane 5.2.3

PHP 5.2.3 (cgi-fcgi) (built: Jul 12 2007 19:23:27)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
with eAccelerator v0.9.5.1, Copyright (c) 2004-2006 eAccelerator, by eAccelerator

- testowane na Apache 2.2.3 z paczki

- testowane na Lighttpd 1.4.13 z paczki oraz ręcznie skompilowane 1.4.15

- testowane na XCache oraz na Eaccelerator (z i bez; oba kompilowane w najnowszych wersjach)

- pod Lighttpd jako FastCGI, pod Apache jako moduł (i tam wtedy po 100% CPU miały procesy Apache)

- na drugim serwerze (mocno obładowanym) nic specjalnego sie nie dzieje

- na laptopie CoreDuo przywalenie ab -n1000 nie daje więcej php-cgi jak <10%CPU

 

POMOCY!!!

 

Macie jeszcze jakieś pomysły co z tym zrobić? Mi się już skończyły pomysły...

[T 6]

Macie jeszcze jakieś pomysły co z tym zrobić? Mi się już skończyły pomysły...

Trudno odpowiedzieć przy tak szczątkowych danych. W zasadzie napisałes tylko, że jakiś kod Ci się wykonuje na jednej maszynce niewydajnie, a na inneh wydajnie, a nie pokazałeś nawet tego kodu.

[Gość normanos]

"szczątkowe dane"? Chyba żartujesz. A tak, mogłem napisać "pomocy, nie działa mi".

 

Kod to jeden z popularniejszych frameworków, nie wkleję ci tutaj kilkuset tysięcy linii kodu Nie przeczytałeś też uważnie: 'skrypt' wszędzie uruchamia się bardzo szybko, czasy generowania są niewielkie, różnica jest w procesach; nie ma co dalej kontynuować wątku 'skryptu' (i po co ja boldowałem i podkreślałem odpowiedni fragment? ehh)

[shive 0]

Dlaczego odpalasz jako cgi?

[Gość normanos]

Dlaczego odpalasz jako cgi?

- pod Lighttpd jako FastCGI, pod Apache jako moduł (i tam wtedy po 100% CPU miały procesy Apache)

[MasterNETpl 100]

Problemu możesz równiesz szukać w zainstalowanych pakietach w systemie których php dotyczy.

error.log apacha pod różnymi levelami nic nie pokazuje?

[shive 0]

Jedyne problemy z obciążeniem na Apache jakie miałem wystąpiły ZTCP po zastosowaniu mod_security czy innego mod_dosevasive (pod Apache2). W innych przypadkach na 95% typuję, że winny jest kod.

 

Może sprawdź sobie jak śmiga pod starym dobrym Apache 1.3?

[Gość normanos]

Problemu możesz równiesz szukać w zainstalowanych pakietach w systemie których php dotyczy.

error.log apacha pod różnymi levelami nic nie pokazuje?

Ruch jest cały czas na Lightym, Apache chodził zbyt krótko i w tym czasie żadnych błędów nie wygenerował. Lighty co kilka godzin generuje "cgi died?" ale jak pisałem wyżej tu jest php-cgi, a na apache jest jako moduł więc 2 różne serwery, 2 różne php, a 100% CPU to samo.

 

Hmm, jakie pakiety masz na myśli, które mogły by być wspólne dla wszystkich tych instalacji?

 

@Shive: Apache2 jest bez podanych przez Ciebie dodatków. Apache 1.3? Cóż, z nudów mogę sie pobawić. ps. możemy zakończyć wątek kodu?

[shive 0]

Jak chcesz się bawić w szukanie błędu po stronie Apache, to na wstępie wyłącz sobie wszelkie moduły, które są zbędne do czystego wyświetlania stron i sprawdź czy nie zaskoczy.

[MasterNETpl 100]

Hmm, jakie pakiety masz na myśli, które mogły by być wspólne dla wszystkich tych instalacji?

W zasadzie to obojętnie jakich, których to skrypt/php wymaga do wykonania skryptu.

Miałem parę razy z czymś podobnym doczynienia ale na na prawdę starszych wersjach oprogramowania i starych maszynach.

W tym przypadku również dosłownie parę prostych skryptów php zajmowało 100% CPU lecz w error.log wywalało komunikaty, pomogło dopiero upgrade oprogramowania.

 

@Shive: Apache2 jest bez podanych przez Ciebie dodatków. Apache 1.3? Cóż, z nudów mogę sie pobawić. ps. możemy zakończyć wątek kodu?

Pobaw się pobaw różnymi wersjami apache oraz php.

[Gość normanos]

Prawdę mówiąc to Apache mało mnie interesuje. Doinstalowałem go tylko dlatego aby wyeliminować winę Lighttpd i php-cgi. Szukam teraz czegoś wspólnego dla tych wszystkich instalacji.

 

@Adrian: już tyle kolejnych wersji php skompilowałem, że ten punkt trzeba wykluczyć

[shive 0]

Zachęcam do sprawdzenia Apache 1.3 i kombinacji z modułami.

[patryk 451]

Skoro na jednej machinie działa super a na innej nie to tutaj wcale nie musi chodzić o Apacza i tego typu sprawy. Sprawdź dmesga i sysloga czy nie ma błędów kernela albo czy dyski nie chodzą na jakimś generic IDE driver generując 90% iowaitu (co przekłada się na load serwera). Możesz też od razu zagrać z grubej rury i skompilować go z ręki z ulubionym schedulerem, opcjami itd itp.

[Gość normanos]

Problem _chyba_ został rozwiązany. Muszę powiedzieć, że najprawdopodobniej na problem złożyło się kilka rzeczy:

 

- sam load spadł poniżej 0.7-1.0 po wyłączeniu statystyk BBClone. Nie profilowałem tych statystyk ale moim zdaniem nie powinny one stwarzać problemu w kwestii kodu PHP. Mam je na drugim serwerze w co najmniej 20 kopiach przy nieporównywalnie większym ruchu i nie stwarzają one tam żadnych problemów. Za to co powiedział Patryk wydało mi się interesujące więc dokładniej przyjrzałem się wykresom pracy hdd (tym bardziej, że te statsy opierają się na plikach txt). I rzeczywiście: ten minimalny ruch, jeden skrypt i jedne statystyki generowały 2 razy (!!!) większy zapis niż mój drugi dedyk gdzie jest chyba z 100 domen, dziesiątki różnych serwisów, for (nawet jeden przemo!) i z 20 tych statystyk. Wniosek: sam kod PHP statystyk nie wydaje się być problemem, problemem jest coś związanego z HDD. Tym samym tak jak Patryk pisał wraz z tym ogromnym read/write hdd zwiększało się obciążenie CPU.

 

- no dobra, statsy swoją drogą ale dalej load 0.7 i nagminne 50-100% CPU dla procesów php-cgi to jakaś makabra przy niesamowicie niskim ruchu (około 2-4k uu). I tutaj zaniepokoiły mnie te komunikaty w logach Lighttpd, że "mod_cgi died?". Zaraz, zaraz, mod_cgi? Dopiero teraz do mnie dotarło, że ja przecież używam mod_fcgi (FastCgi)! Od razu mi się przypomniało, że w Lightym zasadniczą sprawą jest kolejność ładowania modułów, a tutaj config mówił wyraźnie: mod_cgi był wcześniej niż mod_fcgi, a do tego miał w defaulcie ustawienia dla *.php. Zamieniłem kolejność, wyłączyłem *.php dla mod_cgi, force-reload i...

 

load average: 0.06, 0.02, 0.00

 

Szkoda, że żadne logi ani inne komunikaty nie potrafią rozróżnić czy to leci przez cgi czy fgci :/ To bym wcześniej to wyłapał.

----------------------

 

Dobra, sam problem php-cgi chyba rozwiązany. Ale dalej nie wiem co się dzieje z HDD, że te statsy aż tak wariują na tym serwerze.

Patryku, możesz mi napisać jak dokładnie sprawdzić te rzeczy o których wcześniej pisałeś? Nie bardzo się w tym orientuje. Przejrzałem logi ale nic specjalnego na temat HDD nie znalazłem, a te wartości dla tak małego ruchu w zestawieniu do mojego drugiego serwera są bardzo niepokojące.

 

----------

 

ps2. zastanawiające jest dlaczego Apache2 z php jako moduł też generował takie obciążenie. Być może nadal był tu problem z tym odczytem HDD?

[patryk 451]

Żeby sprawdzić wydajność dysków odpal hdparma, powinnien być w katalogu sbin, jeśli go nie ma doinstaluj go (nie zmieniaj ustawien dyskow gdy masz softwarowego raida - może narobić bigosu typu brak syncu macierzy itd).

 

Teraz zakładając, że Twój dysk to /dev/hda robimy małego benchmarka (najlepiej przy malo obciazonej maszynie aby bylo miarodajnie):

 

hdparm -t /dev/hda - da to wyniki odczytu i zapisu na dyskach. Odpal to na obu dedykach, aby mieć porównanie.

 

potem mozesz uruchomic hdparm -i /dev/hda

 

Dostaniesz info w rodzaju:

Model=WDC WD800BB-00JHA0, FwRev=05.01C05, SerialNo=WD-WMAM93645829

Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }

RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=66

BuffType=unknown, BuffSize=2048kB, MaxMultSect=16, MultSect=off

CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156301488

IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}

PIO modes: pio0 pio3 pio4

DMA modes: mdma0 mdma1 mdma2

UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 udma3 udma4 *udma5

AdvancedPM=no WriteCache=enabled

Drive conforms to: Unspecified: ATA/ATAPI-1 ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6

 

Ważne jest to czy włączony jest tryb UDMA, DMA czy PIO (pozdrowienia dla forum ) - nie musze chyba mówić jakie to ma znaczenie dla ew. wydajności dysku. Sam IoWait, czyli upraszczając info o tym ile zajmuje procesorowi czekanie az dyski uporaja sie z zadaniami znajdziesz w topie (tutaj akurat czwarta pozycja):

 

 

Cpu(s): 17.8%us, 2.8%sy, 0.2%ni, 78.8%id, 0.0%wa, 0.2%hi, 0.2%si, 0.0%st

 

Jeśli masz dyski SATA/SCSI parametry ustawien zmienisz dzieki sdparm (zamiast hdparm). To chyba tyle .

[Gość normanos]

Wielkie dzięki za pomoc.

hdparm -t /dev/hda - da to wyniki odczytu i zapisu na dyskach. Odpal to na obu dedykach, aby mieć porównanie.

/dev/hda:
Timing buffered disk reads:  152 MB in  3.00 seconds =  50.60 MB/sec
------------
/dev/sda:
Timing buffered disk reads:  154 MB in  3.13 seconds =  49.24 MB/sec

 

potem mozesz uruchomic hdparm -i /dev/hda

 Model=HDS728080PLAT20, FwRev=PF2OA21B, SerialNo=PFD210S2RJ4WLE
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=51
BuffType=DualPortCache, BuffSize=1719kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=160836480
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes:  pio0 pio1 pio2 pio3 pio4 
DMA modes:  mdma0 mdma1 mdma2 
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 udma3 udma4 udma5 *udma6 
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: ATA/ATAPI-7 T13 1532D revision 1:  ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6 ATA/ATAPI-7

[patryk 451]

Czyli jak widać wyniki dysków są porównywalne na obu maszynach, możesz wykluczyć problemy z nimi jako ew. powód problemów (choć wynik cached reads tez jest wazny - a akurat go nie podales).

[Gość normanos]

czyli niezła zagwostka z tym drugim serwerem

 

cached reads? gdzie to?

 

Cpu(s): 2.6%us, 4.0%sy, 0.0%ni, 93.4%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

 

?

[beliq 442]

aby odczytać cached reads musisz dodać jeszcze switch T do polecenia hdparm,

tak więc... hdparm -tT /dev/dysk

[Gość normanos]

dzięki. o, i tu są znaczne różnice:

 

Stary serwer:

Timing cached reads: 2058 MB in 2.00 seconds = 1029.16 MB/sec

 

Nowy serwer:

Timing cached reads: 556 MB in 2.00 seconds = 277.60 MB/sec

[shive 0]

Czyli to wina skryptu :]

[Gość normanos]

Czyli to wina skryptu :]

ten wolny dysk? LOL. ciekawy tok rozumowania

[shive 0]

Ciekawy tok rozumowania to chyba Twój jest, skoro uważasz, że skrypt będący w stanie zarżnąć dysk jest w porządku... jeśli to jakiś program napisany wybitnie w celu obróbki danych na dysku to, po pierwsze, PHP jest kiepskim wyborem, a po drugie każdy dysk będzie przy nim leżał bo zawsze będzie oczekiwanie na odczyt/zapis, zwłaszcza na serwerze który realizuje w tym samym momencie sto innych żądań. Natomiast jeśli to skrypt bardziej w stylu WWW, to jest po prostu do bani skoro jedzie w ten sposób po dysku.

 

Ostatnią rzeczą, którą bym podejrzewał w przypadku kiepskiej wydajności PHP jest problem sprzętowy

[Gość normanos]

Idąc twoim tokiem rozumowania to zawsze winny jest skrypt bo cham jeden odpala się w ogóle i coś robi wredniak jeden. To raz.

 

Dwa: juz drugi raz w tym wątku drażni mnie brak czytania ze zrozumieniem. Wiem, że w Polsce jest z tym coraz gorzej, ale żeby aż tak? Specjalnie dla Ciebie zrobię uproszczoną wersje: winnym był mod_cgi. Wyłączenie statystyk poprawiło wydajność o jakieś 30% przy czym z zupełnie innych powodów. Co więcej te statystyki mam na drugim serwerze w ilości co najmniej 20 instalacji przy co najmniej 50 razy większym ruchu i serwer ani sie nie spoci z nimi, a jazda po dysku jest 2 razy mniejsza. Jeżeli dla ciebie brak w tym logicznych przesłanek do uznania skryptu przynajmniej za neutralnego w tym problemie to szczerze współczuje. Jak bardzo chcesz to mogę specjalnie dla ciebie zrobić profiling tych statystyk i w 100% wyeliminować je z tego sporu.

 

Dzięki dla Patryka za konstruktywne porady.

[patryk 451]

Normanos, pokaż jeszcze output hdparm /dev/dysk z serwera, który chodzi wolniej - jeśli zobaczysz tam cos w rodzaju multcount = 0 (off) I/O support = 0 (default 16-bit) unmaskirq = 0 (off) to jest duza szansa dodac troche pary temu dyskowi przez zmiane tych ustawien.

 

BTW. HDS728080PLAT20 wyglada mi na standardowy dysk EIDE by Hitachi w serwerach LayeredTecha (paradoksalnie pakuja cos co sie nazywa "DeskStar" do serwerow - te dyski sa wytrzymale, w ciagu 3 lat padl mi 1 na jakies 20 sztuk dysków 40 GB i 80 GB od Hitachi, ale z wydajnoscia to nie jest za dobrze..).