Apache optimális beállítás nagy terhelés mellett!??

Hálózatok általános

Olyan kérdésem lenne, hogy milyen apache beállítás lenne optimális egy intel core i7-re 8GB RAM-hoz, a weboldalon egy időben kb 3000 user van online, ez elég sok lekérdezés másodpercenként, a load csúcsidőben 40-50re is felugrik, van mikor még magasabbra, most épp 60 felett van...

jelenlegi beállítások:

ServerLimit 20 <- ez mondjuk nem is kellene ide, mind1...
StartServers 10
MaxClients 1024
MinSpareThreads 200
MaxSpareThreads 600
ThreadsPerChild 64
MaxRequestsPerChild 3300

KeepAlive On
MaxKeepAliveRequests 1500
KeepAliveTimeout 3

Proci infó:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz
stepping : 5
cpu MHz : 2793.000
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr sse4_1 sse4_2 popcnt lahf_lm ida
bogomips : 5333.54
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

Memória info:

MemTotal: 8199516 kB
MemFree: 64080 kB
Buffers: 1385052 kB
Cached: 2361872 kB
SwapCached: 812 kB
Active: 3894628 kB
Inactive: 3653144 kB
SwapTotal: 3229024 kB
SwapFree: 3228208 kB
Dirty: 64492 kB
Writeback: 0 kB
AnonPages: 2137164 kB
Mapped: 878712 kB
Slab: 452848 kB
SReclaimable: 404528 kB
SUnreclaim: 48320 kB
PageTables: 74344 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 7328780 kB
Committed_AS: 14891804 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 288088 kB
VmallocChunk: 34359450175 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB

Remélem tudtok segíteni :) esetleg írjátok, hogy milyen adatokra lenne még szükség, a mysql beállításban sem vagyunk biztosak, hogy jó, de egyelőre az apache a gond inkább.

  • 6196 megtekintés

( neutrino v | 2009. 10. 19., h – 20:14 )

Az adatbázis biztosan a legszűkebb, amennyire csak lehet?

127.0.0.1 SWEET 127.0.0.1

( Andrej84 | 2009. 10. 19., h – 21:24 )

Csak érdeklődés szintjén kérdezem, hogy milyen komolyságú weblapról van szó.

Nézd meg, hogy top mit ad vissza, mi terheli a rendszert!
I/O wait mekkora? Használsz memcached-et? Van RAID vagy LVM?

Érdemes megnézni a következőket, ha mysql van, és saját fejlesztésű cuccról van szó:
"SELECT * FROM" ne leygen, ha nem feltétlenül szükséges
"SELECT COUNT(*) FROM" helyett használd ezt "SELECT COUNT(column_name) FROM"

3000 user az kb hány lekérdezést jelent óránként?
Milyen méretű az az adatbázis, amit használsz?

elég komoly a weblap, egyébként egy fizetős cms-el megy (expressionengine)

I/O waiting ugrándozik 0 és max 12% között, olyan átlag 3-5%

memcached van RAID nincs, ja és még van eAccelerator
4,5millió oldalletöltés óránként, a lekérdezések számát nem tudom.

adatbázis 150MB

Mysql beállítások:

user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
language = /usr/share/mysql/english
character-set-server=utf8
collation-server=utf8_general_ci
default-character-set = utf8
default-collation = utf8_general_ci
init_connect='SET character_set_connection = utf8;set collation_connection = utf8_general_ci; set character_set_client= utf8; set character_set_results= utf8;'
skip-external-locking
bind-address = localhost
key_buffer = 1024M
max_allowed_packet = 16M
thread_stack = 4M
thread_cache_size = 100
myisam-recover = BACKUP
max_connections = 100
table_cache = 2048
join_buffer_size = 8M
query_cache_limit = 2M
query_cache_size = 64M
log_slow_queries = /var/log/mysql/mysql-slow.log
expire_logs_days = 10
max_binlog_size = 100M
connect_timeout = 15
interactive_timeout = 100
myisam_sort_buffer_size = 64M
read_buffer_size = 2M
read_rnd_buffer_size = 2M
sort_buffer_size = 4M
thread_concurrency = 4
wait_timeout = 200
query_cache_type=1

fcgid conf:

AddHandler fcgid-script .php .php5

AddHandler fcgid-script .fcgi .php
# Where to look for the php.ini file?
DefaultInitEnv PHPRC "/etc/php5/cgi"
# Maximum number of requests each process should handle before it is terminated
MaxRequestsPerProcess 1000
# Maximum number of processes to spawn
MaxProcessCount 50
# Number of seconds of idle time before a php-cgi process is terminated
IPCCommTimeout 60
IdleTimeout 60
# Executable to run
FCGIWrapper /usr/bin/php-cgi .php
# Limits on Apache processes itself

Egy gyors próbaként a memcached-et kitehetnéd másik gépre (light proci, "sok" RAM). Ha már az adatbázist macerásabb.
Egy vason szegény szerverek (apache, mysql, memcached, rendszer) veszekednek a memórián, fellélegezhetne az apache, a mysql, ha jutna neki több RAM.
A próbához akár egy notebook is elég, amit ideiglenesen beteszel.

Maradjunk annyiban, hogy nem értelmetlen, hanem te nem érted.
Szerinted egy Gb-es belső hálón mennyit vesztesz, ha - mondjuk - a html cache-t egy másik gépen írod memcache-be, és nem HD-re teszed le? Vagy sql query cache-nek használod?
Ezzel szemben miért is jobb, ha elveszel a rendszeredtől memóriát azért, hogy cache-eljél bele, így aztán a rendszernek nem marad memóriája, hogy ő cache-eljen? Ha már szerencsétlen gépen egy helyen van a http szerver, adatbázis szerver, akkor ne bonyolítsuk az életét azzal, hogy még memcached is fut rajta. Pláne, ha úgyis csak egy gép van, tehát a cache nyugodtan íródhatna shared memoryba is.
A memcache igazi előnye ott kezdődik egyébként, amikor több frontendről szolgálsz ki, és az összesről elérsz - hálózaton - egy memcache szervert, ahová cache-elsz. Ebbe a vasba nem nagyon kell a sok memórián kívül szinte semmi, és nagy forgalom esetén, ha tipikusan sok olvasás van, nagyon sokat jelent. Egy frontendnél (ha várhatóan az életciklus alatt nem is lesz több) eszembe nem jutna a memcached, elég sok bajom volt a szemét(nem)gyűjtésével, oda az shm szerintem jobb megoldás.

Van amikor egy gep eseten is hasznalhato a memcached, ha pl. az adatbazis cache-e ugyetlen (ld. mysql), vagy ha egyszeru key-value parokat kell tarolni. Bar az is igaz, hogy ha van eleg memoriad, akkor az sql szerver az adatokat is memoriaban tarthatja.... Merlegelni kell.

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

( YanChi | 2009. 10. 20., k – 07:31 )

Amikor én ilyennel szembesültem, elkezdtem a kód részleteinek futási idejét mérni, és aránylag hamar kibukott, hol volt a szűk keresztmetszet. Meg kellene nézni, hogy hány párhuzamos szál fut az apache-ból, mert lehet, hogy az túl sok. És ha gondolod keress meg privátban, több nagy site-on csináltam már optimalizálást, esetleg tudok segíteni.

( lacika v | 2009. 10. 20., k – 10:49 )

Meg segíthetne egy combosabb Xeon (nehalem) alapú több CPU-s több memóriával rendelkező masina a jelenlegi helyett. (bár az igaz, hogy pontos leírást nem adtál a gépről).
Memória elég neki a 8GB? Nem swappeli agyon magát?

--
http://laszlo.co.hu/

Szerintem pont a linux az, ahol nem feltétlen növelni kéne az erőforrásokat, hanem lehet optimalizálni a beállításokat, kódot.

Ez nem feltétlen csak a linuxra vonatkozik.
Memóriát keveslem egy kicsit. Több memóriával lehetne az adatbázis cache-t növelni, az eAccelerator is kaphatna több memóriát, az apache meg egyenesen repesne az örömtől.
Nem szükséges apache modulok ki vannak kapcsolva? Kicsinyes dolognak tűnik, de nem biztos, hogy az ekkora látogatottságú oldal esetén.
Teszt céllal nem tudod az adatbázist külön vasra tenni?
A mod_status -t érdemes lehetne kis időre bekapcsolni, hát ha onnan több infót kapsz.
Lehetne nézegetni az iostat -x -et és a vmstat -ot is.

--
http://laszlo.co.hu/

Ez mindenképpen egy érdekes kérdés, hogy merre érdemes elindulni. Webszerver és honlap optimalizálás, vagy vas bővítés. Ugye egy agresszív cache-elés után már nem nagyon van mit tenni, mint hozzányúlni a bővítés kérdéséhez. Hozzáteszem nem biztos, hogy az optimalizálás a legköltséghatékonyabb megoldás, főleg a mai vas árak mellett.

Azért nagy meglepetéseket tud okozni, ha valaki olyan nyúl hozzá a kódhoz, aki terhelés oldalról áll hozzá a feladathoz. Van egy olyan limit, ami felett már drága vasat bővíteni, viszont, ha tudod, hogy egy-egy általánosan használt megoldásnak lehet olyan alternatívája, ami az adott helyen negyedakkora procit eszik, mégis ugyanazt eredményezi, akkor összességében 20-30%-ot simán lehet fogni. És ezt nem egy gagyi kódnál (ott nyilván többet is).

Egy szóval sem mondtam, hogy az i7 nem nehalem arch. De lássuk be, hogy nagy eséllyel fog jobban teljesíteni a site pl. egy 2 vagy 4 CPUs Xeon CPUkkal ellátott vasban, mint a jelenlegi (asztali?) PC-n. Lehetne egy load balanced webszerver park irányába is elindulni kisebb gépekkel. Ne akarjunk már egy ekkora látogatottságú site-ot kiszolgálni egyetlen egy géppel. Vagy try & buy -al ki lehetne próbálni pl. egy ilyenen: http://www.sun.com/servers/x64/x4450/specs.xml Azért a 24 CPU core biztosan jobban fog teljesíteni, mint a mostani rendszer. Ha meg még sem, vissza a gép a feladónak.

--
http://laszlo.co.hu/

en nem ezt mondtam. hidd el, nem a levegobe beszelek (bizonyitani had ne bizonyitsam most referenciakkal), amikor azt mondom, hogy terveztem mar kisebb-nagyobb rendszereket. az 5 uj vas helyett az swk beallitasa/lecserelese es egy kis rendszeroptimalizalas sokkal kifizetodobb, es meg penzbe sem kerul (max oradijba).

mentunk mar olyan helyre tanacsadni, ahol bevolt rakva 2 db szerver, 4 webszerver, meg egy proxy, es jottek hogy "jajdehat nembirja 17req/s folott!444". betuningoltuk az sqlt, felment duplajara. megneztuk sql logban, hogy mit tol ki az oldal, es akkor kb felalltam, hogy ezzel igy nem lehet mit kezdeni.

ertsd, oldalletoltesenkent generalodott kb 400-600 query, 80% select + 20% insert [imadom ezt a "tartsunk minden countert a dbben!!" mentalitast is].

szoval meselhetnek en, hogy milyen gany rendszereket lattam. ez ala tolhatsz vasat, tuneti kezelesre tokjo, ha birja az uf penztarcaja. ha meg nem, akkor kerem ugy kell tervezni a rendszert. jahogy ahoz hozzaerto architectek, es normalis programozok kellenek?

+1 az alkalmazas tuningolasra. Egyszer kapcsolatba kerultem egy olyan brigaddal, de aztan szerencsere elvaltak utjaink, ahol Php Pistike sulyos n * 10k tmp, session, whatever file-okat egy konyvtarba tett, es csodalkozik, hogy valami nem koser...

oldalletoltesenkent generalodott kb 400-600 query

Az nagyon korrekt...

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

nemhittem hogy valaha eztfogom mondani, de kifejezzen orulok hogy egyetertesz velem :P
ez a php pistike amugy nepbetegseg, ugy veszem eszre..

mint ahogy egyik topicban volt [itt a hupon], hogy volt valami cuccuk, lassu volt, es a srac X post utan beirta, hogy "eddig nem emlitettem, de a sessionok shared nfsen vannak"

*bang* :)

php-ban amugy lehet jo dolgokat csinalni - ha az ember ert hozza. Nyilvan a feladathoz kell az eszkozt kivalasztani. Mondjuk egy email spamszurot azert nem php-ban irnek meg (pedig a nyelv mindent a rendelkezesedre bocsat, ami csak kellhet hozza). A php azert veszelyes, mert konnyen ossze lehet dobni benne egy (valahogy) mukodo dolgot. De egy nagyobb forgalmu vagy fortune500 dolgot mar alaposan at kell gondolni. A kulonbseg csak annyi, mint atmenni egy vekony pallon 30 cm 'magasban' vs ugyanazon a vekony pallon atmenni 200 m magasan.

Hogy a tulvilagot maskent latjuk, az meg nem akadalyoz meg abban, hogy elismerjem, ami igaz, az igaz (=hw bovites elott sw optimalizalas).

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Hihi, ilyet én is láttam, több szerveres kiszolgálásnál simán megosztott partícióra tették az oldal cache-t, hogy minden gép lássa, ne kelljen mindegyiken létrehozni. Aztán egy hónapig álltak felette értetlenül, hogy vajon miért nem működik már közepes terhelésnél sem.
Mondjuk, hamar kiderült, amikor elkezdtünk futási időket nézni, és a cache-ből jövő részek százszor lassabbak voltak, mint ugyanaz cache nélkül. De nagyon haragudott érte az, aki elcseszte, még hetekig bizonygatta, hogy nem ez volt a hiba.

elobb arra kene megtalalni a valaszt, hogy mi a feladat, utana mar el lehet donteni, hogy valoban kell-e hozza (ex-has) 85 counter, stb. Ha arra jutunk, hogy kell (es azok olyanok), akkor tegyuk db-be (vagy memcached-be (tobbe), es onnan kesleltetett batch feldolgozassal db-be).

Figyeld meg, hogy nem a db-be pakolas ellen van kifogasa, hanem azert csovalja a fejet, mert 1 oldal legeneralasahoz n * 100 qry kell.

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

( cydrk | 2009. 10. 20., k – 14:37 )

Szvsz ilyenkor szoktak a jol bejaratott skalazas buzzwordot emlegetni. Neked is az kene, elsore kulon gepre rakhatnad a mysql-t. Gondolom az nem nagy penz ennyi userrel. Akkor nem kell meg balance-erbe gondolkodnod meg logic szetvalasztasban.

B, ha mindenkep ezt a gepet akarod nyuzni akkor elso lepeskent
- timeout off, tiltsd le, a preforkos apache -od modphp-vel rendkivul halas lesz ha nem foglalod a szalakat.
masodszor,
- Timeout = (5|10|15|30) valahogy igy, mentsd az apache-od segget.

Preforknal nem anyira a request/sec -el van a gond hanem azzal ha 1-1 szalat tartasz azhelyett hogy processaljon tovabbi kereseket.

A masik ami erdekes lehet neked
- MaxRequestPerChild, ne rakd 2-3k nal magasabbra, regen rosszul birta.

Azon kivul amit tobben is irtak, optimalizalj optimalizalj optimalizalj az alkalmazason, ha fizetos akkor sokat ugysem fogsz tudni valszeg ezert skalazz. Tedd mysql-t kulon gepre, szeretni fodja. Ha nem jon be, probald meg leszerelni a prefork-ot workerre es fcgi-php-t helyette, jo, kb 1,5x gyorsabb tud lenni, viszont hajlamos segfaultolni. Cherokee -val (ha mindenkep 1 gepen akarsz maradni) sikerult stabilra beloni es apachenal kis tulzassal duplajat tudja kitolni.

hf gl

drk

UI: ketfele skalazas letezik, vertikalis es horizontalis, vertikalis amikor veszel erosebb gepet. Ezeknel az opensource cuccoknal amiket nem erre talaltak ki, ugyis limitbe fogsz utkozni bizonyos ertekek utan. A horizontalis amikor sok kevesbe eros geped van es megosztod koztuk a terhelest. Lehet erositeni, lehet skalazni.

UI2: latom fcgi mar, sry :$

workeren van nem preforkon

ui: egyébként thx a javaslatokat, most készülünk venni majd egy izmosabb gépet, de lehet hogy mellé lesz még1 külön az sql-nek, megátjuk

ServerLimit 20
StartServers 10
MaxClients 1280
MinSpareThreads 200
MaxSpareThreads 600
ThreadsPerChild 64
MaxRequestsPerChild 2500

ezek most a beállítások, 3300ról levettem 2500ra a maxreq/child-et de ezzel nemhiszem, hogy leőbbre vagyok. 1024-ről 1280-ra feltoltam még a maxclients-t. Majd kiderül később mikor mégtöbb ember lesz online. Most os 8-9 a load, de az oldal még gyors.

ui2:
mennyire gond az hogy a a php cgi-ként fut és nem modulként?

Régen hangoltam már apacsot (közel se akkora forgalomra, meg mod_perl-t), de ezek a thread számok bődületesek. A cgi-ként futtatott php sem ígér sok jót.
Mi az az oprendszer és proci, amelyik ennyit hatékonyan tud futtatni. Komolyabb terhelés esetén mennyit tölt ez a rendszer context switch-el meg spawn-al és io-ra várva?

Elvileg gond, mert cgi php hajlamos meghalni :)) attol fugg hogy confoltad 100k/1 500as internal errorral szalt nekem el :)
Nezz access logot mennyi az 500as error. Ugye olyant normal esetben nem dobna csak ha elkefeles van.

Szerintem kapcsold ki keepalive-ot es vedd le a timeoutot 30sec -re. Ami anyi ido alatt nem toltodik le, kit erdekel? :)) SOKAT fog segiteni.

Apache es utana savszel korlatai miatt altalaban nem eri meg webservert agyon turbozott tuning gepre rakni (ertsd eros serverre).

Amugy az alkalmazasba nemtudom mennyire tudsz belenylni, de a kepeket megerheti atrakni kulon serverre lighttpd -re vagy nginx-re.

Illetve erdemes ele rakni egy varnish-t (nem squid) es cache-eltess is vele. IRTOZATOSAN sokat fognak ezek dobni es php-kat amiket sokat toltenek 2-3 sec-re cache-eltesd el. Minden mast probalj onnan kiszolgalni.

APC -t ha meg nemlenne izzitsd be, perszecgi-vel valszeg nemfog menni rendesen.

Igy mondjuk azert nehez konkret tippeket adni :) de ezek artani nem fognak es sokat nyerhetsz.

drk

( tco99 | 2009. 10. 20., k – 16:35 )

"elég komoly a weblap, egyébként egy fizetős cms-el megy (expressionengine)

I/O waiting ugrándozik 0 és max 12% között, olyan átlag 3-5%

memcached van RAID nincs, ja és még van eAccelerator
4,5millió oldalletöltés óránként, a lekérdezések számát nem tudom.
"

Csak kiváncsiságból, lehet tudni melyik ez az oldal?

4,5 millió oldalletöltés * 24 óra == 108 millió oldalletöltés / nap. Ez már az iwiw -nél is több.

Mindezt 1 géppel?

( subchee | 2009. 10. 21., sze – 08:24 )

Hasonló load problémát úgy oldottam meg, hogy Lighttpd -re váltottam Apache helyett. A tesztek szerint az Apache volt az, ami a magas loadot okozta (sok megnyitott session) és közben várakozó pályára rakott sok kapcsolódni vágyó klienst. Próbálkoztam Apache tuninggal, RAID10 -el, memcache -el, eAccelerator -ral, stb -vel, de egyik sem jött be. Lighty + fastcgi meg szépen muzsikál.

Lehet hogy megerne az apache-t lecserelni, mondjuk en akkor nginx-et ajanlanam a lighty helyett.

Igazabol eleg durva dolgoknak kellene tortennie hogy egy mukodo apachet lecsereljek, pedig en nagy nginx fannak tartom magam.

Elso korben apc az musthave, szep nagy cachet adva neki.
Esetleg ha sok kulonbozo php fajlt szolgaltok ki (ugy olvastam), akkor erdemes a php.ini-ben a realpath_cache_size-t nagyobbra venni.

( b0b0 | 2009. 10. 30., p – 14:13 )

Sziasztok!

Nem akartam új témát indítani, hisz hasonló a kérdésem.
Adott: fast_cgi, mpm_worker, egy egyszerű php site (alap joomla telepítés). Erre küldöm a JMeter tesztelőjét: 20 konkurens júzer, 2 másodpercenként indít lekérést 10X ismételve. Az egész apache virtuális gépben fut (KVM) 512 mega memóriával, AMD Opteron 2,2 proci két VCPU.
Ha elindítom a tesztelést egy ideig kiszolgálja az apache a folyamatokat, aztán úgy kb. a teszt felénél lerohad a szerver és onnan kakukk.

Mit kellene beállítanom, hogy ha lassan is de kiszolgálja a felhasználókat és ne szálljon el az apache?

Előre is köszönöm!