Dotaz: problemy s apachem

[Vlada]

Dobry den,

Prosim o radu, nemuhu vyresit problem s padem apache.

Cas od casu mi do logu zahlasi toto:

[Wed Aug 12 16:44:38 2009] [error] server reached MaxClients setting, consider raising the MaxClients setting
Pak pomaha jen restart apache.

Nekdy se zobrazi i tyto hlasky:

[Wed Aug 12 16:46:14 2009] [warn] child process 17893 still did not exit, sending a SIGTERM
[Wed Aug 12 16:46:14 2009] [warn] child process 26327 still did not exit, sending a SIGTERM
[Wed Aug 12 16:46:14 2009] [warn] child process 26837 still did not exit, sending a SIGTERM

Pravdepodobne jak se pokusim o restart.

Server je novy a ma 4G RAM, nastavil jsem vyssi hodnotu MaxClients:

<IfModule mpm_prefork_module>
    StartServers          5
    MinSpareServers       5
    MaxSpareServers      10
    ServerLimit        550
    MaxClients          550
    MaxRequestsPerChild   0
</IfModule>

# worker MPM
<IfModule mpm_worker_module>
    StartServers          2
    MaxClients          550
    MinSpareThreads      25
    MaxSpareThreads      75
    ThreadsPerChild      25
    MaxRequestsPerChild   0
</IfModule>
 

Ale moc to nepomohlo, apache hlavne vubec nekomunikuje, misto aby zpomalil.

budu rad za kazdou radu

 

 

 

 

 

Odpovědi

[cronin]

Na zaciatok rada nesuvisiaca priamo s Apacom: ak mas procesor s hyperthreadingom, odporucam vypnut, ibaze by benchmark v Tvojich konkretnych podmienkach ukazal, ze HT je prinosom.

Okrem "nastavovatelnych" limitov ma apac aj vkompilovane limity. Skus vygooglit aj nieco na temu "queueing network" a "listening backlog"; nezlakni sa ak najdene dokumenty budu popisovat trebars tazkotonazny aplikacny server od IBM - princip je rovnaky.

Najrychlejsi postup - teda ak nechces instantne riesenie, ktoremu ale nebudes rozumiet - je precitat si uvod do MPM modulov a potom dokumentaciu prislusnej pouzitej implementacie, v Tvojom pripade to bude bud Prefork alebo Worker; dporucam zvazit moznost zmeny Prefork-u za Worker (cim som aj naznacil, ktory modul asi aktualne pouziva Tvoj server). Po pochopeni tychto zalezitosti pokracovat kapitolou o ladeni. Kazdopadne ale treba najskor zistit - prostriedkami OS - ktory subsystem sposobuje latencie: siet, disk, CPU, pamat?

Moja praxou velakrat odskusany postup na konfiguraciu apaca je vymazat httpd.conf a urobit si ho od zaciatku, direktivu po direktive. Je to mozno trochu zdlhave, ale na konci dna ziskas konfiguraciu, v ktore bude len to, co potrebujes, a ktorej budes do detailov rozumiet.

[artec]

Jedna vec je ta, ze kdyz uz je tazatel na tom tak, ze konfiguruje 2 MPM moduly najednou, tak by si o tom mel nejdrive neco precist, aby zjistil o co se vubec pokousel a mel vubec sajn co vlastne dela.

Druha vec ale je, ze doporuceni zmeny MPM na worker by se dalo jednoznacne doporucit pouze v pripade, ze by apache nepouzival zadne rozsireni, o kterych se tazatel nezminil. Pokud by tam nejake mel, tak zalezi na tom, jak dobre dokaze pracovat s vlakny. Navic jeste neni vubec jiste, jestli dojde pouzitim workeru ke zvyseni vykonu nez u preforku. Pokud by tam mel napriklad rozsireni PHP (i s podporou thread safe), tak pouzitim workeru s vice vlakny dojde k propadu vykonu nez pri pouziti preforku.

[cronin]

Odporucil som nastudovat si problematiku a az nasledne zvazit zmenu MPM implementacie. Takze ak nemas sam lepsiu radu ako navazat sa do niekoho, kto sa radu pokusil dat, a to navyse hypotetickymi namietkami "what if", zdrz sa komentara.

[artec]

Muj prispevek byl pouze doplneni toho tveho. O nejakem navazeni se do nekoho snad nemuze byt ani rec...

[Vlada]

No snazim se do problematiky vice proniknout, na serveru bezi PHP i MySQL, mam pocit ze problem bude spojen prave s Mysql a pconnect (v php kodu).

Pocet procesu u MySQL nestacil tak jsem ho zvetsoval ale porad to casem doslo na hranici (MySQL hlasilo prilis mnoho spojeni), jelikoz jak jsem nakonec zjistil se procesy ukoncovali az po 8 hodinach (vychozi nastaveni), jsem direktivou v my.cnf nastavil na 10s pak se proces pri necinosti ukonci, zda se ze to pomohlo a rychlost webu se nijak nezhorsila.

Vypada to ze apache si s kazdym procesem mysql drzel svuj proces, kdyz dosli tak to spadlo, zvysovani MaxClient a Server se povedlo jen castecne protoze apache ma asi zakopilovany nejake sve limity.

Mozna jsou tyto uvahy spatne, zatim do toho jen pronikam ale zda se ze se to zlepsilo.

[AraxoN]

Persistentné spojenia odporúčam nepoužívať. Hlavne ak sa používa viac databáz pri hostingu viacerých projektov. Skončí to tak, že každý apache je pripojený ku každej databáze, resp. skončí to skôr, lebo mysql má defaultne nízky limit počtu spojení.

[Vlada]

Diky, to vicemene potvrzuje me uvahy. Nemohu zarucit ze nekdo na svem webu nepouzije persistentni pripojeni. Je mozne pouzit nejakou direktivu, ktera bude pconnect ignorovat a bude procesy nekompromisne ukoncovat ?

dekuji

[oron]

snad v php.ini

mysql.allow_persistent = Off
 

[Vlada]

OK diky, to bude ono nenapadlo me hledat v php.ini

 

diky