VPS processor terhelése és szabályozása

Linux-kezdő

Sziasztok,

saját VPS-men, amin egy Debian Wheezy fut. A szerveren inkább Drupal oldalak futnak. Ezért nagy erőforrásokra van szükségem. Kérdésem, hogy hogyan lehet a terhelést elosztani. pl: Nézem a HTOP-al a szervert, hogy alig mozdul ki a CPU, ha frissítem az oldalamat, de az oldal lassan töltődik be. Tesztként elindítok pl: egy tömörítést, akkor az oldal szintén lassabban töltődik be, de a CPU terhelése nem nagyon megy 50% felé.
Amit szeretnék, hogy ha oldalakat töltök, akkor mennjen fel azonnal 80% körüli értékre és a többi dolog pedig lassuljon le. Kérdésem, hogy ezt hogyan lehetne kivitelezni, miket kellene átnéznem ehez?

Köszi!

KALMI

  • 5227 megtekintés

( andrej_ v | 2014. 01. 04., szo – 00:28 )

A PHP opcode cache, memcached vagy xcache variable cache körökön és optimalizálásokon már ugye túl vagy? Jó kiinduló pontot szokott adni pl. ez az oldal: http://tools.pingdom.com/fpt/

Hát sorrendben ezek a tippjeim, de kisebb guglizást is igényel:
- Ha Apache+mod_php-val dolgozol, akkor a php-fpm-re érdemes áttérni és megfontolni hogy lighttpd vagy nginx legyen a webszerver. A nemhasznált apache és PHP modulokat értelem szerűen letiltani, pl. ha PHP-zol, akkor a cgi-s apache modulok valszin nem fognak kelleni, ha CGI-s php akkor úgyis fastcgi-t ajánlanak és talán php-fpm-hez is.
- Érdemes egy xcache vagy apc telepítése, mint php opcode cache. Mindkettő egyszerű, szépen beépülnek, monitorozhatóak és nem kell minden egyes lapletöltésnél futásidőben fordítani a PHP kódot a nulláról.
- Kimenet (főleg js és css) tömörítése, apache-ban mod_deflate.
- A pingdomon leírják, hogy az adott oldallal szerintük mit érdemes csinálni, ilyen szokott lenni a kliens cache engedélyezése, a css/js file-ok aggregálása (Drupal ala van egy Boost nevű modul ehhez)
- Memcached vagy xcache esetén a változó cache (erősen memcached jellegű) használata, szintén a Boost modul jön képbe

A helyzet az, hogy ezek elsőre tűnnek csak szerverkímélő dolgoknak, de a kedves látogató élményét is nagyban növelik. Jóval gyorsabbá és pörgősebbé válik egy 1-2 js/css file-al dolgozó és a kliens cache-ét használó oldal betöltődése. Hiába van adott esetben 50Mbit/sec is a kliensnél, ha akár 80db-ból kell összepakolnia a böngészőnek a weboldalt. A Firefox 15 szálon kezd tölteni és sorban halad...

Mindenképp lépésenként haladj és nézd, hogy melyik lépés hol és miben számít.

( thxer v | 2014. 01. 04., szo – 00:29 )

1 oldalbetöltés valószínűleg egyszerre csak 1 magot fog terhelni, próbáld meg ab-vel (http://explainshell.com/explain/1/ab) tesztelni, akkor valószínű 100%-ig fog menni, ha a -c-t legalább annyira állítod, ahány magod van.

( lavian v | 2014. 01. 04., szo – 00:33 )

Ugyan nem az általad felvetett irány, de ilyen jellegű dolgot (sebesség) ezekkel szépen lehet áthidalni:
- php cache/accelerator
- apache disk/mem cache
- apache mod_expires
- memcached modul drupálhoz
- statikus adatok file-ba cache-elése drupálnál
- reverse proxy

Nem írtad, de szóba jöhet még: vár az adatbázisra és a lemezre. Előzőt finomhangolással lehet javítani az utóbbira mondjuk valami ssd-n alapuló block-cache lehet a megoldás - én flashcache párti vagyok -, bár ezzel az adatbázist is lehet szépen gyorsítani.

Vagy a fentiekkel megegyező megoldás.

Köszönöm! Nézem is ezeket :)

Egy tapasztalati, nagyon általános kérdésem lenne, hogy egy Drupal 7-es oldal, ami mondjuk napi 100 regisztrált látogatót és mondjuk ugyan ennyi nem regisztrálatlan látogatót fogad annak mi lenne az optimális VPS server paramétere, azaz egy ilyen oldal milyen erőforrásokat igényelne, egy nagyon gyors, jó futáshoz?

Jól beállítva kényelmesen el kell mennie 512-768MB körül (FPM-el), de a MySQL közbeszólhat, mert az InnoDB-nek elég jó memória igénye van, de az is hangolható. A mysql-edre a mysqltuner.pl -t érdemes ráereszteni, az ad néhány tippet. Egyébként alapvetően a lapletöltések száma a mérvadó és hogy miket töltenek le, pl. olyan oldalt ami 23293239823db Drupal modul rak össze, galériát böngésznek vagy a korábban javasolt valamilyen cache-ből (előre generált html, memcached, xcache akármi) érkezik...

Hát nem tudok semmit az oldalról, de mondjuk ez jó méréshez, hogy lásd változik-e valami, ha csinálsz valamit, ne csak szemre menjen a dolog:
http://gtmetrix.com/

Amúgy hogy hány ember jár arra, az másodlagos. Hány oldal letöltés van, mekkora egy oldal, a mikor kigenerálódik, hány modul lapátolja össze, miből szedi össze az oldalt, ahonnan összeszedi az mennyire terhelt, mennyi a statikus elem az oldalon, ha van javascript-ed az hívható/tölthető-e async módban, egy időben többen is nyomkodják az oldalad vagy időben eloszlik a dolog átfedés nélkül...

Mondjuk egy fórum, alap hír oldal, a fentebbi javaslatokkal 1GB RAM és 2/4 CPU maggal cache-ből, cache-elt adatbázisból szépen elmegy. De ez hatalmas általánosítás, szóval nem mérvadó az oldalaid és szervered ismerete hiányában.

Olvass, tesztelj és mérj! :)
A szentháromság.

Utólag jutott eszembe, hogy a naplózás is tud ültetni vasat rendesen, szóval érdemes arra is ránézni.

Alapvetően két módszer van: magát a mysql server-t "tuningolod", illetve magát a használt adatbázis szerkezetét is célszerű. Ez utóbbival nagyon sokan nem foglalkoznak, néhány index nagyságrendi gyorsulást (vagy akár lassulást) is okozhat. A mysql szerver terhelését "élőben" mytop-pal tudod kényelmesen monitorozni, illetve javaslom kapcsold be a slow_query_log-ot (és persze log-queries-not-using-indexes).
Illetve célszerű még a query-ket is jól megfaragni, ott is nagyságrendeket lehet nyerni (vagy bukni), mert minden dbms-nek vannak heppjei. Persze ez "gyári" modulnál nem biztos, hogy lehetséges (vagy célszerű).

Persze mindez csak akkor igaz, ha db limites a dolog.

( denton | 2014. 01. 04., szo – 00:58 )

Kezdetnek el kell dönteni, hogy hol lassul be.

Egy sima php oldalt amiben nincs db is lassan tölt be?
Ha db-ből olvasol be akkor esetleg?

Vagy fájlelérés?

Illetve biztos, hogy az oldalbetöltés a lassú? Ha wget-el kérdezed le az oldalt, akkor is? (tehát nem a css-ek, js-ek stb lassítja be? drupálnál van ezer http lekérés a sok file miatt)

Nem lehet network probléma? Pl távoli a szerver esetleg? ping-el gyors az elérés?

Ha mindenre pozitív (szerk: vagy inkább negatív bocs) a válasz, akkor nem 100%, hogy a szervernél kell keresni a hibát, hanem lehet, hogy a drupál oldalban van valami genya, pl béna modul.

Egy php oldalnak nem kötelező azonnal 100-ra pörgetnie a cpu-dat. Olyan mintha a kocsiddal egy 10 méteres útra is 100-ra akarnád pörgetni a motort (most hanyagoljuk el a gyorsulás tényét)

( kalmarr | 2014. 01. 04., szo – 01:42 )

Olyan kérdésem van még, hogy pl: MySQL adatbázis CRON-ba történő optimalizálása, javítás jó ötlet?