Sziasztok!
Adott egy adatbazis, amin minden honapban egyszer egy brutal nagy query-t futtatnak. (idonyilvantarto rendszer, egy tobb ezres allomany blokkolasi adatait adja at a berszamfejtesre). A Lekerdezes van hogy egy oran at is tarthat.
Az lenne a kerdesem, hogy egy Memcached beillesztese segithet szerintetek ezen a dolgon? Azt tudom, hogy alapvetoen minden Mysql performance/cache tuning arra van kihegyezve, hogy sok felhasznalot tudjon viszonylag kis lekerdezesekkel kiszolgalni egyszerre gyorsan, de ennel a rendszernel pont forditott a helyzet. Viszonylag keves felhasznalo hasznalja, Viszont nagyon nagy lekerdezesekkel.
Ha a Memcached nem jo erre, akkor esetleg van otletetek, mi az, amivel egy ilyen tipusu adatbazis teljesitenyet lehet novelni? (Most csak uzemeltetesi szempontbol kerdezem, magat a programot nem mi irtuk, tehat a program oldali opimalizalashoz nincs kozunk)
Hozzászólások
Ha _ugyan azt_ sokszor kérdezi le, akkor igen.
De ebben az esetben el kell küldeni a q anyjába a fejlesztőt.
Nem tartom valoszinunek hogy, olyan query-n ami havonta egyszer fut sokat tudna segiteni barmilyen cache-eles.
Nezzetek meg elso korben milyen query-k futnak le (pl slow log bekapcsolas vagy pt-query-digest tcpdump-al) es miert lassu (pl explain a lassu query-kre), utana lehet megnezni azon tudtok-e alaklmazas modositas nelkul is javitani. Lehet session buffer meretekkel elegendo jatszani (ha annyira se lehet alkalmazast modositani es mas nemnagyon van a db-n akkor globalis per session limiteket is lehet novelni csak kalkulalni kell memoriaval), esetleg diszken gyart temp tablakat, netan csak kell par plusz index a tablakra.
Persze szebb ha alkalmazs oldalrol van rendesen megcsinalva es ok is latjak jobban hogy mit meg miert csinal, de par dolgot talan lehet tenni alkalmazas modositas nelkul is.
Ha MySQL akkor InnoDB cache és buffer beállításokkal nagyon sokat lehet rajta gyorsítani de alapvetően memóriával.
Személy szerint én inkább a query próbálnám meg átírni első körben. Hogy néz ki a query? Mekkora adathalmazról van szó pontosan? Mert, több ezer ember egy hónap alatt azért nem tűnik olyan nagy adatmennyiségnek.
Szerk: most látom az utolsó mondatod, akkor passz, üzemeltetési oldalról nem tudom hogy lehetne ez megoldani. Nekem nagyon úgy tűnik, hogy ezt fejlesztői oldalról lehetne megfogni és javítani.
3-4000 ember napi blokkolasa (ki-be). A query vege egy csv fajl, ami megy a berszamfejto proginak, ami ez alapjan szamolja a fizut. Tehat gondolom nem csak a be-ki ido van benne, hanem muszak szerinti adatokat is szamol, meg potlek, stb.... Pontosan nem tudom, mi csak uzemeltetunk.
Nekem ez még mindig nem tűnik nagy adatmennyiségnek? De nem értem, akkor most ti melyiket üzemeltetitek, a blokkoló rendszer részét, vagy a bérszámfejtő programot?
Mert az OP-ból nekem az jön le, hogy a blokkoló (időnyilvántartó rendszer). De itt meg az ellenkezőjét érzem (lehet rosszul).
Vagy az időnyilvántartó rendszer kiszámolja a bérszámfejtési adatokat is kapásból?
- innodb (nincs table lock)
- read-only mysql replika a nagy query-knek
- tmpfs ramdrive-ra
Mennyi adatról van amúgy szó? Nem segít-e egy dump -> ramdisk restore -> batch -> kuka? Mivel a cache felmerült, gondolom a futás alatt az adatok nem változnak.
https://egysoros.com
Meg kellene nézni, nem hiányzik-e pár index...
“May have been the losing side. Still not convinced it was the wrong one.”
Ha van erőforrás, akkor csinálj egy replikát, és a böszme, órákig tartó lekérdezéseket futtassák azon.
miutan az osszes mysql tekero jobbra-balra allitgatasa nem hozta meg a vart eredmenyt. en aggatnek ra egy slaveet, es azon futna ez a csoda query, aztan szamolgasson.
nem is kell folyamatosan szinkronba tenni, eleg csak a csoda elott szinkronba hozni egy reset slave; start slave; pt-sync-table-el.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Ez nem tudom segit-e:
https://i.imgur.com/Nq5DfB8.png
kb 9:40-kor indul a query, akkor dolgozik is szepen, az elso 10 percben. Van CPU terheles, A webserver fele is megy az adat... Aztan kb 9:50 tol leesik minden, a CPU marad olyan 15-20 kozott es erre a szintre beall az IO-wait is. Ez aztan megy tobb mint fel orat...
most lehet furat fogok allitani, majd a mysql nagy tudorai megcafolnak ha.
szoval hasonlon nekem az segitett sokat, hogy miutan mar megemeltem az osszes *_buffer_size ( pl: join_buffer_size , sort_buffer_size ) es a cachekhoz kapcsolodo mindenfele parametereket, ( pl : thread_cache_size, query_cache_limit ) vegso probakent a tmp_table_size -t allitottam nagyobbra.
HUP te Zsiga !
Miután majdnem stabilan 1/8 az iowait max-ja, ezért feltételezem hogy 8 magos gépről van szó, ahol az egyik cpu csak a lemezre vár.
Ha valóban ez az eset áll fent, akkor meg kellene nézni a query-t (explain) hogy mi az ami ennyire retek lassú.
A query elnagyolt leírásából egyébként úgy vélem hogy nincs indexálva a dátummező. ( az alkalmazottak tábla meg gondolom elég pici ahhoz, hogy folyamatosan memóriában legyen tartva)
Ideális esetben a munkaidő visszamenőleg nem változik ezért akár hetente / naponta is le lehetne futtatni a queryt kisebb időtartományra. Hetente csak egyszer kellene egy select a brutál queryre, az lefut amennyi idő alatt letud. Az eredményét el lehetne tárolni ideiglenesen más táblában. Havi zárás alkalmával már csak az előre kiszámolt adatokat kellene átadni a bérszámfejtőknek.
View-k segítségével transzparensé tudod tenni ezt a bérszámfejtők felé, de mivel csak üzemelteted a db-t, így ez az opció erősen korlátozott.
Az, hogy mi segit azt nem tudom megmondani, en egy hasonlo esetet ugy oldottam meg, ahogy fentebb is irtak.
Ha adott naptol napig kell, akkor egy akarmilyen kontener, vagy vm, egy tmpfs amirol dolgozik a mysql, majd beletolom a mentest, vagy barmifele dumpot.
Nagyon haxor, de ha egyszer kell egy honapban, akkor ennek kar tul nagy feneket keriteni.
http://karikasostor.hu - Az autentikus zajforrás.
Próbáld meg SSD(k)-re költöztetni az adatbázist.
Mar azokon van.
Sajnos valószínűleg teljesen ökör módon van megírva a lekérdezés és a legtöbb javulást a program átírásával lehetne elérni.
Üzemeltetésileg table és query statisztikákat nézegetnék, abból rá lehet jönni hogy érdemes-e memcached-et elétenni illetve hogy miről hiányzik index esetleg.
Vannak toolok arra is hogy query logok alapján adnak javaslatokat tuningra, egy ilyet is ki lehet próbálni.
Gábriel Ákos