Dziwny problem z apache

[denis94 0]

Witam.

Posiadam portal na którym w godzinach szczytu przebywa około 1800-2500 użytkowników.

Serwer na którym to stoi to serwer vps.

 

Średnie zużycie ramu w ciągu dnia to około 45%.

Zużycie ramu w godzinach szczytu około 60%

 

Mój problem polega na tym, że serwer www czasami w ciągu kilku minut powoduje raptem 100% zużycie ramu i utrzymuje się do tej pory, dopóki nie przeładuję usługi httpd. Gdy tylko to zrobię problem po kilkunastu sekundach ustępuje i zużycie ramu spada do normalnego poziomu. Podczas tak wysokiego zużycia ramu strona nie ładuje się lub zwraca błąd 500.

Najdziwniejsze jest w tym wszystkim to, że nie dzieje się to tylko w godzinach szczytu. Czasami występuje to nawet wczesnym rankiem gdy ruch jest najmniejszy.

Logi nie wykazują żadnych nadzwyczajnych działań czy ataków tym bardziej, że po przeładowaniu (nie zresetowaniu) httpd wszystko wraca do normy.

 

Bywa, że czasami są dwa tygodnie przerwy w występowaniu tego problemu, a czasami bywa, że dzieje się to 2-3 razy dziennie.

 

Proszę o pomoc lub naprowadzenie na przyczynę problemu. Może ktoś spotkał się z czymś podobnym?

Edytowano Luty 6, 2013 przez denis94 (zobacz historię edycji)

[Pan Kot 1535]

Ciężko będzie coś więcej powiedzieć, może to być jakiś długi keepalive, jakiś skrypt może się zloopować bądź jesteś zwyczajnie atakowany jakimś slowlorisem.

 

Poleciłbym zacząć od skrócenia keepalive'a i timeoutu dla php i zmierzyć parę dodatkowych rzeczy podczas takiego "skoku", cokolwiek co może nas nakierować, logi z access'a na pewno nam mogą pomóc, tak samo jak logi php czy nawet liczba threadów apache'a (o ile używasz prefork'a).

[denis94 0]

Ok dzięki za wskazówki. Timeouty zmniejszone. Jak tylko znów będzie skok to pozbieram logi.

[denis94 0]

Znów miała miejsce ta sytuacja.

 

Logi:

 

Apache Access Log - brak jakichkolwiek niepokojących.

 

System Messages

Feb 12 20:10:44 xyz freshclam[1368]: Received signal: wake up
Feb 12 20:10:44 xyz freshclam[1368]: ClamAV update process started at Tue Feb 12 20:10:44 2013
Feb 12 20:10:44 xyz freshclam[1368]: main.cld is up to date (version: 54, sigs: 1044387, f-level: 60, builder: sven)
Feb 12 20:10:44 xyz freshclam[1368]: daily.cld is up to date (version: 16670, sigs: 759792, f-level: 63, builder: ccordes)
Feb 12 20:10:44 xyz freshclam[1368]: Current functionality level = 61, recommended = 63
Feb 12 20:10:44 xyz freshclam[1368]: Please check if ClamAV tools are linked against the proper version of libclamav
Feb 12 20:10:44 xyz freshclam[1368]: DON'T PANIC! Read http://www.clamav.net/support/faq
Feb 12 20:10:45 xyz freshclam[1368]: bytecode.cld is up to date (version: 210, sigs: 39, f-level: 63, builder: neo)
Feb 12 20:10:45 xyz freshclam[1368]: Current functionality level = 61, recommended = 63
Feb 12 20:10:45 xyz freshclam[1368]: Please check if ClamAV tools are linked against the proper version of libclamav
Feb 12 20:10:45 xyz freshclam[1368]: DON'T PANIC! Read http://www.clamav.net/support/faq
Feb 12 20:10:45 xyz freshclam[1368]: [LibClamAV] ***********************************************************
Feb 12 20:10:45 xyz freshclam[1368]: [LibClamAV] ***  This version of the ClamAV engine is outdated.     ***
Feb 12 20:10:45 xyz freshclam[1368]: [LibClamAV] *** DON'T PANIC! Read http://www.clamav.net/support/faq ***
Feb 12 20:10:45 xyz freshclam[1368]: [LibClamAV] ***********************************************************
Feb 12 20:10:46 xyz freshclam[1368]: [LibClamAV] ***********************************************************
Feb 12 20:10:46 xyz freshclam[1368]: [LibClamAV] ***  This version of the ClamAV engine is outdated.     ***
Feb 12 20:10:46 xyz freshclam[1368]: [LibClamAV] *** DON'T PANIC! Read http://www.clamav.net/support/faq ***
Feb 12 20:10:46 xyz freshclam[1368]: [LibClamAV] ***********************************************************
Feb 12 20:10:48 xyz freshclam[1368]: --------------------------------------

 

 

logi httpd dla domeny:

wiele lini typu:

 

[Tue Feb 12 20:12:33 2013] [error] [client xxx.xxx.xxx.xxx] Script timed out before returning headers: index.php

 

 

Po przeładowaniu httpd w logach Apache Error Log:

 

[Tue Feb 12 20:20:19 2013] [notice] SIGHUP received.  Attempting to restart
[Tue Feb 12 20:20:20 2013] [warn] RSA server certificate CommonName (CN) `localhost' does NOT match server name!?
[Tue Feb 12 20:20:20 2013] [notice] Apache/2.2.19 (Unix) mod_ssl/2.2.19 OpenSSL/0.9.8o DAV/2 configured -- resuming normal operations

 

 

Liczba procesów httpd podczas skoku: 99

[Pan Kot 1535]

Dziwna sprawa, wszystko wskazuje na to że winą jest updatujący się ClamAV, ale z jakiego powodu to nie mam zielonego pojęcia...

 

Feb 12 20:10:45 xyz freshclam[1368]: [LibClamAV] ***  This version of the ClamAV engine is outdated.     ***

 

Polecam zacząć od standardowego updatea (apt-get update && apt-get dist-upgrade)

 

 

Jeśli chcesz szybkiego rozwiązania problemu to możesz sprawdzić czy całkowite odinstalowanie ClamAV (apt-get purge clamav*) pomoże, ja osobiście sądzę że tak bo jeśli w syslogu nie ma nic ciekawszego to raczej to on jest winowajcą. Jeśli natomiast chcesz się pobawić w detektywa to...

 

Pytanie pierwsze, jakie to IP w tych logach httpd? Mogą to być zarówno userzy, którzy nie mogą wczytać strony jak i jakiś botnet, który atakuje httpd. Raczej stawiam na to pierwsze. Jeśli natomiast IP jest jedno i to samo i nie jest to ani IP zewnętrzne/wewnętrzne Twojego serwera to najzwyczajniejszy w świecie DoS.

[Gość patrys]

Co ma Clamav do tego ?

 

[Tue Feb 12 20:12:33 2013] [error] [client xxx.xxx.xxx.xxx] Script timed out before returning headers: index.php

 

Timeouty, timeouty... i konfiguracja.

Przy takim ruchu standardowa konfiguracja Apache nie jest dobrym rozwiązaniem.

[Pan Kot 1535]

WG mnie to trochę podejrzane, że ClamAV się zupdatował ~2 min wcześniej, ale jak najbardziej mogą to być tylko przypuszczenia . Jednak w przypadku prefork'a apache'a thready się nie kończą "na raz" tylko po trochu, dlatego też odrzuciłem ilość userów.

[Gość patrys]

Pudło to nic podejrzanego, a tym bardziej nie wpłynął na pracę serwera WEB.

[denis94 0]

Update i upgrade zrobiony. Niestety problem nadal występuje

Czy znacie jakieś narzędzie w którym mógł bym monitorować który to dokładnie plik php jest odpowiedzialny za przeciążenie apache?

[Pan Kot 1535]

Tak, to narzędzie się nazywa logi, tylko pierw trzeba je włączyć.

Edytowano Luty 15, 2013 przez Archi (zobacz historię edycji)

[denis94 0]

Logi z domyślnej konfiguracji nic nie wykazują.

Jakie jeszcze dodatkowe mogę włączyć?

Edytowano Luty 15, 2013 przez denis94 (zobacz historię edycji)

[Gość nrm]

Kolego Archi, logi w takim wypadku nic mu nie powiedzą. Zakładając taką konfigurację połączenia Apache<=>PHP dzięki której widzimy obciążenie per wywołany plik na wiele to nam się nie zda przy konstrukcji dzisiejszych aplikacji kiedy to w 99% przypadków dowiemy się, że to index.php W poszukiwaniu wąskiego gardła musimy już skorzystać z wew. profilerów czy też np. xdebuga i wyśledzić najbardziej problematyczne fragmenty aplikacji.

 

Ale w opisanym wyżej przypadku myślę, że nie ma co tak daleko się zapuszczać bo problem pewnie tkwi w sumie: faktycznych możliwości VPSa i tego co jest w stanie wyciągnąć w takim środowisku Apache.

 

Na pewno pierwszy krok to wywalenie Apacza, potem odpowiednie skonfigurowanie nginx+php-fpm+xcache. Potem można obserwować co się dzieje: ruch vs wykorzystanie zasobów vs poszukiwanie "wąskich gardeł".

[Pan Kot 1535]

(...)

Na pewno pierwszy krok to wywalenie Apacza, potem odpowiednie skonfigurowanie nginx+php-fpm+xcache. Potem można obserwować co się dzieje: ruch vs wykorzystanie zasobów vs poszukiwanie "wąskich gardeł".

 

Ten fragment mi się podoba .

[Gość patrys]

Na pewno pierwszy krok to wywalenie Apacza, potem odpowiednie skonfigurowanie nginx+php-fpm+xcache. Potem można obserwować co się dzieje: ruch vs wykorzystanie zasobów vs poszukiwanie "wąskich gardeł".

Uwierz, że na tym Apache można ustawić wydajne środowisko i FPM też będzie działał.

[Gość nrm]

Poważnie? "Pacz pan", kto by przypuszczał...

 

Wydajne, nie oznacza najwydajniejsze. Szczególnie jak masz ciasnego VPSa to ma to znaczenie.