Mi olvas sok adatot a fájlrendszerről?

Linux-haladó

Üdv mindenkinek,

Egy kis segítséget szeretnék kérni mysql ügyben.

Adott egy szerver ahol mysql szolgál ki jelenleg 875 darab adatbázist.
Gyakran előfordul, hogy percekig elég masszív (80-90MByte/s) adatmennyiséget olvas valami a fájlrendszerről miközben
a fájlrendszerre írás és a hálózati forgalom elhanyagolható. Tehát valami sok adatot olvas de nem ír vissza a fájlrendszerre és a beolvasott adatot nem szologálja
ki kliensnek a hálózaton keresztül.

Sajnos iotop nem megy az adott szerveren mert elég régi a kernel. (jelenleg sajnos nem megoldható a kernel frissítés)
Ezért az iodump segítségével próbáltam megtalálni a processzt. 


TASK                   PID      TOTAL       READ      WRITE      DIRTY DEVICES
mysqld               13938       2409       2409          0          0 sda2
mysqld                3094       1892       1892          0          0 sda2
mysqld                3089       1523       1523          0          0 sda2
kjournald              698        971          1        970          0 sda2
kjournald             2322        804          1        803          0 sdb1

A listában az látszik hogy a mysql processzek végeznek intenzív olvasást a fájlrendszerről.

A mytop-ot nézve nem látszik olyan tranzakció ami egy-két másodpercnél tovább futna, miközben folyamatos a nagy mennyiségű olvasás a fájlrendszerről.
Továbbá nincsenek folyamatosan ismétlődő tranzakciók amik bár egyszere kis mennyiségű adatot olvasnak összességében indokolnák a percekig tartó magas fájlrendszer olvasást.

Az inotifywach segítségével talán meg lehetne találni, hogy konkrétan melyik adatbázis melyik táblájából olvas a mysql. Úgy gondolom, hogy a nagy mennyiségű adatbázis miatt
sok fájlt kellene monitorozni ami nem biztos, hogy szerencsés.

Tehát a kérdésem az lenne, hogy miként lehetne kideríteni, hogy melyik adatbázisból (esetleg milyen művelet miatt) olvas sok adatot a mysql?

A válaszokat előre is köszönöm.

  • 7083 megtekintés

( hrgy84 | 2012. 03. 30., p – 17:17 )

Azt kell megnezni, hogy parhuzamosan milyen alkalmazasok aktivak akkor, amikor sok olvasas tortenik. Ha pl. az apache is nagyon aktiv, akkor lehet sejteni, hogy valamelyik weboldal a ludas, ilyenkor kell nezni egy server-status -t, ami kiirja, hogy melyek az aktiv szalak (ExtendedStatus On).

Mivel nem irtal bovebb kornyezetet, igy csak ennyi tippet tudok adni, probald meg a problemat rendszerszinten atgondolni, mik futnak, mi hasznal mysql-t, mi az, aminek van egyaltalan annyi adata, amennyit olvasol, adatbazismeretek sokat tudnak segiteni.

Illetve erdemes lehet a mysql binlogot is neha uriteni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Mit értesz a párhuzamosan futó alkalmazások aktívságán?
Az iotop szerint a nagy mennyiségű olvasás a mysql műve. Közben a cpu és memória nem fogy, hálózati forgalom nem jelentős. Tehát más alkalmazások működése nem mutat összefüggést a jelenséggel.

Binlog nincs engedélyezve.

--
maszili

Hat a praxisomban a mysql szerverek, amennyiben a vilagon senki nem hasznalja oket, nem szoktak olvasasi muveletekbe kezdeni, ennyire nem kimuvelt egyenisegek. Sot, ha csak ugy elinditok egy MySQL-t es utana semmit nem csinalok, akkor a MySQL szerver se szokott semmit csinalni, nagyon lusta egy dog, tudod...? :-)

Szoval, arra akartam kihegyezni a dolgot, hogy ha a MySQL ilyen sokat olvas, azt nem magatol teszi, valamilyen alkalmazas azt keri tole, hogy az egyik adatbazisbol legyen kedves, es muvelje ki magat, majd adjon valami izgalmas kerdesre valaszt. En azt gondolom, hogy erdemes lenne megkeresni azt az illetot (alkalmazast), aki ilyen felettebb bonyolult kerdeseket tesz fel a MySQL szervernek, hogy annak a teljes adatbazisbol kell muvelodnie, semmint a MySQL-t kerdezgetni folyamatosan, hogy melyik konyv (db) hanyadik oldalan (melyik tablajanal) tart. Olvasas kozben en utalom az ilyen kerdesket :-).

A slowlog bekapcsolasa esetleg segithet..

Ezt ugy lehet kinyomozni, hogy a futo alkalmazasok logjat elkezdi az ember nezegetni, hogy ugyan melyiknek van hirtelen nagyobb forgalma, vagy hol var nagyobb mennyisegu szal kiszolgalasra. De mivel nem tudom, milyen appok vannak a kornyezetben, ebben nem tudok segiteni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( dap | 2012. 03. 30., p – 17:53 )

Az inotify nem mutatja az olvasást. Egy jó systemtap script segíthetne mai kernellel, bár ha mmap, akkor további fejtörést okoz.

Mysql 5.5 esetén a file_summary_by_instance kihúzna a csávából, bár a régi kernel mellé gondolom kőkori Mysql dukál és/vagy nincsenek lebontva az InnoDB adatok fájlokra.

Szerintem első körben a slow.log -ot érdemes elemezned mysqlsla-val és összevetni a jó és a rossz időszakokat.

Hát más nem nagyon okozhatja, csak valamiféle művelet.

Mondjuk alapvetően érdekes, hogy nem kapcsolható hosszan futó művelethez (a legesleg elején sem?), talán valami cache thrashing lesz: egy művelet agyonb'ssza a query/page cache-t és a talpraállás, a cache-ek újbóli feltöltése amit látsz. Azt már a "normális" műveletek végzik, amik egyesével viszonylag gyorsan lefutnak, de összességében mégis rengeteg kiesett adatot kell újra betölteniük.

Ha ez a gond, akkor is kell lennie valaminek ami besszennyezi/invalidálja a cache-t és ez a művelet akkor fut le, amikor elindul az egész folyamat.

Rosszabb esetben egy egyszerű, egy pillanat alatt lefutó írás lesz, ami a query cache egy olyan részét invalidálja, amit csak drága IO műveletekkel lehet újra feltölteni.

Az is lehet, hogy egyszerűen két óriási adatbázissal kezdenek dolgozni egyszerre, amik már együtt nem férnek be a cache-be és sima page cache thrashing amit látsz. Külön-külön jól működnek, együtt már nem.

Szóval nagyon fel kell kötni a gyatyát, adott esetben jobban megéri memóriába/ssd -be befektetni, mint felderíteni a pontos okot..

Én is úgy gondolom, hogy valami kretén lekérdezés okozhatja csak jó volna tudni, hogy melyik az.
A cache töltése jó ötlet, megpróbálom valahogyan azt monitorozni.

Szerencsére még nem okoz nagy traumát a jelenség de szeretném kideríteni, hogy mi pazarolja így az erőforrásokat amíg még nem fogynak el.

--
maszili

( szniki | 2012. 03. 31., szo – 11:09 )

Komolyan semmilyen eszkoz nincs linuxban i/o monitorozasra? oO

( zamboriz v | 2012. 03. 31., szo – 12:29 )

> Tehát valami sok adatot olvas de nem ír vissza a fájlrendszerre és a beolvasott adatot nem szologálja ki kliensnek a hálózaton keresztül.

mysqldump lementi a bájtokat a /dev/null -ba ... :-)

( hrgy84 | 2012. 03. 31., szo – 13:21 )

A HWSW forumarol kaptal egy tippet, amelyet szeretnek megosztani veled:

... esetleg érdemes lenne megnézetni vele, hogy cron-ból vagy a mysql event schedulerből nincs-e valami elindítva (nem tudom, az 5.0-ban van-e ilyen, 5.1-ben már van)

Egyetertek, ezt is erdemes megnezni.

-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( Fisher v | 2012. 04. 01., v – 10:01 )

Gondolom a mysqltuner meg tuning-primer már megvolt.

( tovis v | 2012. 04. 01., v – 09:55 )

Nem vagyok MySQL guru. Viszont mindenki aki érteni vél hozzá, állítja, hogy magától, szorgalmi feladatokat nem végez. Akkor ezt valaki/valami kiváltja. A MySQL mint minden böcsületes *nix program, elérhető UNIX és hálózati socketeken keresztül. Így a megnövekedett IO aktivitást kell összevetni a szerver kapcsolataival, nem csak közben, de már előtte. Mindenféle, aktivitást tartalmazó logot mellé kell tenni, és így vizsgálódni - a problémát a reakció idő jelentheti, azaz az indokolatlannak tűnő aktivitást kiváltó külső esemény mennyivel előtte szólt bele - kutass jobban a naplókban, nézd meg az esemény előtti utolsó tranzakciót!
Sajnos nem tudom hogy lehet a MySQL -en kívül, belekukkolni a UNIX socketon zajló kommunikációba, vagy a normál socketon zajló, belső kommunikációba - elvileg erről a MySQL -nek magának kellene gondoskodnia, nincs valami beállítás amivel intenzívebb naplózásra lehet bírni?

* Én egy indián vagyok. Minden indián hazudik.

( maszili | 2012. 04. 01., v – 18:38 )

Úgy látom sokan nem értették meg amit a post-ban írtam. Megpróbálok akkor itt egyben válaszolni pár dologra és megmagyarázni pár dolgot.

- A rendszer egy CentOS release 5.8 (Final), Kernel 2.6.18-194.11.3.el5, MySQL 5.0.95
Ezen sajnos most nem tudok változtatni, ezzel kell főzni ami van.

- iotop ugyan nincs a rendszeren mert a kernel régi de van iodump ami nagyjából ugyanazt tudja. Az iodump segítségével behatárolható, hogy a mysql processzek csinálnak nagy IO olvasási műveletet a fájlrendszeren.

- Igen tudom, hogy a mysql nem fog magától vaktában IO műveleteket végezni, nyílván oka van a nagy mennyiségű olvasásnak. Ezért szeretném valahogy közvetlenül a mysql felől megközelítve megtalálni az okot és nem közvetett módon millió egyéb processzen keresztül.

- A post-ban írtam, hogy a mytop szerint nincsenek egy-két másodpercnél tovább tartó sql tranzakciók. Ezért szerintem a slow-log nézegetése értelmetlen, hacsak nem állítom be a limitet 1 másodpercre mert akkor lesz sok bejegyzés a slowlog-ban.

- A post-ban írtam azt is, hogy miközben egy-két másodperces tranzakciók vannak az olvasás folyamatos akár egy percen keresztül is. Tehát feltehetőleg nem közvetlenül egy darab "select * from" miatt történik a dolog mert akkor az a hosszú futási időtartam miatt látszana a mytop-ban is.

- A post-ban írtam azt is, hogy a nagy olvasások alatt nem látszanak nagy_mennyiségű_hasonló_tranzakciók_ amelyek olvasási igénye összeadódva indokolnák a nagy mennyiségű olvasást.

- Nem látom értelmét logolni az összes tranzakciót még rövid időre sem, mert átlagos 700-800 query/s esetén a felgyülemlett log mennyiséget nem fogom tudni érdemben átnézni annak reményében, hogy melyiknek lehet köze a nagy olvasásokhoz.

- A nagy olvasások kezdetének időpontja véletlenszerű. Nem tudom határozott időponthoz kötni ezért arra gondolok, hogy nem köthető valamilyen ütemezett feladathoz.

--
maszili

"nem látszanak nagy_mennyiségű_hasonló_tranzakciók_"

"Nem látom értelmét logolni az összes tranzakciót még rövid időre sem, mert átlagos 700-800 query/s "

700-800 q/s esetén halvány lila gőzöd sincs, hogy milyen tranzakciók futnak.A nagy mennyiségű olvasást pár tucat tranzakció is összehozhatja, amik darabja 1 másodpercen belül lefut.
A mytop kutyagumit nem ér ebben az esetben.
Eszközök híjján nincs túl sok esélyed kideríteni mi okozza, ha problémát jelent, akkor próbáld meg a mysql-t hangolni, mert lehet, hogy a megfelelő cache és egyéb beállításokkal elmúlik.

Nem feltetlen tranzakciokrol van szo, lehet hogy van egy hirtelen nepszeruve valo oldalatok.

Egyekbent a kiindulasi pont rossz. Altalaban - foleg ha ennyire bekorlatoltak az ember lehetosegei - nem erdems a mysql iranyabol keresni a nagy terhelot. Es altalaban ha az ember nem panikol, hanem leul es gondolkodik, akkor a millio processz 90%-at ki tudja dobni egy szalma keresztbetetele nelkul.

Altalanos tapasztalatom, hogy a debuggolast mindig felulrol lefele hajtjuk vegre. Vagyis megkeresem a topmost problemas appot, es utana kezdek el leasni. Alulrol lefele nem mindig lehet megmondani, hogy mi okoz problemat.

Egyebkent pedig a legtobben megertettuk, amit irtal. Viszont te meg azt probald meg megerteni, amit mi irunk. Ennyi erovel a fajlrendszer felol is megprobalhatnad kitalalni, hogy ugyan mi eszi a gepet, pont ugyanannyira lennel kozel a megoldashoz. Tul melyen van ez a MySQL ahhoz, hogy barmi ertelmeset tudjunk mondani. Ertem, hogy egy tobbnapos lognezegetest akarsz elkerulni, de ez igy sajnos nem fog menni.

-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Már többen írták: kapcsold be a slow query log-ot, vedd mondjuk 2 sec-re, vagy akár 1-re. Az ki fogja írni a lassú query-ket, és ezen kívül azokat is, amik nem használnak indexet. Na ezeket kell explain-nel kielemezni, és adott esetben indexelni vagy átírni a query-t. Ahol full table scan-t látsz nagyobb táblákon, ott gond van. Aztán ha van slow query-log-od, akkor tudsz adatbázisra is statisztikázni...

A másik, amit már sokan írtak: tuningolni a mysql paramétereket. Ha nagyon sok az ismétlődő olvasás, akkor a query cache megemelése (és ha nincs még bekapcsolva, akkor természetesen a bekapcsolása) nagyon sokat tud dobni a rendszeren. Pl. ha 20 megára van állítva, te pedig rendszeresen olvasgatod ugyanazt a 200 megát, akkor kb. semmit se ér. Persze az optimális értékeket a szerver fizikai paramétereitől, terhelésétől, esetleges más szolgáltatásoktól (pl. apache) függően lehet kimatekolni, és főleg mérni.