Tweak week (eek!): Apache, MySQL.

A Critical Mass (már csak négy nap!) mindig új, vagy módosított konfigon futó szolgáltatásokat igényel, mivel teljesen más jellegű terhelést ad a szervernek, mint a „mindennapi” forgalom: sok kicsi, viszonylag kis forgalmú, sok esetben szimpla statikus, vagy kis adatbázissal operáló site helyett egy baromi nagy dinamikus site, viszonylag nagy adatbázissal (400 mega körül tán?), sok látogatóval. Mindezt persze úgy, hogy közben a kis siteok forgalma ugyanúgy jelen van, és természetesen biztosítjuk. Az ilyen időszakok lehetőséget adnak egy kis tweakelésre, ez történik tegnap/ma is.

Tavaly a Drupal cache bekapcsolása és a Lighttpd kipróbálása volt soron, amit végül a .htaccess támogatás hiánya (és az ezáltal okozott kényelmetlenség) miatt pihenőpályára tettem.

Mivel tavaly szeptemberben gépcsere volt és több erőforrással gazdálkodunk, idén próbálok az Apache keretein belül maradni, a Lighty csak végső megoldásnak marad. Lássuk, miket fogok most (negyed óra!) életbe léptetni. (Van, amit már napközben megtettem.) De előtte (drámai feszültség!) nézzük át, hogy mit miért arra, amerre. Alapvetően ugyebár egy szerverben három erőforrással ga(rá)zdálkodunk (a lemezkapacitásokat most nyugodtan vehetjük végtelennek):

• processzoridő
• fizikai memória (ha terhelt rendszeren swapolni kell, rég rossz)
• disk i/o.

A két szerver pedig, amivel most dolgozunk, az az Apache és a MySQL. (Apache alatt pedig a php, mint főbűnös az esetek 80%-ában.) Szóval lássuk, mivel mit.

• Apache-ban KeepAlive visszakapcsol, MaxKeepAliveRequests 0 (vagyis végtelen), viszont KeepAliveTimeout 4 (másodperc). Vagyis nyitva hagyjuk azokat a kapcsolatokat, de csak rövid ideig. Még az is lehet, hogy a Timeout értéket 2-re veszem majd le. Ezzel elvileg prociidőt nyerünk, mert nem kell mindig újranyitni mindenféle socketeket. Cserébe ezek a processzek kicsit tovább foglaltak az új kérések kiszolgálása elől, mint KeepAlive nélkül.
• MaxRequestsPerChild 200-ra fog (talán) csökkenni (400-ról). Ettől azt várom, hogy a memóriazabáló Apache processzek gyakrabban dögölnek ki, ergo általánosságban több memória lesz. Persze nem megy áldozat nélkül, a gyakrabban kigyilkolt processzek gyakoribb újprocessz-forkolást eredményeznek, ami viszont többlet prociidőt igényel.
• A criticalmass.hu .htaccess file-ját statikusan betettem a VirtualHost konfigba, így egyszer, induláskor olvassa be, nem minden eléréskor. Kicsi előny, de dob valamit a teljesítményen. (A flexibilitás feladásával.)
• A MySQL fő problémája jelenleg a disk i/o bottleneck. Amikor szegény elkezd valami olyannal dolgozni, ami nincs memóriában, akkor a load általában felpattan 20 fölé. Ennek kiküszöbölésére a Critical Mass adatbázisa átkerül egy külön fizikai RAID tömbre (és symlinkkel lesz visszalinkelve az eredeti helyére), vagyis teljesen más diszkek fogják kiszolgálni, mint a többi oldal adatbázisát és a CM statikus tartalmát. Ettől természetesen a disk i/o, végső soron az iowait érték (van, hogy 50% fölött!) drasztikus csökkenését várom, és overall egy teljesítmény boostot. Probléma ezzel akkor lehet, ha a CM adatbázis adta eddig a mostani RAID tömb fő terhelését. Ez esetben annyi fog történni, hogy a terhelést áttettük az egyik tömbről a másikra, amivel nem segítettünk magunkon. A megoldás az, hogy az adatbázis file állományát is szét kell dobálni fizikailag különböző lemezekre, tehát pl. az indexek az egyiken, az adatok a másikon.
• Némileg unrelated, de a rendszer általános reszponzivitása érdekében renice-oltam (negatív irányba, vagyis prioritást emeltem rajtuk) a slapd-t és az nscd-t. Ezek szolgáltatják, illetve cache-elik az autentikációs adatokat, tehát fontos, hogy mindig reszponzívak legyenek.

Elgondolkodtam még a külön Apache telepítésén, amivel sokkal könnyebb a bütykölés és a külöbnöző értékek állítgatása – de az majd következő körös lépés lesz.

Update 1: MySQL adatbázist áttettem, lássuk mit mond az iostat.

Update 2: Részlet a gépház levelezéséből!