MySQL optimalizálás játékszerverre

Adatbázis: SQL, XML DB

Sziasztok!

Adott egy HP Prloiant ML110-es gép szerverként, elsősorban játékszerverek futnak rajta. Nemrég kértek WoW-szervert is, ami brutális mérteű adatbázissal jár. (Alapjáraton ~100 mega, de 2 hét alatt megduplázódott, ilyen növekedés várható később is)
Ez persze elég rendesen leterheli a szervert, ami a többi szolgáltatás minőségén meglátszik, szóval nem tartható állapot. Szeretném valahogy a végletekig optimalizálni a MySQL-szervert, akár külön erre a célra futtatni egyet. Hogyan tudom megoldani, hogy ne terhelje ennyire? Gondoltam a progi processzoridejének korlátozására (hogyan?), a progi által használt sávszél korlátozására (iptables gondolom, de ahhoz sajnos nem értek), esetleg a MySQL-DB másik szerverre való átpakolására (belassíthatja jelentősen a WoW-ot, mert csak külföldi ingyenes hostolókat találtam, sajnos még nincs 2. szerver). De biztos vannak még jobb megoldások is, ha valaki tud ilyet akkor ne sajnálja;)

Köszi a segítséget!

  • 3777 megtekintés

( suvlaj v | 2006. 12. 21., cs – 16:11 )

Vicces volt azt olvasni, hogy a 100 Mbyte-os adatbázis méret "brutális". :)

Nem tudom mi az a wow server és hogy maga az adatbázis mennyire optimalizált de az biztos, hogy mysql és minden egyéb sql implementáció esetén leginkább a performancián javítani az indexek megfelelő módon való létrehozásával/módosításával lehetséges. Alternatív megoldás lehet még az egyidejű adatbázis kapcsolatok számának korlátozása vagy a mysql prioritásának módosítása de ezen utóbbiak csúnya és igénytelen megoldások ebben az esetben.

A 100 alapból nem lenne az, de egy ilyen szervernél vmiért mégis nagyon leterhelő. Gondolom azért mert nem túl sok a memória (1024) + a MySQL-t is lehetne még tovább finomítani. Amúgy most kb 1GB körül jár a DB, szal gyorsan szaporodik.

No igen, elfelejtettem leírni, hogy mi az a wow: World of Warcraft nevű MMORPG típusú játék. (én se nagyon ismerem, sosem láttam még magát a játékot, csak így szerverként, de mit tehetek, ezt rendelték)
Ami probléma főleg, hogy magába a szerkezetbe nem nagyon lehet belenyúlni (táblák, indexek...), mert az a progi miatt adott, szóval a csúnya és igénytelen megoldások maradnak csak. Azokat hogyan tudom kivitelezni? Mármint olvastam róla, de mik azok a reális értékek, amiket be lehet lőni? (mysql oldalán csak leírja a kapcsolókat, de hogy default mennyi, vagy max mennyi lehet arról nem szólnak)

Igen, közben utánanéztem én is, hogy mi ez wow..

MySQL-lel nem foglalkoztam mostanában de lennie kell egy config file-nak valahol, amiben szépen megtalálható az összes paraméter, majd aktuális ismeretekkel rendelkező emberek megmondják, bár megtalálni is max. 2 perc szerintem (mysql.conf ?). Magát az adatbázist hogyan hoztad létre? Valami program megcsinált mindent a'la csilivili vagy script-et kellett futtatnod? A tábla-struktúra természetesen nem változhat, de egy-két plusz index magának az adatbázist használó programnak csak javára válhat, gondot nem okoz (természetesen ha indokolt).
Jó lenne egyébként azt kideríteni, hogy miért a lassulás. Úgy értem első körben illene kideríteni, hogy a processzort terheli az alkalmazás vagy a disk-et? A mysqld fogja a processzort vagy a kliens program? Ha maga a kliens (ami itt egyben server is a gamerek felé) vacakol valamit, akkor hiába optimalizálod a mysql-t, nem lesz eredménye.

Szerintem leginkább a diskek lettek leterhelve, I/O jelentősen megugrott mióta futnak a játékszerverek.
A prociideje elég nagy magának a szerver-proginak, de ez sztem lehet attól is hogy lassan kap választ a mysql-től.
A táblákat lehetne módosítgatni, de van benne majd' 100, ált 20-40 oszloppal, szal az is egy jó időbe fog telni.

No mindegy, még gúglizok meg belemélyedek ezekbe a táblákba...

Nézd meg a mysql logban (ha nincs akkor log = mysql.log és a datadirbe megy) hogy pontosan mit update-el. Ha megvan akkor egy EXPLAIN $query-vel megtudod hogy mit is csinálna és hogyan. Mivel sok az update, ezért a diszk I/O-t zabálja meg. A memóriánál nézd meg, hogy mennyi a szabad buffer és ha minimális, akkor a memóbővítés és jó. A muninból a cpu usage nevű grafikon is very hasznos. Ha a használt swap 200-250MB főlé megy az is erősen beakasztja a dolgokat, ha a swapben sűrűn használt dolgok vannak.

A szerveremen olyan 50-60 query/sec (10%-a update) van és több GB adatbázis, sok kicsibe elszórva. Így sem meg a cpu használat néhány % fölé, illetve a load 0.2 főle tartósan. Swappelni nem swappel a gép.

Megpróbálkozhatsz a mindenféle bufferek csökkentésével, mert ha update van sok vagy igényes, akkor ne select-re optimalizálj teljes mértékben.

Nézegettem a logot, és nálam kb 99+% az INSERT parancs, van jónéhány DELETE és elszórtan 1-1 SELECT. Indexelgetést elkezdtem, de így is hosszú idő lesz...
Ezt az indexes dolgot nem nagyon vágom, még sosem volt dolgom 5000 sornál többet tartalmazó táblákkal. Ez most segít INSERT, UPDATE, DELETE... stb-nél is, vagy csak a SELECT-nél jó? Neten mindenhol SELECT van a példában.

Asszem neki kéne állni kicsit mélyebben tanulni a DB-ről, tudtok esetleg könyvet ajánlani, amiben ilyesmik le vannak írva? Lekérdezések, stb mennek, csak a szerver karbantartásával nem vagyok eléggé tisztában.

SELECT-nél és UPDATE-nél és DELETE-nél segít, SELECT-nél értelem szerűen gyorsítja a keresést az index, hogy nem kell mindig a táblát nyalnia. UPDATE és DELETE-nél a keresésben segít (pl WHERE feltétel), viszont minden esetben, mikor az adatok módosulnak a táblában (tehát az UPDATE, DELETE és főleg az INSERT-nél) lassít, ugyanis egy-egy módosításnál újra kell gyúrnia az indexet. Szóval ha lényegében csak INSERT van, akkor meg jobb kikapcsolni.

Mondjuk hogy mi a jó ebben a WOW-nak, azt nem tudom, de biztos van valami haszna.

AZ OPTIMIZE TABLE emlékeim szerint arra jó, hogy ha egy nagyobb részt kigyakunk az adattáblából, vagy sokat módosítunk változó hosszúságú mezőket, akkor töredezettségmentesíti a táblát és felszabadítja a helyet. Szóval, ha sokat és sokszor töröl, akkor jól jöhet a hely felszabadításában.

De ha tényleg 99%-ban INSERT van, akkor szerintem még mindig az indexek újragyártása fogja a legtöbb lemezt/cpu-t enni.

Ha meg hülyeségeket magyarázok, majd megmondja valaki.

( cstamas | 2006. 12. 21., cs – 17:27 )

Lehet, hogy érdemes lenne postgresql backend-del is megpróbálni.

( gipszjakab | 2006. 12. 21., cs – 20:21 )

Szerintem is először meg kéne nézned, hogy a táblák rendesen vannak-e felindexelve. A lekérdezést lassítani nagyon nem tudod egy-két plusz index hozzáadásával. Rendes indexeléssel megtáltosodik. Én nekem 1G+ adattábláim vannak és többszörösen join-olt nem egyszerű queryk hegyekben. Egy-egy tábla 20-30 oszloppal és 100000+ sorral. Az update nem szaggatja az istrángot az igaz de azt naponta 4-szer csinálok a táblákon mert az alkalmazás ennyit kíván meg. A query-k pedig tényleg gyorsak. Amúgy érdemes még karbantartási időpontokat definiálni amikor a törölt rekordokat tényleges eltávolítodot egy cron job segítségével ezzel a file méret valóban csökken. Mert a record szintű delete nem csökkenti a file méretet!!! A javasolt explain pedig tényleg hasznos lehet, hogy megnézzed mi tart a legtovább egy lekérdezésben. Az erőforrás igény pedig nem nagy még ilyen esetben sem, nekem egy 4 procis xeon gépen raid-5 tömbbel átlagosan 1-2% a terhelés és naponta 14-15000 tranzakció van. Amíg nem rágtam magamat át az indexelés és optimalizálás rejtelmein addig nekem is sikerült a még teszt alatt levő rendszert timeout-ra tenni 600 másodperces maximális végrehajtási idő mellett is. Miután felindexeltük rendesen és a queryiket is optimalizáltuk a query ideje bőven 1mp alá esett. Szóval megéri vergődni vele.

No.. megnéztem a szripjeimet (hál istennek 2 éve nem néztem feléjük :-)
Szóval rendszerinduláskor ha nem tisztán állt le az adatbázis szerver (meg van a .pid file) akkor első körben egy

myisamchk

fut mielőtt elindulna a mysql szerver. Ha ez rendben lemet akkor indul a mysql ha nem akkor vísít és minden lehetséges módon zakltaja az sysadmin-t, hogy gond van de nagy. Ha lehet akkor megpróbálkozik még a

myisamchk --safe-recover

funkcióval is (erre nálam sosem volt még szükség 6 év alatt). Teszt környezetben próbáltuk pedig a rendszert rendesen (tápot kirángattuk menet közben, hálókábelt ki-be dugdostuk, raid-ben hotswapoltuk a vinyókat) de eddig a pontig nem sikerült eljutnunk.

Normál automatikus maintenance

A "defrag" a

myisamchk -r

paranccsal indul, ezt meg lehet még fűszerezni a -a (analyze) és a -S (sort index) kapcsolókkal.
Az nagyon fontos, hogy a myisamchk alatt ne használja senki az adatbázist. A leállítás előtt érdemes egy FLUSH TABLES parancsot kiadni. Mindezeket meg tudod csinálni egyébként a REAPIR TABLE paranccsal is a myisamchk helyett, de azzal nem vergődtem. Persze csilliárdnyi kapcsoló van amivel testreszabhatod a karbantartást a te igényeidnek megfelelően. Ezért barátod lesz a manual :-D