MySQL optimalizálási probléma
|
View:
New views
11 Messages
—
Rating Filter:
Alert me
|
 |
MySQL optimalizálási probléma
by Fenyvesi Márton
::
Rate this Message:
Sziasztok!
Az általános listára már tegnap írtam, de sajnos nem kaptam választ. Azóta sikerült jobban meghatároznom a problémát, de sajnos a hiba fent áll továbbra is. Van egy relatív nagy adatbázisom, a két leggyakrabban használt tábla mérete 32e rekord (18 MB) és 106e rekord (660 MB). Az adatbázis és a látogatószám növekedésével jelent meg az a probléma, hogy egyre gyakrabban hal le az oldal. (Most átlagosan 80 lekérdezés történik másodpercenként.) Logikusan arra gondoltam, hogy valami nincs megfelelően optimalizálva. Újra átnéztem, leteszteltem a kritikusabb lekérdezéseket, nem találtam olyat, ami néhány ezredmásodperc alatt ne futott volna végig. Majd elkezdtem figyelni a phpmyadminon belül a processlist-et. Azokban az időpontokban, amikor belassult az oldal volt egy csomó "sleep" és "locked" állapotú sor. Ezt nem nagyon tudom mire vélni. A kérdésem az vola, hogy az ilyen teljesítményingadozásoknak általában mik az okai? Illetve mi lehet a megoldás? Előre is köszönöm a segítséget! Üdv: Fenyvesi Márton -- Weblabor hírlevél: http://weblabor.hu/hirlevel -- wl-phplista (wl-phplista@...) levelezőlista https://bors.hoszting.com/mailman/listinfo/wl-phplista Keresheto archivum: http://weblabor.hu/kereses -- etikett: http://weblabor.hu/levlistak/illemszabaly offlista: https://weblabor.hu/levlistak |
|
|
Re: MySQL optimalizálási probléma
by aramisz
::
Rate this Message:
Hello,
Több féle megoldás létezik, de jobb mindet vagy a legtöbbet bevetni egyszerre. Elsőre én a query_cache-t kapcsolnám be a szerveren a my.cnf filében. Ezt checkolhatod a következő paranccsal illetve adhatsz még méretet és egyéb paramétereket hozzá egyértelműen. SHOW VARIABLES; Variable_name Value query_cache_limit 1048576 query_cache_min_res_unit 4096 query_cache_size 67108864 query_cache_type ON query_cache_wlock_invalidate OFF query_prealloc_size 8192 MySQL lekérdezés, update, insert szervezési probléma is lehetséges. Használj minél kevesebb JOIN-t, illetve használj indexeket, legalább azokra amelyek a WHERE feltételeidben szerepelnek. Ezekre vannak trükkök illetve ajánlások, de gondolom, a kódba már nem nagyon szeretnél belenyulni, akkor marad a config tuning. PERSISTANT adatbázis kapcsolatot használnék, hogy ne maradjon nyitott kapcsolat véletlenül sem, egy-egy oldal letöltése után (Ezt ha valaki meg tudja vitatni hogy melyik jobb, erre én is kiváncsi lennék.) Mind ezek mellett debugként érdemes bekapcsolni a log-slow-queries[=file_name] hogy lásd, melyek azok a lekérdezések, amelyekkel küzd a szerver. Röviden ennyi, lenne még biztosan, csak nem tudom milyen lehetőségeid vannak a szervert illetően. Üdv aramisz -----Original Message----- From: wl-phplista-bounces@... [mailto:wl-phplista-bounces@...] On Behalf Of Fenyvesi Márton Sent: Thursday, September 10, 2009 6:20 PM To: wl-phplista@... Subject: [wl-phplista] MySQL optimalizálási probléma Sziasztok! Az általános listára már tegnap írtam, de sajnos nem kaptam választ. Azóta sikerült jobban meghatároznom a problémát, de sajnos a hiba fent áll továbbra is. Van egy relatív nagy adatbázisom, a két leggyakrabban használt tábla mérete 32e rekord (18 MB) és 106e rekord (660 MB). Az adatbázis és a látogatószám növekedésével jelent meg az a probléma, hogy egyre gyakrabban hal le az oldal. (Most átlagosan 80 lekérdezés történik másodpercenként.) Logikusan arra gondoltam, hogy valami nincs megfelelően optimalizálva. Újra átnéztem, leteszteltem a kritikusabb lekérdezéseket, nem találtam olyat, ami néhány ezredmásodperc alatt ne futott volna végig. Majd elkezdtem figyelni a phpmyadminon belül a processlist-et. Azokban az időpontokban, amikor belassult az oldal volt egy csomó "sleep" és "locked" állapotú sor. Ezt nem nagyon tudom mire vélni. A kérdésem az vola, hogy az ilyen teljesítményingadozásoknak általában mik az okai? Illetve mi lehet a megoldás? Előre is köszönöm a segítséget! Üdv: Fenyvesi Márton -- Weblabor hírlevél: http://weblabor.hu/hirlevel -- wl-phplista (wl-phplista@...) levelezőlista https://bors.hoszting.com/mailman/listinfo/wl-phplista Keresheto archivum: http://weblabor.hu/kereses -- etikett: http://weblabor.hu/levlistak/illemszabaly offlista: https://weblabor.hu/levlistak -- Weblabor hírlevél: http://weblabor.hu/hirlevel -- wl-phplista (wl-phplista@...) levelezőlista https://bors.hoszting.com/mailman/listinfo/wl-phplista Keresheto archivum: http://weblabor.hu/kereses -- etikett: http://weblabor.hu/levlistak/illemszabaly offlista: https://weblabor.hu/levlistak |
|
|
Re: MySQL optimalizálási probléma
by emul
::
Rate this Message:
Csak erdeklodom. A 80 query/sec milyen latogatottsaggal parosul?
Egyebkent az hogy teszteleskor mennyi ido alatt fut le a query nem feltetlen szamit. Lehet hogy csak sok query egyideju futasakor jon elo problema. Pl temp tablakat general. Szoval a helyedben megneznem eloszor is hogy milyen query futnak: EXPLAIN. A mysql-en is sokat lehet hangolni, de kukkants ra egy memCache megoldasra is( http://hu2.php.net/memcache ), azzal rengeteget lehet gyorsitani a dolgokon. Ha nagy tablabol kerdezel re rendezve joinolva es szurve akkor neha celszeru csak az azonositokat lekerni eloszor, majd egy masodik queryben leszelektalni az IDkhoz tartozo szukseges adatokat. Igy latatlanban kb ennyit tudok mondani. 2009/9/10 Fenyvesi Márton <fenyvesi@...> Sziasztok! -- Weblabor hírlevél: http://weblabor.hu/hirlevel -- wl-phplista (wl-phplista@...) levelezőlista https://bors.hoszting.com/mailman/listinfo/wl-phplista Keresheto archivum: http://weblabor.hu/kereses -- etikett: http://weblabor.hu/levlistak/illemszabaly offlista: https://weblabor.hu/levlistak |
|
|
Re: MySQL optimalizálási probléma
by Csonka Gergely
::
Rate this Message:
Heló.
2009/9/10 Fenyvesi Márton <fenyvesi@...>: > időpontokban, amikor belassult az oldal volt egy csomó "sleep" és "locked" > állapotú sor. Ezt nem nagyon tudom mire vélni. Feltételezem, hogy MyISAM a tábláid motorja. A MyISAM-ról azt kell tudni, hogy táblaszinten lockol, mikor ír, tehát addig minden más lekérdezésnek várnia kell, és ez meg is magyarázza a "sleep" és "locked" állapotokat. Az InnoDB motor rekord szintű lockolást használ, úgyhogy lehet, hogy megoldódna a gondod, ha átkonvertálnád a sűrűn írt tábláidat. Ennyi az egész: ALTER TABLE [táblanév] ENGINE = InnoDB; Üdv, -- Csonka Gergely http://bekex.hu -- Weblabor hírlevél: http://weblabor.hu/hirlevel -- wl-phplista (wl-phplista@...) levelezőlista https://bors.hoszting.com/mailman/listinfo/wl-phplista Keresheto archivum: http://weblabor.hu/kereses -- etikett: http://weblabor.hu/levlistak/illemszabaly offlista: https://weblabor.hu/levlistak |
|
|
|
|
|
Re: MySQL optimalizálási probléma
by Csonka Gergely
::
Rate this Message:
Heló
2009/9/11 Fenyvesi Márton <fenyvesi@...>: > Rájöttem még egy dologra, ami a valódibb problémát okozza. Alapvetően ez a > MySQL mizéria "csak" lassulást okoz, de több helyen találtam olyan részeket, > amik hibás futnak le az ilyen "belassulások" alatt. Mint kiderítettem, > ezeknek a hibás működéseknek az az oka, hogy két oldalbetöltődés között > elveszik a session. Tehát például bejelentkezés után kidob, mert a következő > oldal betöltésekor már nem elérhető az adott session változó. A > legidegesítőbb az egészben, hogy 95%-ban jól működik ugyanaz a rész. Minden > kimenet eltőtt megy a session_start(); és a $_SESSION -ben meg figyelnek az > adatok. Idáig frankón működött. Írtad, hogy egyelőre nincs lehetőség a konvertálásra, úgyhogy lehet, hogy neked nem hasznos, de megint egy motort említenék, ami pont az ilyen helyzetekben tud igazán hasznos lenni: http://dev.mysql.com/doc/refman/5.0/en/memory-storage-engine.html A lényege, hogy az egész táblát a memóriában tárolja, így nagyon gyors, és nagyon alacsony az erőforrás igénye. Persze vannak korlátai, a legnagyobb az, hogy a szerver újraindításakor a tábla tartalma elveszik, de a session-ökhöz tökéletes. Olvastam egy esettanulmányt, ahol egy 100% körüli terhelést 5% körülire vittek le csak azzal, hogy a session táblát memory motorra konvertálták (persze ez sok mindentől függ, egyáltalán nem biztos, hogy nálad is ennyi lenne). Üdv, -- Csonka Gergely http://bekex.hu -- Weblabor hírlevél: http://weblabor.hu/hirlevel -- wl-phplista (wl-phplista@...) levelezőlista https://bors.hoszting.com/mailman/listinfo/wl-phplista Keresheto archivum: http://weblabor.hu/kereses -- etikett: http://weblabor.hu/levlistak/illemszabaly offlista: https://weblabor.hu/levlistak |
|
|
Re: MySQL optimalizálási probléma
by felho
::
Rate this Message:
> Használj minél kevesebb JOIN-t,
Ezt így általános tanácsként nem mondanám, gyakran rosszabb eredeményt fogsz elérni két vagy több külön queryvel. > amelyek a WHERE feltételeidben szerepelnek. Ezekre vannak trükkök illetve > ajánlások, de gondolom, a kódba már nem nagyon szeretnél belenyulni, akkor > marad a config tuning. Ha van egy rossz query index nélkül, akkor azt configgal nehéz lesz orvosolni. Van amikor egy jó index hozzáadása drasztikusan csökkenti a terhelést (pl. volt amikor 20 fölött loadról lett 1 alatti). > PERSISTANT adatbázis kapcsolatot használnék, hogy ne maradjon nyitott > kapcsolat véletlenül sem, egy-egy oldal letöltése után (Ezt ha valaki meg > tudja vitatni hogy melyik jobb, erre én is kiváncsi lennék.) A perzisztens kapcsolat mysqlnél nem ajánlott, nagyon olcsó a kapcsolódás, ezért teljesítményben nem túl érezhető a nyeremény, viszont nagyon sokat lehet szívni, mert a mysql szarul kezeli, és pl. nem zárja le automatikusan a tranzakciót, változók maradhatnak más állapotban, és replikáció esetné is lehet szopni. > Mind ezek mellett debugként érdemes bekapcsolni a > log-slow-queries[=file_name] Itt érdemes azzal játszani, hogy először beállítod mondjuk 5 sec-re, nézed, hogy van-e, ha igen, akkor ptimalizálod, utána lejebb veszed, és így tovább. Üdv, Felhő -- Weblabor hírlevél: http://weblabor.hu/hirlevel -- wl-phplista (wl-phplista@...) levelezőlista https://bors.hoszting.com/mailman/listinfo/wl-phplista Keresheto archivum: http://weblabor.hu/kereses -- etikett: http://weblabor.hu/levlistak/illemszabaly offlista: https://weblabor.hu/levlistak |
|
|
Re: MySQL optimalizálási probléma
by Fenyvesi Márton
::
Rate this Message:
Nem egyénileg történik a munkamenetek kezelése. Tehát nem mentem
adatbázisba. Minden alapértelmezés szerint történik. Én csak a session_start() függvényt és $_SESSION tömböt használom hozzá. Mivel jól működött nem is ástem bele magamat jobban. Akkor még örültem neki. :-) A tippet köszönöm, ezt is megjegyzem magamnak. Marci ----- Original Message ----- From: "Csonka Gergely" <gergely.csonka@...> To: "weblabor PHP levlista" <wl-phplista@...> Sent: Friday, September 11, 2009 12:54 PM Subject: Re: [wl-phplista]MySQL optimalizálási probléma Heló 2009/9/11 Fenyvesi Márton <fenyvesi@...>: > Rájöttem még egy dologra, ami a valódibb problémát okozza. Alapvetően ez a > MySQL mizéria "csak" lassulást okoz, de több helyen találtam olyan > részeket, > amik hibás futnak le az ilyen "belassulások" alatt. Mint kiderítettem, > ezeknek a hibás működéseknek az az oka, hogy két oldalbetöltődés között > elveszik a session. Tehát például bejelentkezés után kidob, mert a > következő > oldal betöltésekor már nem elérhető az adott session változó. A > legidegesítőbb az egészben, hogy 95%-ban jól működik ugyanaz a rész. > Minden > kimenet eltőtt megy a session_start(); és a $_SESSION -ben meg figyelnek > az > adatok. Idáig frankón működött. Írtad, hogy egyelőre nincs lehetőség a konvertálásra, úgyhogy lehet, hogy neked nem hasznos, de megint egy motort említenék, ami pont az ilyen helyzetekben tud igazán hasznos lenni: http://dev.mysql.com/doc/refman/5.0/en/memory-storage-engine.html A lényege, hogy az egész táblát a memóriában tárolja, így nagyon gyors, és nagyon alacsony az erőforrás igénye. Persze vannak korlátai, a legnagyobb az, hogy a szerver újraindításakor a tábla tartalma elveszik, de a session-ökhöz tökéletes. Olvastam egy esettanulmányt, ahol egy 100% körüli terhelést 5% körülire vittek le csak azzal, hogy a session táblát memory motorra konvertálták (persze ez sok mindentől függ, egyáltalán nem biztos, hogy nálad is ennyi lenne). Üdv, -- Csonka Gergely http://bekex.hu -- Weblabor hírlevél: http://weblabor.hu/hirlevel -- wl-phplista (wl-phplista@...) levelezőlista https://bors.hoszting.com/mailman/listinfo/wl-phplista Keresheto archivum: http://weblabor.hu/kereses -- etikett: http://weblabor.hu/levlistak/illemszabaly offlista: https://weblabor.hu/levlistak |
|
|
Re: MySQL optimalizálási probléma
by felho
::
Rate this Message:
> Feltételezem, hogy MyISAM a tábláid motorja. A MyISAM-ról azt kell
> tudni, hogy táblaszinten lockol, mikor ír, Nem minden esetben, a tábla végére történő insert az külön ágon működik, ilyenkor nincs lock. Ezért pl. akkor is nyerő lehet egy MyISAM, ha kifejezetten többségében vannak egy táblán az insertek. Üdv, Felhő -- Weblabor hírlevél: http://weblabor.hu/hirlevel -- wl-phplista (wl-phplista@...) levelezőlista https://bors.hoszting.com/mailman/listinfo/wl-phplista Keresheto archivum: http://weblabor.hu/kereses -- etikett: http://weblabor.hu/levlistak/illemszabaly offlista: https://weblabor.hu/levlistak |
|
|
Re: MySQL optimalizálási probléma
by felho
::
Rate this Message:
> A lényege, hogy az egész táblát a memóriában tárolja, így nagyon
> gyors, és nagyon alacsony az erőforrás igénye. Persze vannak korlátai, > a legnagyobb az, hogy a szerver újraindításakor a tábla tartalma > elveszik, de a session-ökhöz tökéletes. Azért ez erős orosz rulette, bármikor előfordulhat, hogy egy szervert újra kell indítani (pl. 5.1 előtt egy csomó beállítást nem lehetett futás közben állítani, de gondolom még most is van ilyen), az elég gáz, ha user sessionök elvesznek. Ha pl. nem nagyon van komoly adat a sessionben, akkor lehet pl. cookie alapú, vagy pl. nálunk jelenleg memcacheben van (gyorsabb is mint a DB), kód szinten replikálva. De vannak key-value database-ek (pl. Tokyo Tyrant), erre a célra valszeg az a legtutibb, mert ezek nagyon gyorsak tudnak lenni, viszont perzisztens, így nincs gond a restarttal. Üdv, Felhő -- Weblabor hírlevél: http://weblabor.hu/hirlevel -- wl-phplista (wl-phplista@...) levelezőlista https://bors.hoszting.com/mailman/listinfo/wl-phplista Keresheto archivum: http://weblabor.hu/kereses -- etikett: http://weblabor.hu/levlistak/illemszabaly offlista: https://weblabor.hu/levlistak |
|
|
Re: MySQL optimalizálási probléma
by Hotz Norbert
::
Rate this Message:
A memory storage engine-nel csináltam session kezelést, és működik is a
dolog. A session-ök pont olyan adatok, amiket nyugodtan lehet tárolni a memóriában. Veszhetnek, ha újraindul a szerver. Csak az itthoni kis Linux masinámon próbáltam ki, de egyébként az az 5% reális lehet. Mondjuk nem mindegy, hogy a vinyóról kell felnyalni az adott sessiont gigányi fájlokból, vagy pikk-pakk kiszedjük a memóriából. Márton, ha pedig két select van a kódodban, mondjuk valami ilyesmi: $id = "SELECT id FROM auth WHERE email=' ".$email." ' "; $address = "SELECT address FROM users WHERE id=' ".$id." '"; Ezt mindenképp írd át egy JOIN-ra, és máris töredékére csökkentetted a lekérdezésre fordított időt. $address = "SELECT address FROM auth (INNER) JOIN users on (auth.id=users.id) WHERE email=' ".$email." '"; Így elég egyszer az adatbázisszerverhez fordulni. Szintaktikailag lehet, hogy hibásan írtam, de a lényeg a JOIN. Üdv N. Csonka Gergely wrote: > Heló > > 2009/9/11 Fenyvesi Márton <fenyvesi@...>: > >> Rájöttem még egy dologra, ami a valódibb problémát okozza. Alapvetően ez a >> MySQL mizéria "csak" lassulást okoz, de több helyen találtam olyan részeket, >> amik hibás futnak le az ilyen "belassulások" alatt. Mint kiderítettem, >> ezeknek a hibás működéseknek az az oka, hogy két oldalbetöltődés között >> elveszik a session. Tehát például bejelentkezés után kidob, mert a következő >> oldal betöltésekor már nem elérhető az adott session változó. A >> legidegesítőbb az egészben, hogy 95%-ban jól működik ugyanaz a rész. Minden >> kimenet eltőtt megy a session_start(); és a $_SESSION -ben meg figyelnek az >> adatok. Idáig frankón működött. >> > > Írtad, hogy egyelőre nincs lehetőség a konvertálásra, úgyhogy lehet, > hogy neked nem hasznos, de megint egy motort említenék, ami pont az > ilyen helyzetekben tud igazán hasznos lenni: > http://dev.mysql.com/doc/refman/5.0/en/memory-storage-engine.html > > A lényege, hogy az egész táblát a memóriában tárolja, így nagyon > gyors, és nagyon alacsony az erőforrás igénye. Persze vannak korlátai, > a legnagyobb az, hogy a szerver újraindításakor a tábla tartalma > elveszik, de a session-ökhöz tökéletes. > > Olvastam egy esettanulmányt, ahol egy 100% körüli terhelést 5% > körülire vittek le csak azzal, hogy a session táblát memory motorra > konvertálták (persze ez sok mindentől függ, egyáltalán nem biztos, > hogy nálad is ennyi lenne). > > Üdv, > -- > Csonka Gergely > http://bekex.hu > -- Weblabor hírlevél: http://weblabor.hu/hirlevel -- wl-phplista (wl-phplista@...) levelezőlista https://bors.hoszting.com/mailman/listinfo/wl-phplista Keresheto archivum: http://weblabor.hu/kereses -- etikett: http://weblabor.hu/levlistak/illemszabaly offlista: https://weblabor.hu/levlistak |
| Free embeddable forum powered by Nabble | Forum Help |
