BLACKHOLE.sk

Takze zdravim :).
Chcem sa podelit zo zazitkom z tech@**** ;).
Typek, pre ktoreho som robil web, tam ma normalny server a databazovy
- web: Intel XEON 5405 (4 jádra), 4GB RAM, 1TB diskové pole
- db : 2x Intel XEON 5405 (2 x 4 jádra), 8GB RAM, 3x 147GB HDD 15.000RPM

Cely problem zacal, ked sa presunula db jednej stranky z videami, na databazovy server a spustilo sa nahravanie videii do velkosti 1GB. Zacali visiet procesy v mysql o neukonceni spojenia na stranke o filmoch asi 500 visiacich sleep procesov...

Ale rovno z mailu :)
Majitel si pytal mysql slow query logy pre web server.

Odpisali mu:
"uzivatel xyz, databaze xyz - je nezbytne nutne uzavirat otevrena databazova spojeni, jinak dochazi k vycerpani max. poctu spojeni! To je totiz problem, ktery prave ted zpusobuje nefunkcnost MySQL. Ve slow_log nic neni."

Spojenia uzatvaralo, ve slow_logu nic neni - jasne, nie na db serveri :). Cize ziadate jedno, odpisu druhe.

Nato mail odomna:
Dobry den v munin vidim, ze server web ma mysql slow query viem, ze db server ma prazdny, lebo to vidim na grafe. Server web ma load 300.

A odpisali samozrejme rychlo:
Vzdyt Vam to pisu, je to tim, ze se ceka na mysql na db. Uz jsem Vam vypnul perzistentni spojeni do databaze, coz resi neuzavirani spojeni. Load uz je 15, na grafu se to projevi za chvili. Uzavirani perzistentnich spojeni, nebo jejich nepouzivani je nejlepsi zpusob, jak se podobnemu problemu vyhnout do budoucna.

Tj. uz nikdy mysql_pconnect, ale vzdy pouze mysql_connect!

Vzdy sa pouzivalo mysql_connect je zahada ze klesol load na 15 :D

Mailik odomna:

Dobry den,
Som programator stranky o filmoch a nikdy neopuzivam mysql_pconnect ;). Vzdy od jakziva mysql_connect a teraz k veci:
1.) Pozrite si grafy pre web serveru.
2.) neriesime teraz db-server, lebo ten slape jak hodinky a tym, ze na stranke o filmoch vela ludi pobehuje po webe, kym najdu co chcu, tak jasne ze je viac konektit na mysql, ale vzdy je spojenie uzatvarane, takze tym to neni.
3.) Web server si pozrite IOstat a CPU usage a LOAD.
4.) Je jasne, ze disky nestihaju, kedze IOwait je vysoke.
Pozrite si poriadne grafy a potom kecajte o xyz, ked riesime nieco ine ohladne loadu web serveru a nie loadu db serveru .

Odpoved za polhodinu:
Kdyz vidim 500 spojeni ve stavu Sleep od uzivatele xyz, tak je to jasne. Ze pak apache na druhem serveru ceka a zpusobuje to vysoky load - to tak uz byva, kdyz proces ceka na spojeni do databaze a nedocka se ho. Disky stihaji moc dobre, az nebudou stihat, projevi se to jako IOWAIT 400%.

Ja kecam? Tak milej pane - to si vyprosuju!

Z nasi strany je vse v naprostem poradku a funkcni, chyba je na strane aplikace uzivatele.

IOwait 400% ? :D to je vtipalek :D

Nato mi napisalo vedenie, ze si nepraju take chovanie a bla bla :)

Tak som mu pekne odpisal:
K tejto veci vam kludne napisem s potvrdenim mojho znameho, ktory robi uz par rokov server & web hosting, ze :
- iowait je cakanie na disk, t.j. read/write
- problem nastal urcite pred dvoma dnami, kedze vtedy traffic vzrastol 4x nasobne

To, ze pan KKK presunul databazu na server databazovy, cim nasledne sposobil nejakym sposobom sleep processov DB xyz.
S webom xyz nebolo robene asi mesiac, cize zasah moj nebol a nikto iny nema pristup k danemu webu. Cize problem nastal, ako mozete vidiet na grafoch, co nestihaju disky (iowait je cakanie na disk, t.j. read/write)

Kazdy, kto robi z linuxom si to vsimne velmi rychlo ze vzrastol traffic a s tym aj iowait, kedze bezi 60MB/s siet...
- web server
Apache bezi v klude, IOstat vidime, ze caka na zapis a citanie na disky, mysql query spadli na minimum vdaka presunu, je tam zopar mysql_slow_queries, na netstat tiez mozete vidiet narast, aj pri cpu usage a load average je toho vysledok.
- db server
Mysql querys narast, limit mysql vidno na grafe mysql theards, obidva weby maju denne 20 tisic ludi navstevnost. To moze byt dovod, ze mysql ma nizke limity nastavene. Stranka o filmoch za kazdym uzatvara pripojenia na mysql, neviem preco ostavaju akurat processy stranky o filmoch visiet, aj netstat vidite, ze brutalny narast, odkedy je vide web stranka na databazovom serveri.

Tot podla grafov... Ale treba shell k 100% urceniu problemu - cez grafy sa vela zistit neda.

Odpisal asi po cca 10 minutach a potesil ma:
Vytížení serveru web je mimo jiné způsobeno velkými videii, co se přehrávají. Jsou tam velká videa, kteří uživatele s pomalým připojením stahují i několik hodin a tím čerpají systémové prostředky serveru. Momentálně se trochu ještě víc zvýšil zmiňovaný iowait,, protože se večer automaticky spustila synchronizace RAIDu.

Výše uvedenému problému by pomohl HW RAID na serveru a více paměti. Minimálně 8GB RAM.

Pekne grafy co? :)

RAID je nutný kvůli zabezpečení proti ztrátě dat. Poruchovost pevných disků je cca 20% do 2 měsíců. Tzn, že každý 5. pevný disk do dvou měsíců odejde. Jenže na serveru web je softwarový RAID. Je nutný hardwarový raid s vlastní cache pamětí a CPU. Takovéto RAIDové řešení je velice výkonné.

Silný nedostetek paměti řeší nyní technici. Provádějí upgrade na 12GB RAM.

Vcera novy problem - apache vycerpal limit. Bol nastaveny na 400 procesov a je tam asi 30 webov :)

Na moj mail
z narastem lidi, ktery sleduji videa na video stranke, se vycerpava limit pre otvorene apache pripojenia, kvoli dlhym videam. Bolo mi tento limit mozne dvihnut na 500-600?
To by malo byt optimalne. Dneska sa to prejavilo nenacitavanim stranok atd, kedze server nepusti limit.

Odpisali
Limit zvýšen, ovšem na serveru se projevuje nedostatek konektivity vlivem zvýšení trafficu ve sdíleném pásmu, což bude také parametr, který přispívá tomu, že tam ty procesy visí.

Dalsi problem, ved preco nie :)
Dobry den,
Asi 10 minut, co som vam pisal ohladne apache limitu mysql na video, stranka hlasi:
Host '***' is blocked, because of many connection errors; unblock with 'mysqladmin flush-hosts'

Co som otom cital, tak je to sposobene tym, ze sa straca spojenie po ceste k db... A ze moze pomoct nastavenie:

mysqld_safe --max_connect_errors=10000
Priblizne... Je tam nejake riesenie s tou DB? Kvoli comu to nestiha? Velkemu prenosu dat z video web stranky?

Neodpisali... Zase ta ista chyba, tak pisem znovu:
Max connect errors ste nedvihli hodnotu ako vidim... Lebo zase to pise to iste... Ak by ste mohli dvihnut ten limit, aby to bezalo stale...

Odpisal pan martinu - to mozno spoznate aj v texte ked citate. Odpisoval sef, martinu :). Pricom Jan Martinů sa sprava ako majster sveta.

A ani zvedat nebudeme, Vase aplikace nema zadne neuspesne spojeni vubec delat.

Hmm toto som sa sa zasmial :). Ked dade mysql_connect viete ovplyvnit, ci sa pripoji alebonepripoji?:D.
Neuspesne robi, ak sa vycerpa apache limit a neodpovie uz nejak dalej. Tak mysql zablokuje server, lebo si mysli, ze je to utok.

Vzdy, ked apache dosiahne limit (teraz je 500), tak mysql zacne robit chyby v connecte a nasledne to blockne. Skuste kusok aj pocuvat - uz raz som mal pravdu a nepocuvali ste ma.

A odpisal :)
Nemate v nicem pravdu (viz. nesmysl s diskama), az prekrocite i tento limit, budeme ho opet zvysovat? Na miliardu nebo na vic?

Vy nechapete, ze naraz bezi 500 processov, cize naraz 500 ludi natahuje stranky. Neni tam jeden web. Videa maju kusok dlhsie otvorenu connekciu, nemyslite?
Hlavne, ked su tam 700MB subory, tak laskavo to dvihnite.
Znamy, co ma videa na serveri ma apache limit na 700 a mal tam jeden web! My mame kusok viac a ako vidite, 500 je malo, kedze viac ludi ziada o stranku nez 500!!! Jo? A nemam v nicem pravdu? Proc sa potom dokladala ram pamat, ked IOwait nebol na 400%???? Ale stacilo 150% a uz to bolo citit!

Toto je aktulany graf z apache processes

A cakam co odpise :))).
Prosim kritiku, v com som ja nemal pravdu atd :). Rad sa poucim.
Nehovorim, ze som dokonaly, ale par ludi sa zasmialo na ich odpovediach :)