Dotaz: Pretizeni serveru debian

[Martin Novak]

Dobry den, mel bych dotaz ohledne debian web serveru apache. Klasika s MySQL a PHP.

Server ma 1GB ram a obcas se kvuli pretizeni zasekne. Tzn. zaplni se ramka, zacne se swapovat a server je nedostupny. Zajimalo by me, jestli se to da resit jinak nez porizenim silnejsiho serveru. Tedy nastavenim apache, PHP nebo debianu.

Odpovědi

[linuxik]

1GB je pro tuhle kombinaci minimum, nejspis bude stacit pridat dalsi pamet, dve nebo ctyri GB a server muze spokojene bezet nekolik dalsich let

[pavel]

Zase tolik ho netrapte.....

Gigo rameti je luxus, ktery si nemuze kazdy dovolit. Bylo by dobre upresnit, co presne mas na mysli slovem "zaseknuti".

Nemuze to byt hw problem? Vadna ram? Co mas v logach (dmesg, nebo /var/log/syslog, /var/adm/messages.x apod.)

Pokud to neni hw problem, nemuze to byt sitovy problem? Pokud to neni hw ani sitovy problem, co rikaji logy apache, mysql?? Jake distro pouzivate?

[Martin Novak]

Zaseknuti = server se pretizi a nikomu se nic nezobrazi. Nevyridi zadny pozadavek. Neni dostupny ani pres FTP ci SSH. Resim to vzdy restartem serveru. Pak jde vse zase OK.

Co se konkretne stane? Ve statistikach je videt, ze systemu dosla volna ram + pocet apache procesu vyleze na 150. Rekl bych, ze to bude omezeni v konfiguraci. ( max child process ci neco podobneho).

Problem je, ze z podpory nedokazu dostat, co konkretne zpusobuje pretizeni. Jestli moc pozadavku, malo ram ci konfigurace apache.

Taky nerozumim tomu, proc kdyz server dojde na svuj maximalni vykonovy limit, tak se "zasekne" pro vsechny. Neda se nastavit, aby odmital jen nove pozadavky a soucasnym uzivatelum bezel normalne? Nebo aby se odchodu casti uzivatelu vratil do normalniho behu. Ted "zaseknuti" samo nezmizi trebas ani po 30ti minutach...

[aaa]

Casto je toto problem spatne napsane aplikace a moc pristupu do databaze... Pak se to chova presne takto...

[pavel]

Ano. To je typicky priklad. Pokud to tedy neni hw problem, tak je to urcite mezi app a db casti. Mnoho konekci do databaze (at uz skrze spatne napsanou aplikaci, nebo nejaky typ DoS). Spatne provedeny select do spatne navrhnute db.
Ale toto se necha nastavit restrikcemi v konfiguraci. Na mysql jsem tento problem "zatim" nemel asi proto ze nemam dost velkou a dost vytezovanou db.

[Martin Novak]

Proc by pri pretizeni MySQL vzrostl pocet pozadavku apache na 150 a zustal tam?

Jak poznam, ze je to opravdu problem s dotazy do DB. Neni vetsi problem zmensit pocet dotazu klidne na polovinu, ale potrebuju vedet, jestli to opravdu pomuze. Abych neoptimalizoval na spatnem miste.

[Zdenek]

Protoze uzivatel macka F5, kdyz nic nedostane za 5 sekund

[Šangala]

Pro upřesnění, standardně se každý dotaz (script) od klienta provede do konce i když již klient odešel na pivo. Takže pokud někdo 10× zmáčkne Refresh, může dojít k provádění téhož skriptu 10×, ale uživateli se zobrazí jen ten poslední (a pokud je to blbě udělané, tak i třeba se špatnými daty, protože procesy se mohly provést v jiném pořadí).

[pavel]

Sangala ma pravdu. Kouknete do vypisu netstat -a
Tim zjistite jake konekce, sokety atd. jsou na vasem systemu vyuzity.
Od toho byste se mohl odpichnout dal.

Vetsinou to tak je, ze aplikacni cast (mam na mysli server nikoli aplikaci jako takovou) tohle zvlada vcelku v pohode. Posila pozadavky do db a ocekava odpovedi. Ta zacne varit, nestiha. Takze to resi prirazenim vetsiho mnozstvi systemovych prostredku atd. atd. az dojdou zdroje. Pozadavky se hromadi ve fronte na procesor. Jenze nez db vyridi vas pozadavek, tak klienta driv vytimeoutuje aplikacni cast.

[volvox]

A ten server spravujete vy nebo ona hostingová společnost? Protože je evidentně špatně nakonfigurován. Umožnit Apachi spustit 150 procesů (s PHP) při této velikosti RAM je zjevně nesmysl.

Zkuste tento postup: Během běžného provozu zjistěte počet spuštěných procesů Apache, např. pomocí příkazu

ps ax | grep apache2 | grep -v grep | wc -l

Potom pomocí příkazem free zjistěte použitou paměť (sloupec used ve 2. řádku - tedy bez započtení bufferů a cache). Následně Apache stopněte a proveďte znovu free. Odečtete použitou paměť od hodnoty získané při běžícím Apachi, vydělte počtem procesů a získáte přibližnou průměrnou hodnotu paměti na jeden proces Apache.

Nyní odečtěte použitou paměť bez Apache od celkové velikosti RAM, dále odečtete cca 200MB pro diskovou cache a buffery (tohle číslo jsem si vycucal z prstu, prostě odhad) a konečně 50-100MB jako rezervu. Výsledkem bude velikost paměti zbývající pro Apache, kterou následně vydělíte průměrnou velikostí pro jeden proces, čímž zhruba získáte maximální počet procesů Apache. Toto číslo použijete v konf. direktivě Apache MaxClients. IMHO vám vyjde daleko menší číslo než 150.

Takto docílíte toho, že server nepřestane být dostupný při běžném provozu, ale je možné, že určité HTTP požadavky nárokující si násobky zjištěného průměru ho stejně vytíží. V tom případě bude potřeba vhodně limitovat PHP (memory_limit) či MySQL, ale to už budete zřejmě muset o problému zjistit víc (začal bych s error a access logy Apache).

Je také možné, že se jedná o DDOS útok, kterému se ale rozumně bez součinnosti poskytovatele nedá bránit (a málokterý poskytoval má pro to potřebné vybavení).

[volvox]

A ještě bych dodal, že tohle je jen začátek, aby Apache nevyčerpal veškerou dostupnou paměť, dál by bylo vhodné se zaměřit na příčinu problému. Tedy proč Apache nestíhal obsluhovat došlé požadavky v rozumném čase a musel si pro ně vytvářet nové procesy.

[Martin Novak]

diky za zajimave namety. DDOS utok to nebyl, tim uz mi server jednou nekdo odstrelil a probihalo to jinak :)

Co se stane, kdyz se apache server dostane na limit maxclients? Drive jsem tuto hodnotu mel mensi a pri dosazeni limitu se zacali generovat chyby v logu a server byl nedostupny. zase pomohl az restart...

[Šangala]

Začnou se požadavku skládat do fronty dlouhé ListenBacklog (samozřejmě i tato fronta má své paměťové nároky) a server pro nově příchozí bude nedostupný, dalo by se říct přetížený, ale pokud přestanou chodit požadavky (típne se od sítě) měl by se rychle vzpamatovat.

[pavel]

Zase tolik ho netrapte.....

Gigo rameti je luxus, ktery si nemuze kazdy dovolit. Bylo by dobre upresnit, co presne mas na mysli slovem "zaseknuti".

Nemuze to byt hw problem? Vadna ram? Co mas v logach (dmesg, nebo /var/log/syslog apod.)

Pokud to neni hw problem, nemuze to byt sitovy problem? Pokud to neni hw ani sitovy problem, co rikaji logy apache, mysql??

[pavel]

Sorry. Nejak mi ujela ruka. Vyse uvedene prispevky jsou duplicitni.....

[Martin Novak]

Problem je v tom, ze hostingova firma nedovoluje pridat ramky. Tedy abych mel 2 nebo 4 GB ram, tak musim platit mesicne skoro 2-3x tolik co ted, protoze to bude vykonejsi server. Samotne ramky me nedovoli zvysit

[trekker.dk]

Můžeš omezit počet procesů Apache, omezit spotřebu paměti PHP (memory_limit), pokud ti PHP běží jako samostatný proces, omezit počet těchto procesů.

Eventuelně napsat skript, kterej bude hlídat velikost volné paměti a když klesne moc nízko, tak restartuje Apache.

[Martin Novak]

s memory_limit v PHP bude mozna problem. Jak se to chova? Kdyz nastavim limit trebas 500MB, tak to vzdy sezere jen tolik kolik potrebuje nebo to zere vice nez kdyz je tam trebas 50MB ?

Kdyz se omezil pocet procesu apache, tak se server "zasekl" drive.

[Šangala]

500Mb je asi špatně i 50Mb je možná moc, pokud se nepracuje s velkými daty či obrázky i 8Mb může stačit.
Je to maximální limit jednoho procesu (jednoho požadavku), bere se jen to co je potřeba a jakmile to narazí na tento limit tak provádění PHPka v tomto místě zklame, takže když to přeženete (směrem dolů), tak to poznáte na nefunnkčnosti aplikace/stránek

[Martin Novak]

mam tam 35. Chtel jsem vedet, jestli kdyz skript potrebuje napriklad vzdycky 3MB, tak zda je PHP stejne pametove narocne kdyz ma limit 50MB i 500MB.

[Zdenek]

To nastaveni neplati pro php celkove, ale zvlast pro kazdy skusteny skript, takze 500MB na 1GB stroji je absolutne spatne.

[Šangala]

1Gb není moc na zatížený server, na druhou stranu, MySQL a Web server tak rozhodně lze bezproblémově provozovat.
Je třeba to jen dobře nastavit, lze omezit počet současným připojení jak na Apache tak na MySQL. Omezit velikost paměti na PHP, a nastavit MySQL rozumně s ohledem na dostupnou RAM.
Každopádně to chce zjisti CO to dělá.
Také lze omezit uživatele na kterého běží Apache, či MySql pomocí limitů což sice nemusí být to správné pro udržení chodu, ale mohlo by to zajistit, že se na ten server vždy dostanete a můžete analyzovat problém.
PS: má tá mašina dost místa na disku, když dojde místo na disku může se to zachovat podobně.

[Jezekus]

Docela zajimave, provozoval jsem docela dost veci na starickem Celeronu 700 + 512MB RAM, pozdeji (cti po nabytych zkusenostech) jsem zjistil ze jen apache zere tak 200MB RAM.
Zda se mi podivne, ze se masina "kousne" a je nutno na tvrdo restartovat(aspon tak jsem pochopil). Jak se to chova, kdyz se "kouslemu" serveru sebere sitovy kabel? Vzpamatuje se?
Videl jsem pomerne slaby stroj (Pentium Dual-Core @ 2.4GHz s 4GB RAM) a ten prestaval odpovidat az kolem 3500 apacich procesu. Pokud se mu utrhl "ocasek" okamzite se vzpamatoval a pocet procesu klesl na "beznou" hranici.
Zda se mi to jako spatna napsana webova aplikace nebo (pripadne a zaroven) HW problem.

[volvox]

Serveru prostě dojde RAM a uswapuje se k smrti, případně nastoupí OOM killer.

Kolik RAM zabere Apache se liší server od serveru a u konfigurace z PHP jsou zkušenosti takřka nepřenositelné, protože nelze bez znalosti aplikace odhadnout:

1. kolik paměti si naalokuje PHP k provedení skriptu,
2. jak dlouho bude provedení skriptu trvat (a tedy blokovat paměť),
3. kolik požadavků muset bude během určitého časového úseku obsloužit

A s vytížením Apache v určité korelaci roste i vytížení ostatních služeb, tady zřejmě zejména MySQL.

[Martin Novak]

Predne bych rad podekoval vsem za pomoc. Podival jsem se poradne na ty logy a konfigurace.

Nejprve upresnim o co jde. Server je virtualni. Ma 1 GB ram a na jednom HW jsou tyto stroje maximalne 3. Na strankach je tak 200-250 lidi najednou online. Stranky jsou i trochu download server, tedy ze se ve vetsim mnozstvi stahujou male soubory (<10MB). Kody nejsou skoro vubec optimalizovane na vykon. S vyuziti memcached bych byl urcite schopny snizit pocet dotazu do DB 2x nebo klidne i 5x.

v PHP mam max_limit na 35 MB v apache je tohle: # prefork MPM IfModule mpm_prefork_module> StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0 /IfModule>

# worker MPM IfModule mpm_worker_module> StartServers 2 MaxClients 150 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestsPerChild 0 /IfModule> -- odmazal jsem uvodni < abych to mohl vlozit

Kdyz jsem koukal na log slow queries MySQL, tak vzdy tesne pred a behem vypadku bylo v logu spousta pomalych SQL prikazu. Od trivialnich UPDATE .. where id=X az po nejake slozite. V normalnim provozu neni v logu zadny sql pomaly SQL dotaz.

V apache je pocet maxClients zvyseny proto, ze jsem na podporu pred pul rokem psal kvuli problemu, kdy se server zasekl, protoze apache nemohl vytvaret nove child procesy. Tak zvysili tuto konstantu a problem se uz nevyskytoval.

Kdyz sem si zmeril, kolik MB sezere nacteni stranky (pres nette profiler), tak je to u vsech stranek kolem 4MB. (200-250 lidi online *4 = cca 1000MB ram :( - da se to takto pocitat?)

Z toho co jste psali a co jsem zjistil z logu bych rekl, ze pujde asi opravdu o pretizeni MySQL neoptimalizovanymi dotazy.

Je tu moznost, ze nektery "sousedni" VPS trebas pretizi disk a proto se zpomaly i muj VPS? Pomohlo by kdybych presel na stejnou konfiguraci serveru, akorat s tim, ze by to nebyl virtual, ale server by byl jen pro me? (ram by zustala stejna)

[Šangala]

Když to tak počítám tak si myslím že dojde k následujícímu:
Jakmile se připojí větší množství clientů, tak začne docházet paměť a MySql samo sebe utluče, začne docházet k prodlevám, které mají jen vzrůstající charakter, protože všechny skripty asi čekají na odpověď MySQL a vše se točí do swapu a skončít to může jen vytuhunutím, také trochu díky MaxRequestsPerChild = 0 - je to moc lidí naráz na Apache + MySql s danou RAM.
Přejítí na fyzický HW může pomoc, záleží na typu virtualizace jaké má režie. Samozřejmě pokud budete mít CPU i HDD jen pro sebe, ta stihne vyřídit vše rychleji, nicméně toto je případ kdy více RAM lze jen doporučit.
Pokud to stahování jde z DB tak to je jasný killer :)
Za stávající situace bych zkusil omezit MaxClients, snížení by nemělo vést k vytuhnutí, ale k pomalejšímu vyřizovaní požadavků

[ondrej]

resil jsem ted podobny problem, nastaveni MaxRequestsPerChild na 150 mi dost pomohlo

[Šangala]

A to jste snižoval nebo zvyšoval ?
Je pravdou že nastavená 0 (bez limitu) může být zdrojem problémů.

[Martin Novak]

v nastaveni apache jsem se vubec nevrtal. Tohle tam nastavili admini z hostingu. Tzn asi default nastaveni

[jonson]

Jeste by se dalo podivat na tu MySQLku -- jestli je taky v defaultnim nastaveni, muze vyuzivat treba malo pameti na kesovani klicu atp. Pouzivate innodb nebo myisam tabulky? Osobne mam tu zkusenost, ze dokud se MySQLce vejde databaze, se kterou pracuje, cela do pameti, beha slusne. Jakmile zacne vic sahat na disk, zhorsi se vykon markantne. Ale zalezi jak lezi, jak je velka a strukturovana vase databaze..

Treba ta kes pouzita na vysledky dotazu (memcached, ...) nebude od veci, pokud spoustite nejake narocnejsi dotazy v kazde strance.

[Jendа]

Pak je ještě možnost dát tam místo Apache něco lehčího - lighttpd, nginx…

[Martin Novak]

diky vsem za pomoc. Neco s tim zkusim udelat

[Atom321]

Podobné "uswapování k smrti" se mi stávalo na desktopu. (Starší AcrobatReader měl nějakou chybu a alokoval donekonečna.) Vypnul jsem swap a nastavil:

echo 2 > /proc/sys/vm/overcommit_memory
echo 80 > /proc/sys/vm/overcommit_ratio

První příkaz říká "alokuj jen paměť, kterou máš fyzicky k dispozici". Druhý parametr znamená "maximálně 80% fyzické RAM + swap pro aplikace, zbytek jádru na buffery". V Lennym se to dá trvale nastavit v /etc/sysctl.conf. Přesný popis je v dokumentaci jádra. Výsledek je, že jádro nepřidělí víc, než si může bezpečně dovolit. Pokud nějaký program chce alokovat příliš paměti, prostě jí nedostane a skončí s chybou. Jádro tak má pořád dost RAM pro běh všeho, nikdy tak nedojde k uswapování ani spuštění OOM killera. (V mém případě tedy klekl jen potížista AcrobatReader, čehož jsem přesně chtěl docílit.)

Možná ještě lepší alternativa je udělat swap na cca 90% velikosti RAM a nastavit overcommit_ratio na 0. Jádro pak přidělí aplikacím maximálně 90% RAM, ale zůstane mu možnost odswapovat spící procesy. To jsem ale nezkoušel - RAMky mám dost.