Strona 1 z 3 123 OstatniOstatni
Pokaż wyniki 1 do 10 z 23

Temat: strace +apache PID

  1. #1
    Zarejestrowany
    Aug 2008
    Postów
    23

    Domyślnie strace +apache PID

    witam,
    niektore z procesow apache'a zuzywaja >90% CPU, podczas gdy normalnie jest to na poziomie 15-20%.

    jest zdubbogowalem te procesy i kazdy z nich wyglada tak samo (podobnie )

    ...
    mremap(0xa0940000, 267214848, 267227136, MREMAP_MAYMOVE) = 0xa0940000
    mremap(0xa0940000, 267227136, 267235328, MREMAP_MAYMOVE) = 0xa0940000
    mremap(0xa0940000, 267235328, 267247616, MREMAP_MAYMOVE) = 0xa0940000
    mremap(0xa0940000, 267247616, 267255808, MREMAP_MAYMOVE) = 0xa0940000
    ....
    mremap(0xa0940000, 267255808, 267268096, MREMAP_MAYMOVE) = 0xa0940000
    mremap(0xa0940000, 267268096, 267276288, MREMAP_MAYMOVE) = 0xa0940000
    mremap(0xa0940000, 267276288, 267288576, MREMAP_MAYMOVE) = 0xa0940000
    chdir("/") = 0
    umask(022) = 022
    fstat64(2, {st_mode=S_IFREG|0640, st_size=8906940, ...}) = 0
    mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7465000
    write(2, "Allowed memory size of 268435456"..., 85) = 85
    munmap(0xb7465000, 4096) = 0
    exit_group(1) = ?

    nie znam sie na tym za bardzo, ale wyglada mi to na skan nmapem, czy tak?

    sprawa jest dosc powazna bo potrafi zawiesic caly system.

    pozdr.

  2. #2
    Zarejestrowany
    Aug 2007
    Postów
    104

    Domyślnie

    Cytat Napisał drwal Zobacz post
    nie znam sie na tym za bardzo, ale wyglada mi to na skan nmapem, czy tak?
    NIE...


    na pierwszy rzut oka masz problem ze sprzetem - sprawdz pamiec, bo ona powoduje problem, ewentualnie dysk i swap lub konfiguracja...
    Ostatnio edytowane przez Whizz_BANG : 12-11-2010 - 13:22

  3. #3
    Zarejestrowany
    Aug 2008
    Postów
    23

    Domyślnie

    hmm.. to ciekawe.. a co wskazuje na to ze mam problem ze sprzetem?
    nie twierdze, ze tak nie jest, ale jak bede pisac do NOC'a to musze jakos uzasadnic..

    poza tym, te przypadki >90%CPU, zdarzaja sie co jakis czas tylko.
    99% czasu zuzycie CPU, jest na poziomuie ok 20%.
    ten problem zaczal pojawiac sie dopiero niedawno.

    zastanawia mnie tez duza liczba TIME_WAIT

    netstat -nat | awk '{print $6}' | sort | uniq -c | sort -n
    1 established)
    1 Foreign
    1 LAST_ACK
    10 FIN_WAIT2
    13 LISTEN
    21 CLOSING
    34 SYN_RECV
    36 ESTABLISHED
    44 FIN_WAIT1
    3377 TIME_WAIT

    choc mam w apache'u:
    KeepAlive Off, KeepAliveTimeout 2, Timeout 5

    sysctl.conf:
    net.ipv4.tcp_fin_timeout=15
    net.ipv4.tcp_keepalive_time=200
    Ostatnio edytowane przez drwal : 12-11-2010 - 16:13

  4. #4
    Zarejestrowany
    Jun 2006
    Skąd
    rand(.eu)
    Postów
    8,748

    Domyślnie

    Czy nie uzywasz przypadkiem mpm-worker albo NFSa?
    Masz pelno polaczen ktore blokuja deskryptory - w normalnych warunkach worker dziala wydajniej bo uzywa watkow ale w sytuacji gdy czekasz na zakonczenie I/O ten model dostaje po tylku i to ostro...
    Nie pasuje mi tylko obciazenie procesora - jesli to jest to co mysle to powinno byc na poziomie 0-1% max i serwer www powinien byc zatkany calkowicie i nie akceptowac nowych polaczen.

    Mam pewne przypuszczenia co to moze byc ale najpierw potrzeba do tego nieco wiecej informacji
    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

  5. #5
    Zarejestrowany
    Aug 2008
    Postów
    23

    Domyślnie

    uzywam mpm-prefork.

    CPU w takich sytuacjach wyglada tak (top):
    Cpu(s): 91.7% us, 7.6% sy,

    kiedy us osiagnie 99% to przechodzi na dysk, no i jak I/O osiagnie 90pare to pada..
    wtedy CPU us jest, tak jak mowisz, 0-1%..

    ale nie zawsze CPU us idzie w kierunku 99%.
    zazwyczaj waha sie to od 90-95% i spada do normalnego poziomu, czyly 10-25% CPU.

    BTW, dlaczego polaczenia sa aktywne (TIME_WAIT) przez 30sekund
    (biorac pod uwage moje ustawienia ktore podalem w 1. poscie)?
    jak to zmniejszyc? bo moze TIME_WAIT zamula?

  6. #6
    Zarejestrowany
    Jun 2006
    Skąd
    rand(.eu)
    Postów
    8,748

    Domyślnie

    TIME_WAIT to specyficzna przypadlosc ze tak to ujme

    net.ipv4.tcp_fin_timeout=15
    net.ipv4.tcp_keepalive_time=200

    te parametry nie reguluja TIME_WAIT niestety... jedyne co jako tako moze pomoc (uwagi na koncu postu) to tcp_tw_reuse ktore pozwoli na ponowne uzycie socketow w stanie TIME_WAIT jesli bedzie to bezpieczne z punktu widzenia protokolu.

    Ja zaczalbym raczej od okreslenia co dokladnie jest powodem takiego zachowania systemu.
    To co opisujesz czesto pojawia sie na bardzo obladowanych serwerach WWW gdzie masz mase polaczen ktore zyja bardzo krotko.
    Wlasnie sprawdzilem jeden ze swoich serwerow ktore sa dosyc dosyc obciazone - 28 socketow w TIME_WAIT i ten serwer dziennie robi dobre kilka GB ruchu... serwujac malenkie obrazki sredniej wielkosci ok 30-50kB...

    Najpierw nalezaloby ustalic co jest powodem takich zachowan i zrobic tuning serwera a nie tuning stosu tcp na poziomie kernela :-] bo to nieco jak zabieranie sie do tematu od duszy strony...
    Jesli to nie tajemnica, to co tam stoi na tym serwerku ze taki dziwny ruch masz?
    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

  7. #7
    Zarejestrowany
    Aug 2008
    Postów
    23

    Domyślnie

    Wlasnie sprawdzilem jeden ze swoich serwerow ktore sa dosyc dosyc obciazone - 28 socketow w TIME_WAIT i ten serwer dziennie robi dobre kilka GB ruchu... serwujac malenkie obrazki sredniej wielkosci ok 30-50kB...
    dokładnie to robi

    jeśli chodzi o konfigurację apache, to:

    Kod:
    Timeout 5
    KeepAlive Off
    MaxKeepAliveRequests 100
    KeepAliveTimeout 2
    
    <IfModule prefork.c>
    StartServers        15
    MinSpareServers     10
    MaxSpareServers     20
    ServerLimit     250
    MaxClients         250
    MaxRequestsPerChild 8000
    </IfModule>
    BTW, rozumiem że output strace'a nic nie mówi.. ?
    Ostatnio edytowane przez drwal : 12-12-2010 - 08:14

  8. #8
    Zarejestrowany
    Jun 2006
    Skąd
    rand(.eu)
    Postów
    8,748

    Domyślnie

    Nie mowi za wiele poza tym ze *chyba* brakuje pamieci do obslugi polaczenia. Kazdy socket zajmuje RAM wiec jesli te uzyte nadal wisza to pamiec jest zajeta... wtedy wzrost uzycia CPU jest raczej logiczny a jak sie skonczy RAM to zaczyna dzialac swap i wtedy leci I/O ostro do gory... w pewnym momencie pojawia sie OoM Killer i jak trafi to ubije proces lub nawet kilka apaczowych.

    Ile masz RAM na tym serwerku?

    Nie rozumiem tez dlaczego majac taki proufil ruchu masz MaxRequestsPerChild=8000 - to by sugerowalo ze odpalasz mase procesow ktore sa zablokowane tak dlugo jak dlugo klient jest podlaczony (max 2sek bez przesylania danych, 1 klient = 1 proces) i taki proces wisi do 8k zapytan... Proces oznacza zablokowany socket z tego co widzialem w dokumentacji, proces zyje dluuuugo, pozniej jak zakonczy prace to jeszcze te 30sek czy ile tam jest TIME_WAIT musisz czekac az pamiec zostanie zwolniona i socket zwrocony do ponownego uzycia.
    Moge sie totalnie mylic ale ja bym zmniejszyl z 8000 do powiedzmy 200-250 i zobaczyl co sie bedzie dzialo.
    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

  9. #9
    Zarejestrowany
    Aug 2007
    Postów
    104

    Domyślnie

    czlowieka chwile nie ma i tyle postow sie zrobilo
    drwalu, mogles w pierwszym poscie napisac, ze problem dzieje sie raz na jakis czas, bo zrozumialem, ze jest on permanentny.

    Wychodze z zalozenia, ze tcp_wait ma ulatwiac zycie - jest to stan w ktorym serwer czeka na potwierdzenie rozlaczenia; podczas tego oczekiwania moze nastapic retransmisja z klientem co kosztuje mniej niz nawiazanie nowego poalczenia - czekamy na flagi ACK, FIN lub sami ustawiamy czas czekania np. 30 sekund i bye. Generalnie tcp ma zwalniac zamkniete polaczenia i szaybciej udostepniac nowe zasoby.
    Do tego celu tak jak powyzej zostalo napisane (TQM) potrzeba ustawiac m.in. tcp_fin_timeout oraz ponowne uzycie gniazd time_wait czyli: tcp_tw_reuse.
    Moim zdaniem to by bylo na tyle, jezeli chodzi o zabawy z tcp i grzebanie w kernelu.

    dalej skupiamy sie na httpd.conf
    najpierw troche lektury:
    Configuring Apache for Maximum Performance | HowtoForge - Linux Howtos and Tutorials
    mpm_common - Apache HTTP Server

    MaxRequestsPerChild bym zmniejszyl do 2000
    StartServers chyba jest taka zasada, ze ustawia sie taka wartosc jak MinSpareServers, ustaw na 10

    w pierwszym poscie napisalem, ze masz problem ze sprzetem, czyli pamiecia - dalej to utrzymuje, tylko dla jasnosci: maszyna nie wyrabia i potrzeba go wiecej - dlatego napisalem sprawdz pamiec, bo jesli to serwer dedykowany to mozna chyba odrzucic teze, ze zepsula sie jedna kosc ramu.

    Szukajac dalej przyczyn problemu mam dwie opcje:
    - time_wait jest tylko dla portu 80 i nie dotyczy baz danych? bo problem moze byc na lini php-baza_danych, sprawdz sobie oprocz php.ini to jakie parametry masz ustawione w konfiguraji dla bazy danych, czy skrypty czegos nie zapetlaja; dodatkowo mozesz uzyc jakis wzrow na performance bazy danych, jesli takowych nie znasz to uzyj mysqltuner.pl lub pgtune, bo nie wiem jaka masz baze...
    - 2 opcja to: bawiles sie kiedys ab na linuxie? to potestuj sobie serwer tym narzedziem i wtedy sam domyslisz sie, gdzie jest problem
    ab(1): Apache HTTP server benchmarking tool - Linux man page
    Uwazaj bo mozesz latwo zabic serwer! zarowno maszyny do DoS jaki i serwer testowany

    rozumeim, ze nie masz zadnego systemu monitoringu i nie wiesz kiedy lub w jakis odcinkach czasowych dzieje sie to obciazenie i ile trwa?

  10. #10
    Zarejestrowany
    Aug 2008
    Postów
    23

    Domyślnie

    zmniejszylem wartosc MaxRequestsPerChild do 800.
    Na razie wyglada to dobrze. przez ostatnie pare godzin nie skacze do 90%,
    ale jeszcze nie ma hura, bo to niedziela i jest mniejszy ruch. nadal bede obserwowal.

    mam 3GB RAMu.

    Zwiekszylo sie nieco natomiast liczba TIME_WAIT'ow:
    netstat -nat | awk '{print $6}' | sort | uniq -c | sort -n
    1 CLOSING
    1 established)
    1 Foreign
    13 LISTEN
    21 FIN_WAIT2
    32 ESTABLISHED
    34 FIN_WAIT1
    34 SYN_RECV
    4111 TIME_WAIT


    z baza nie ma raczej problemow,ale TIME_WAIT'y sa tez na porcie 11211 (memcached).
    uzywam to do serwowania tych obrazkow, o ktorych TQM wspomnial.
    mam: net.ipv4.ip_local_port_range = 10000 65535

    jesli chodzi o ab, to juz sie tym bawilem. nie boje sie tego bo mam DOS-deflate i mod_evasive ktore wytna taki ruch.

    nie, nie mam zadnych narzedzi do monitorowania zuzycia CPU poza TOP. znasz jakies godne polecenia?

Strona 1 z 3 123 OstatniOstatni

Zasady Postowania

  • Nie możesz zakładać nowych tematów
  • Nie możesz pisać wiadomości
  • Nie możesz dodawać załączników
  • Nie możesz edytować swoich postów
  •  
Subskrybuj