apache tuning ? Teljesítmény gondok

 ( manci | 2009. október 18., vasárnap - 10:49 )

Sziasztok !

Van két szerverem amelyik load balance-al működik.
Debian 4.0 apache 2.2.3 / php4 . A gépek 4 magos 4Gigás szerverek.

Az a problémám , hogy úgy tünik ezek a gépek nem elegendőek a kiszolgálásra.

StartServers 100
MinSpareServers 10
MaxSpareServers 120
MaxClients 436
ServerLimit 436
MaxRequestsPerChild 0

Gyakran tapasztalom , hogy valamiért megugrik a memória használat és elkezd swapelni a gép (mindkettő).
Milyen módszereket javasoltok , hogyan lehetne:
- jobban tuningolni az apache processeket
- tracelni mi eszi meg a memóriát ?
- eldönteni, hogy elértük-e a szerver fizikai korlátait ?

köszi!

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Ha nem 500 oldal fut ezeken a gépeken, amiből legalább 100 masszív terheléssel működik, akkor nem érted el a gépek fizikai korlátait.

Egyenkét is elég erősek LAMP-ra, nemhogy elosztva. Érdemes lenne tudni, hogy milyen terheltségű oldalakat hostolsz, és kb. mennyit. Csak hogy legyen mihez viszonyítani a configot.

Az mpm worker, vagy prefork?

Egyébként:
- MaxRequestsPerChild 0 szerintem kevés, többnek kellene lennie, mert így mindig új szálat nyit.
- Startservers 100 sok, MaxClients 436-hoz (ez egyébként hogy jött ki?) képest biztos.

Szerintem az apache rendesen el van konfigolva, az nem lehet a gond?

(beépülő pluginjaim: imho és fixme :) )

A MaxRequestsPerChild nem az amire gondolsz szerintem:

The MaxRequestsPerChild directive sets the limit on the number of requests that an individual child server process will handle. After MaxRequestsPerChild requests, the child process will die. If MaxRequestsPerChild is 0, then the process will never expire.

Viszont azt tényleg érdemes beállítani ha a memóriaszivárgás zavar. Márpedig az apache szivárog rendesen. Próbáld ki valami 1000 alatti értékkel.

A StartServer csak eleinte számít, szerintem mindegy mire állítod MinSpareServers és MaxSpareServers között.

Sejtettem, hogy a 0 lehet nolimit is, de lusta voltam manualba nézni :)

Az hogy mpm worker v. prefork azt honnan tudom ? mert nincs ilyen modul beapplikálva csak a default etch httpd fut.

m.

dpkg -l | grep apache

apache2-mpm-prefork..

köszi,
m

Ha megtudod oldani szerintem probalj atallni worker-re. Prefork iszonyat sok memoriat zabal.
Viszont a php tudomasom szerint nem nagyon mukodik jol vele (kiv. fastcgi-vel).

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

Van-e valami trace opció amivel lehetne jobban belőni miért nem képes az apache kiszolgálni a kéréseket ?

Van mégy egy érdekes sztori , éspedig a session store egy nfs-el van megosztva , de nem látom ennek köze lenne hozzá :
avg-cpu: %user %nice %system %iowait %steal %idle
13,40 1,29 1,09 6,43 0,00 77,78

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
cciss/c0d0 69,05 1032,00 944,54 84319572 77173376

m.

csak prefork lehet, ha php is van...

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

KeepAliveTimeout mennyire van állítva?

#Timeout 300
Timeout 10
#
# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
#
KeepAlive On

#
# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.
#
#MaxKeepAliveRequests 100
MaxKeepAliveRequests 400

#
# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.
#
KeepAliveTimeout 5

#KeepAliveTimeout 2

1) Csinálj egy cronjobot ami kettő percenként lefut és lekéri a full szerver statuszt. Ezzel pikkpakk kiderül, hogy pontosan melyik site-ra szálltak rá.

2) Ha 64bites rendszer, akkor a 4G memó apache-al elég hamar elfogy, főleg ha más is megy a gépen. Tehát +4GB-t érdemes beleszórni. Első körben azért a fölösleges apache és php modulok kiszórásával lehet spórolni néhány MB-ot apache-onként.

3) Ha tényleg rászállás, azaz DoS vagy DDoS jelleggel szállnak rá egy oldalra, akkor IP-t tiltsd ki és írjál a hálózatilag illetékesnek is. Az oldalra pedig mod_cband vagy hasonlóval tegyél külön korlátokat, de sávszélességre ne, csak a kliensek számára.

Ezzel is érdemes lehet próbálkozni:
http://code.google.com/p/compcache/
Pont ilyen swap-elős hibákhoz ad kis segítséget, de az alap problémádat nem fogja megoldani.

Érdemes lehet a php.ini-t is átnézd, mert ha sok szálon dolgoztatja a php-t az apache, az is tud szépen enni erőforrást még normális üzem mellett is.
Én az erősen php-t használó oldalakhoz az eaccelerator-t használom. Volt olyan gépem, ahol 12-14-es load-ból (kis mysql állítással) 0.5-2 közöttit csinált.

csereld le nginx-re es egy-ket evig nem kell gepet boviteni ;)

--
When in doubt, use brute force.

+1
Vagy lighttpd. Bár ez inkább a probléma megkerülése, mert ki tudja miért kell az apache...

Egyrészt, másrészt meg ha a PHP miatt swappel gigabájtokat, akkor a php-cgi szálak miatt fog elszállni a gép.

Még olyanra gondoltam, hogy valamilyen nagytehetségű juzer feltett egy PHP-s fileletöltő cucc és sokMB-os cuccokat tol át így az Apache-PHP duetten. Ez főleg akkor nyerő, ha nem szép folyamatosan olvas be és ír ki, hanem puff beolvas és majd valahogy leszedi a kliens.

Azért a fastcgi esetében elég egzakt módon meg lehet adni, hogy hány szálat indíthat egy fastcgi daemon és hány daemon indulhat el.
Tehát ha minden kötél szakad, a gép még működőképes, reakcióképes maradhat más téren attól, hogy a webserver vár egy szabad cgi szálra.
Persze azt is hozzá kell tenni, hogy extrém sok találat esetén, ahogy én a teszteket néztem a neten, a fastcgi módszer valamennyivel lassabb feldolgozást ad.