Re: MySQL lassu INSERT/UPDATE
On Wed, Sep 30, 2009 at 01:37:30PM +0200, Hegedüs Ervin wrote: BBU-t kinyomoztatom, de - bocs a lama kerdesert - write-cache nelkul ennyivel lassabb? Ill ez most koltoi volt, nem varok ra valaszt, inkabb hogy egy noname IDE vezerlon be van kapcsolva a write-cache? Akkor itt sem felek tole igazabol... :) Nem a vezerlon, a diszkben. itt vezerlohoz volt kotve a write-cache, tehat egy checkbox volt - az azt jelenti hogy minden diszken megcsinalja? Bocs a kesoi valaszert. Amennyire en olvasgattam az idok folyaman, a leggyakoribb (vagy csak legtobb publicitast kapott) megoldas, hogy a RAID vezerlo az osszes diszken kikapcsolja a diszk sajat cache-et, es amikor a cache ki- ill. bekapcsolasarol van szo, akkor az a vezerlon levo memoria hasznalatat ill. hasznalatanak modjat jelenti. Persze ettol meg lehet, hogy a tied nem igy mukodik, szoval nezz utana a dokumentacioban (mar ha leirjak benne, hogy mi is tortenik a szinfalak mogott). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
2009. 09. 29, kedd keltezéssel 22.29-kor Hegedüs Ervin ezt írta: A novekedes kulonbsegere viszonylag egyszeru a magyarazat: az autocommit eseteben diszk-bound a hatarertek, itt nem volt nagy fejlodes, a nocommit eseteben memoria-cpu-bound a hatarertek, itt volt nagy fejlodes. hogy erted, h nem volt nagy fejlodes? Az elozo gephez kepest? Egy ICH5-os vezerlon logo Maxtor IDE helyett egy P410-esen levo RAID10-es SATA tobm van. Igy van, ez messze nem akkora kulonbseg, mint amekkora a ket gep kozott egyebkent van. Probald ki, csereld meg a ket diszk-alrendszert... Ill. nem ertem a novekedes kulonbseget sem: melyikre gondolsz? Akkor olvasd el meg parszor a levelet, meg fogod erteni. :) -- Üdvözlettel, Gábriel Ákos -=E-Mail :akos.gabr...@i-logic.hu|Web: http://www.i-logic.hu=- -=Tel/fax:+3612391618|Mobil:+36209278894 =- _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
hello, hogy erted, h nem volt nagy fejlodes? Az elozo gephez kepest? Egy ICH5-os vezerlon logo Maxtor IDE helyett egy P410-esen levo RAID10-es SATA tobm van. Igy van, ez messze nem akkora kulonbseg, mint amekkora a ket gep kozott egyebkent van. Probald ki, csereld meg a ket diszk-alrendszert... momentan nincs ra lehetosegem... :) meg egyebkent is kihagynam. Ill. nem ertem a novekedes kulonbseget sem: melyikre gondolsz? Akkor olvasd el meg parszor a levelet, meg fogod erteni. :) ok, tfh tudom h melyikre gondoltal, de miert egyszeru a magyarazat? Igazabol nem a novekedes kulonbseg erdekel, hanem hogy miert lassabb 5x az uj gep ugyanazzal a scripttel, mind a regi? 1000 rekord betoltese tablankenti commit-tal: regi: 32sec uj: 2m48sec 1000 rekord betoltese egy commit-tal: regi: 16sec uj: 5.9sec Ebbol engem a 32sec vs 168sec zavar, ennek az okat szeretnem kideriteni. A 2x gyorsulas vs 28x gyorsulas nem igazan erdekel... Koszi: a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
On Wed, Sep 30, 2009 at 10:15:29AM +0200, Hegedüs Ervin wrote: 1000 rekord betoltese tablankenti commit-tal: regi: 32sec uj: 2m48sec 1000 rekord betoltese egy commit-tal: regi: 16sec uj: 5.9sec Ebbol engem a 32sec vs 168sec zavar, ennek az okat szeretnem kideriteni. Commit ~= cache flush. Ha az uj gepen a cache flush lassabb, minden mas gyorsabb, akkor az nagyon szepen magyarazza a fenti eredmenyeket. Itt van egy kis teszt programocska: http://osdir.com/ml/linux-ext4/2009-03/msg00325.html Mit ir ki a regi ill. az uj gepen? Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
hello, 1000 rekord betoltese tablankenti commit-tal: regi: 32sec uj: 2m48sec 1000 rekord betoltese egy commit-tal: regi: 16sec uj: 5.9sec Ebbol engem a 32sec vs 168sec zavar, ennek az okat szeretnem kideriteni. Commit ~= cache flush. Ha az uj gepen a cache flush lassabb, minden mas gyorsabb, akkor az nagyon szepen magyarazza a fenti eredmenyeket. Itt van egy kis teszt programocska: http://osdir.com/ml/linux-ext4/2009-03/msg00325.html Mit ir ki a regi ill. az uj gepen? huhh, ez durva: regi: fsync time: 0.0158 fsync time: 0.0150 fsync time: 0.0154 fsync time: 0.0151 fsync time: 0.0147 fsync time: 0.0153 uj: fsync time: 0.0692 fsync time: 0.1493 fsync time: 0.0644 fsync time: 0.0733 fsync time: 0.0743 fsync time: 0.0661 Kiprobaltam a masik tombon is: fsync time: 0.0788 fsync time: 0.0743 fsync time: 0.0744 fsync time: 0.0744 fsync time: 0.0744 fsync time: 0.0744 es sajnos ezzel egyidoben megjelentek az alabbi sorok a logban: [603806.434791] end_request: I/O error, dev cciss/c0d1, sector 0 [603806.449380] end_request: I/O error, dev cciss/c0d1, sector 0 ... [603824.841591] end_request: I/O error, dev cciss/c0d0, sector 0 [603824.841683] end_request: I/O error, dev cciss/c0d0, sector 0 (mikor a problema felmerult, mar gondoltam hw hibara, megneztem a logokat, de nem volt semmi - ezt csak ma vettem eszre, de most ha fut a script, akkor is megjelenik az uzenet... :() a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
2009. 09. 30, szerda keltezéssel 11.04-kor Hegedüs Ervin ezt írta: [603806.434791] end_request: I/O error, dev cciss/c0d1, sector 0 [603806.449380] end_request: I/O error, dev cciss/c0d1, sector 0 O nagyon jo, pont ilyen hiba volt nalunk is. A RAID10 tombon az egyik diszk lassuzott. Nem hibazott, SMART se irt semmi rosszat, de lassuzott. Amiota a diszket kicsereltuk, azota a tomb sebessege kb. megduplazodott. Ja es ugye far-copy -s a RAID10-ed? -- Üdvözlettel, Gábriel Ákos -=E-Mail :akos.gabr...@i-logic.hu|Web: http://www.i-logic.hu=- -=Tel/fax:+3612391618|Mobil:+36209278894 =- _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
hello, [603806.434791] end_request: I/O error, dev cciss/c0d1, sector 0 [603806.449380] end_request: I/O error, dev cciss/c0d1, sector 0 O nagyon jo, pont ilyen hiba volt nalunk is. A RAID10 tombon az egyik diszk lassuzott. Nem hibazott, SMART se irt semmi rosszat, de lassuzott. Amiota a diszket kicsereltuk, azota a tomb sebessege kb. megduplazodott. Ja es ugye far-copy -s a RAID10-ed? A far-copy-nak utana nezek - de ha megmondod, hol lehet, segitesz, nem remlik ilyen menupont A masik tombre miert irt hibat? (cciss/c0d0). Tovabbi fejlemeny: volt egy restart, a tesztre megszunt a cciss/c0d0-on a hiba, nem tudom reprodukalni. A cciss/c0d1-en viszont eltunt a particios tabla... :( Letrehoztam, s' lon a pvdisplay/vgdisplay mutatja a volume-okat, melyeket letrehoztam. Viszont a cciss/c0d1-en ismet elojott a hiba. bonusz kerdes: a fenti esetben hogy sikerult kideriteni, melyik a hibas diszk? jozan parasztival egyesevel kihuzkodni? :) a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
Hegedüs Ervin wrote: es sajnos ezzel egyidoben megjelentek az alabbi sorok a logban: [603806.434791] end_request: I/O error, dev cciss/c0d1, sector 0 [603806.449380] end_request: I/O error, dev cciss/c0d1, sector 0 ... [603824.841591] end_request: I/O error, dev cciss/c0d0, sector 0 [603824.841683] end_request: I/O error, dev cciss/c0d0, sector 0 (mikor a problema felmerult, mar gondoltam hw hibara, megneztem a logokat, de nem volt semmi - ezt csak ma vettem eszre, de most ha fut a script, akkor is megjelenik az uzenet... :() Imho ez valoban gaz. Az elso disk elso sectora az mbr, amire panaszkodni egy bebootolt rendszeren filemuvelet kozben eleg necces...Plane, hogy a masodik tombre is panaszkodik, mikozben a tesztelo csak egy filet piszkal. -- Gabor HALASZ halas...@freemail.hu _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
Hegedüs Ervin wrote: bonusz kerdes: a fenti esetben hogy sikerult kideriteni, melyik a hibas diszk? jozan parasztival egyesevel kihuzkodni? :) Jozan paraszti esszel gondold vegig, mire is panaszkodik: egy hw raid tombre, ami tobb diszkbol all. Ha valamelyik diszken failure van, akkor a raid vezerlo kidobja a tombbol (vagy a smart redirekcioval megprobalja megbuheralni), bekapcsolja a failure lampat, ordibal, hogy odalett a redundancia, stb...de io error nem keletkezik, ez (lenne) a raid lenyege. Ha pedig annyi diszk esik ki, hogy odalesz a tomb, akkor offlineba rakja, es nem latja tobbet az os. Plusz amit a masik mailben is irtam: a nullas szektor az mbr es a particios tabla, oda csak igen ritkan ir a rendszer. -- Gabor HALASZ halas...@freemail.hu _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
Hello, es sajnos ezzel egyidoben megjelentek az alabbi sorok a logban: [603806.434791] end_request: I/O error, dev cciss/c0d1, sector 0 [603806.449380] end_request: I/O error, dev cciss/c0d1, sector 0 ... [603824.841591] end_request: I/O error, dev cciss/c0d0, sector 0 [603824.841683] end_request: I/O error, dev cciss/c0d0, sector 0 (mikor a problema felmerult, mar gondoltam hw hibara, megneztem a logokat, de nem volt semmi - ezt csak ma vettem eszre, de most ha fut a script, akkor is megjelenik az uzenet... :() Imho ez valoban gaz. Az elso disk elso sectora az mbr, amire panaszkodni egy bebootolt rendszeren filemuvelet kozben eleg necces...Plane, hogy a masodik tombre is panaszkodik, mikozben a tesztelo csak egy filet piszkal. az elso diszk hiba reboot utan megszunt - ennek nem feltetlen orulok, de most nem tudom reprodukalni a hibat. a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
Hello, bonusz kerdes: a fenti esetben hogy sikerult kideriteni, melyik a hibas diszk? jozan parasztival egyesevel kihuzkodni? :) Jozan paraszti esszel gondold vegig, mire is panaszkodik: egy hw raid tombre, ami tobb diszkbol all. Ha valamelyik diszken failure van, akkor a raid vezerlo kidobja a tombbol (vagy a smart redirekcioval megprobalja megbuheralni), bekapcsolja a failure lampat, ordibal, hogy odalett a redundancia, stb...de io error nem keletkezik, ez (lenne) a raid lenyege. Ha pedig annyi diszk esik ki, hogy odalesz a tomb, akkor offlineba rakja, es nem latja tobbet az os. Plusz amit a masik mailben is irtam: a nullas szektor az mbr es a particios tabla, oda csak igen ritkan ir a rendszer. tok logikus amit irsz, de Gabriel Akos irta, h naluk ue volt ezzel a vezerlovel (ha jol ertem): semmi hiba se a smart altal, sem sehonnan, megis az egyik diszk kivetele utan felgyorsult a rendszer. Az meg nem tiszta, hogy ugyanez a hibauzenet volt naluk is... Koszi: a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
Hegedüs Ervin wrote: tok logikus amit irsz, de Gabriel Akos irta, h naluk ue volt ezzel a vezerlovel (ha jol ertem): semmi hiba se a smart altal, sem sehonnan, megis az egyik diszk kivetele utan felgyorsult a rendszer. Szereny maganvelemenyem: a smart ugy hulyeseg, ahogy van, es aki smartra alapozza a rendszeret, az ugy jar mint Te vagy Akos. Mar a diszkben levo smart implementaciok is gyakran es csunyan bugosak, utana ezek a gyakran fals informaciok alapjan probalnak a mindenfele eszkozok (vezerlo, kernel) ertelmetlen muveleteket vegezni. Az meg nem tiszta, hogy ugyanez a hibauzenet volt naluk is... Reszletkerdes, a te rendszered jelen allapotaban hasznalhatatlan es eletveszelyes: egy intenzivebb write sorozatra felulirta a particios tablat. A helyesben eloszor masik fs-sel (megint csak azt mondanam, hogy ne extx legyen, plane ne ext4) futtasd az fsync tesztet, ha nem jon elo a hiba, akkor a te problemad rendezodott, mar csak egy oprendszert kell keresned a linux helyett. Ha ismet jelentkezik a hiba. akkor legyalulnam az egesz rendszert, elkezdenem firmware upgradelni a mindent (diskek, raid, alaplap), aztan ujrakezdenem egy massziv tesztelessel. -- Gabor HALASZ halas...@freemail.hu _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
On Wed, Sep 30, 2009 at 11:26:46AM +0200, Gábriel Ákos wrote: Ja es ugye far-copy -s a RAID10-ed? Khm, HW RAID... Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
Hello, Szereny maganvelemenyem: a smart ugy hulyeseg, ahogy van, es aki smartra alapozza a rendszeret, az ugy jar mint Te vagy Akos. Mar a diszkben levo smart implementaciok is gyakran es csunyan bugosak, utana ezek a gyakran fals informaciok alapjan probalnak a mindenfele eszkozok (vezerlo, kernel) ertelmetlen muveleteket vegezni. tiszteletben tartom a velemenyed, es nem erre alapozom a rendszert (ezen pl nincs is smartd) - a rendszert (ertelemszeruen reszben) a raid vezerlore alapoznam. az en maganvelemenyem hogy barmilyen matrica van a diszken/alaplapon, ez bizonyos hataron kivul sokat nem valtoztat: ez van, feljebb lehet menni k*10-szeres szorzoval, es lehet ott (is) firwarekkel b*szakodni (bocs). Az meg nem tiszta, hogy ugyanez a hibauzenet volt naluk is... Reszletkerdes, a te rendszered jelen allapotaban hasznalhatatlan es eletveszelyes: egy intenzivebb write sorozatra felulirta a particios tablat. A helyesben eloszor masik fs-sel (megint csak azt mondanam, hogy ne extx legyen, plane ne ext4) futtasd az fsync tesztet, ha nem jon elo ok, kiprobalok masik fs-t is, a hiba, akkor a te problemad rendezodott, mar csak egy oprendszert kell keresned a linux helyett. az alkalmazas alapvetoleg LAMP-ra keszult, Windows-t nem valoszinu, h teszunk be, mivel ez is olyan lesz (erzesem szerint), hogy van egy hasznalhato gep, nosza talaljunk meg feladatot neki. Mivel PC architektura, szoba johetne meg a *BSD, de nem vagyok hive a hegeszteseknek: ha valaki elojon egy jo otlettel hogy legyen rajta Oracle vagy XXX (- tetszoleges BSD unsupported alkalmazast beirhatsz), akkor megint csak en leszek a saras, hogy miert ezt talaltam ki. De ezt a reszt hagyjuk is. Ha ismet jelentkezik a hiba. akkor legyalulnam az egesz rendszert, elkezdenem firmware upgradelni a mindent (diskek, raid, alaplap), aztan ujrakezdenem egy massziv tesztelessel. egyszerubb kihivni a szervizt, ket hetes gep, jojjon ki es nezze meg... :) a. -- Gabor HALASZ halas...@freemail.hu _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
Hello, 1000 rekord betoltese tablankenti commit-tal: regi: 32sec uj: 2m48sec 1000 rekord betoltese egy commit-tal: regi: 16sec uj: 5.9sec Ebbol engem a 32sec vs 168sec zavar, ennek az okat szeretnem kideriteni. Commit ~= cache flush. Ha az uj gepen a cache flush lassabb, minden mas gyorsabb, akkor az nagyon szepen magyarazza a fenti eredmenyeket. Itt van egy kis teszt programocska: http://osdir.com/ml/linux-ext4/2009-03/msg00325.html Mit ir ki a regi ill. az uj gepen? nos, elokapartam valami utilitty CD-t a doboz aljarol, bebootoltam vele, s lon Kanaan: egy menuponttal tobb lett a wizzard kepernyon, egereszve be tudtam kapcsolni a kikapcsolt allapotban leledzett write-cache-t. Ujraepitettem a RADI10-et, es most lazan veri barmilyen modban a regi gepet. Az osszes hibauzenet megszunt - nem tudom most oruljek vagy kossem fel magam inkabb... a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
hello, Akkor ennyit a MySQL buheralasrol :-) :) es sajnos ezzel egyidoben megjelentek az alabbi sorok a logban: [603806.434791] end_request: I/O error, dev cciss/c0d1, sector 0 [603806.449380] end_request: I/O error, dev cciss/c0d1, sector 0 ... [603824.841591] end_request: I/O error, dev cciss/c0d0, sector 0 [603824.841683] end_request: I/O error, dev cciss/c0d0, sector 0 Hat, ez szagrol nem media hiba, ugyhogy csak a szokasos altalanos menetrendet tudom ajanlani: - eloszor is probalj meg valami HP management cuccost beloni, hatha mond valami okosat. Ha maskepp nem, akkor live CD-rol vagy rakj fel egy hivatalosan is tamogatott disztribuciot a swap particiora. irtam masik mailt is, (HP wizzarddal be tudtam kapcsolni a write cache-t, _minden_ nyomor megszunt, a gep hasitja a pitet) - tapegyseg es kabelek ellenorzese az alapjan ezt kizarnam, - controller firmware upgrade nem tudom erdemes-e meg - fazom az ilyenektol... - diszk firmware upgrade (a HP-nel a controller support oldalan van nehany) fazom++, - diszk csere. Sajnos a HW RAID vezerlok nem minden diszket szeretnek, es a HP persze csak a sajat markajelzessel ellatott diszkekre garantalja, hogy egyuttmukodnek a vezerlovel. Szoval ha nem HP-s diszkjeid vannak, akkor hivatalosan meg csak nem is reklamalhatsz... HP diszkek vannak benne. a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
2009. 09. 30, szerda keltezéssel 12.16-kor Hegedüs Ervin ezt írta: tok logikus amit irsz, de Gabriel Akos irta, h naluk ue volt ezzel a vezerlovel (ha jol ertem): semmi hiba se a smart altal, bocs, nem ugyanezzel a vezerlovel volt. sw raid10. Ilyen modon valszeg a far-copy sem ertelmezheto a hw raid rendszereden. a hiba misztikus eltunese reboot utan mindenesetre nyugtalanitana. lehet hogy tenyleg erdemes lenne upgradelni a firmware-ket, legalabb a vezerloet. -- Üdvözlettel, Gábriel Ákos -=E-Mail :akos.gabr...@i-logic.hu|Web: http://www.i-logic.hu=- -=Tel/fax:+3612391618|Mobil:+36209278894 =- _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
2009. 09. 30, szerda keltezéssel 13.05-kor Hegedüs Ervin ezt írta: HP diszkek vannak benne. akarod mondani hp matricas maxtorok :) -- Üdvözlettel, Gábriel Ákos -=E-Mail :akos.gabr...@i-logic.hu|Web: http://www.i-logic.hu=- -=Tel/fax:+3612391618|Mobil:+36209278894 =- _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
On Wed, Sep 30, 2009 at 01:00:09PM +0200, Hegedüs Ervin wrote: nos, elokapartam valami utilitty CD-t a doboz aljarol, bebootoltam vele, s lon Kanaan: egy menuponttal tobb lett a wizzard kepernyon, egereszve be tudtam kapcsolni a kikapcsolt allapotban leledzett write-cache-t. Ujraepitettem a RADI10-et, es most lazan veri barmilyen modban a regi gepet. Ez megintcsak felveti azt a kerdest, hogy van-e BBU? Az lenne a logikus, hogy BBU jelenlete eseten defaultbol legyen write cache, BBU nelkul pedig ne legyen. Persze ha a sebesseg fontosabb, mint az adatok biztonsaga, akkor BBU nelkul is be lehet kapcsolni a cache-t. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
Hegedüs Ervin wrote: Hello, Szereny maganvelemenyem: a smart ugy hulyeseg, ahogy van, es aki smartra alapozza a rendszeret, az ugy jar mint Te vagy Akos. Mar a diszkben levo smart implementaciok is gyakran es csunyan bugosak, utana ezek a gyakran fals informaciok alapjan probalnak a mindenfele eszkozok (vezerlo, kernel) ertelmetlen muveleteket vegezni. tiszteletben tartom a velemenyed, es nem erre alapozom a rendszert (ezen pl nincs is smartd) - a rendszert (ertelemszeruen reszben) a raid vezerlore alapoznam. A raid vezerlo is hasznal(hat)ja, probald meg ott kikapcsolni. az en maganvelemenyem hogy barmilyen matrica van a diszken/alaplapon, ez bizonyos hataron kivul sokat nem valtoztat: ez van, feljebb lehet menni k*10-szeres szorzoval, es lehet ott (is) firwarekkel b*szakodni (bocs). En is ugy latom, hogy a rebranded cuccokkal sokkal tobb baj van. Lehet, hogy par szazelekkal gyorsabbak vagy jobban illeszkednek a brand altal gyartott managementcucchoz a megpatkolt vezerlok/diszkek, de cserebe sokkal tobb bugot tartalmaznak (kisebb feljesztesi tapasztalat, kisebb peldanyszam, stb..) a hiba, akkor a te problemad rendezodott, mar csak egy oprendszert kell keresned a linux helyett. az alkalmazas alapvetoleg LAMP-ra keszult, Windows-t nem valoszinu, h teszunk be, mivel ez is olyan lesz (erzesem szerint), hogy van egy hasznalhato gep, nosza talaljunk meg feladatot neki. Amennyiben masik filesystemmel nem jelentkezik, akkor egyertelmuen az ext4 okozta a problemat (elotte nem irtad, hogy ilyen uzeneteid lettek volna). Az ext4 nem stable meg (ha jol tudom), elofordulhatnak benne bugok; a problema az, hogy _ha_ valoban az fs hiba eszkalalodott a rendszeren egeszen odaig, hogy leverte a particios tabladat, akkor ez erosen megkerdojelezi a linux kernel hasznalhatosagat. -- Gabor HALASZ halas...@freemail.hu _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
2009. 09. 30, szerda keltezéssel 13.14-kor Gabor HALASZ ezt írta: Az ext4 nem stable meg (ha jol tudom), elofordulhatnak benne bugok; a problema az, hogy _ha_ valoban az fs hiba eszkalalodott a rendszeren egeszen odaig, hogy leverte a particios tabladat, akkor ez erosen megkerdojelezi a linux kernel hasznalhatosagat. Én mondjuk 5x nagyobb esélyt adok a hw hibának. -- Üdvözlettel, Gábriel Ákos -=E-Mail :akos.gabr...@i-logic.hu|Web: http://www.i-logic.hu=- -=Tel/fax:+3612391618|Mobil:+36209278894 =- _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
Hegedüs Ervin wrote: nos, elokapartam valami utilitty CD-t a doboz aljarol, bebootoltam vele, s lon Kanaan: egy menuponttal tobb lett a wizzard kepernyon, egereszve be tudtam kapcsolni a kikapcsolt allapotban leledzett write-cache-t. Szerintem azert nem lattad a biosban, mert nincs bbu-d, anelkul pedig a writecachet hasznalni nem tanacsos. Az osszes hibauzenet megszunt - nem tudom most oruljek vagy kossem fel magam inkabb... Megmagyarazhatatlan hiba megmagyarazhatatlan eltunese nem igazan ok az oromkodesre. Plane, hogy a writecache ki/be kapcsolt allapotaban is hibatlanul kell mukodnie a rendszernek. -- Gabor HALASZ halas...@freemail.hu _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
hello, tiszteletben tartom a velemenyed, es nem erre alapozom a rendszert (ezen pl nincs is smartd) - a rendszert (ertelemszeruen reszben) a raid vezerlore alapoznam. A raid vezerlo is hasznal(hat)ja, probald meg ott kikapcsolni. a HP utility-ben nem volt ilyen opcio - feltetelezem nincs. a hiba, akkor a te problemad rendezodott, mar csak egy oprendszert kell keresned a linux helyett. az alkalmazas alapvetoleg LAMP-ra keszult, Windows-t nem valoszinu, h teszunk be, mivel ez is olyan lesz (erzesem szerint), hogy van egy hasznalhato gep, nosza talaljunk meg feladatot neki. Amennyiben masik filesystemmel nem jelentkezik, akkor egyertelmuen az ext4 okozta a problemat (elotte nem irtad, hogy ilyen uzeneteid lettek volna). Az ext4 nem stable meg (ha jol tudom), elofordulhatnak benne bugok; a nem irtam sehol ext4-et, ill egyszer irtam h kiprobaltam _azzal_ is, es utana irtam hogy ext3 van mindehol. problema az, hogy _ha_ valoban az fs hiba eszkalalodott a rendszeren egeszen odaig, hogy leverte a particios tabladat, akkor ez erosen megkerdojelezi a linux kernel hasznalhatosagat. most hogy igy mondod, kb az ext4 proba utan volt eloszor I/O error (ket napja), a gep kb 10 napja megy, visszaneztem a logokat. de ennek kihatasa lehet a masik tombre is? vagy egyszeruen tenyleg vmi kernel feature? a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
hello, nos, elokapartam valami utilitty CD-t a doboz aljarol, bebootoltam vele, s lon Kanaan: egy menuponttal tobb lett a wizzard kepernyon, egereszve be tudtam kapcsolni a kikapcsolt allapotban leledzett write-cache-t. Ujraepitettem a RADI10-et, es most lazan veri barmilyen modban a regi gepet. Ez megintcsak felveti azt a kerdest, hogy van-e BBU? Az lenne a logikus, hogy BBU jelenlete eseten defaultbol legyen write cache, BBU nelkul pedig ne legyen. Persze ha a sebesseg fontosabb, mint az adatok biztonsaga, akkor BBU nelkul is be lehet kapcsolni a cache-t. BBU-t kinyomoztatom, de - bocs a lama kerdesert - write-cache nelkul ennyivel lassabb? Ill ez most koltoi volt, nem varok ra valaszt, inkabb hogy egy noname IDE vezerlon be van kapcsolva a write-cache? Akkor itt sem felek tole igazabol... :) a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
hello, bebootoltam vele, s lon Kanaan: egy menuponttal tobb lett a wizzard kepernyon, egereszve be tudtam kapcsolni a kikapcsolt allapotban leledzett write-cache-t. Szerintem azert nem lattad a biosban, mert nincs bbu-d, anelkul pedig a writecachet hasznalni nem tanacsos. ahha, bar ez a P410i eleg gagyi, max 2 tombot enged letrehozni, es nincs JBOD opcio... en siman kinezem, h ezzel is sporoltak... Az osszes hibauzenet megszunt - nem tudom most oruljek vagy kossem fel magam inkabb... Megmagyarazhatatlan hiba megmagyarazhatatlan eltunese nem igazan ok az oromkodesre. Plane, hogy a writecache ki/be kapcsolt allapotaban is hibatlanul kell mukodnie a rendszernek. a masik levelben irtam: az ext4 probaja elegge osszefuggesben van a hiba megjelenesevel: Sep 28 13:09:17 linux mysqld[18221]: 090928 13:09:17 [Note] /usr/sbin/mysqld: Shutdown complete Sep 28 13:09:17 linux mysqld[18221]: Sep 28 13:09:17 linux mysqld_safe[18616]: ended [airween molyol...] Sep 28 13:13:46 linux kernel: [439298.009431] EXT4-fs (dm-0): barriers enabled Sep 28 13:14:44 linux kernel: [439298.028422] kjournald2 starting: pid 18646, dev dm-0:8, commit interval 5 seconds Sep 28 13:14:44 linux kernel: [439298.040769] EXT4-fs (dm-0): internal journal on dm-0:8 Sep 28 13:14:44 linux kernel: [439298.040774] EXT4-fs (dm-0): delayed allocation enabled Sep 28 13:14:44 linux kernel: [439298.040778] EXT4-fs: file extents enabled Sep 28 13:14:44 linux kernel: [439298.047257] EXT4-fs: mballoc enabled Sep 28 13:14:44 linux kernel: [439298.047271] EXT4-fs (dm-0): mounted filesystem with writeback data mode Sep 28 13:14:44 linux kernel: [439320.129197] end_request: I/O error, dev cciss/c0d1, sector 0 Sep 28 13:14:44 linux kernel: [439320.136986] end_request: I/O error, dev cciss/c0d1, sector 0 szal' ez itt eletem elso ext4 probajanak hiteles kivonata. es az elso I/O hiba a nehany szazezerbol... a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
On Wed, Sep 30, 2009 at 01:20:27PM +0200, Hegedüs Ervin wrote: BBU-t kinyomoztatom, de - bocs a lama kerdesert - write-cache nelkul ennyivel lassabb? Ill ez most koltoi volt, nem varok ra valaszt, inkabb hogy egy noname IDE vezerlon be van kapcsolva a write-cache? Akkor itt sem felek tole igazabol... :) Nem a vezerlon, a diszkben. A HW RAID vezerlok szepen kikapcsoljak a diszkeken a write cache-t, mondvan hogy ott van helyette a vezerlon levo. Probald meg a regi gepen hdparm -W-vel kikapcsolni a diszken levo cache-t, es ugy hasonlitsd ossze a teljesitmenyt. Bar desktop kategoriaban allitolag vannak olyan diszkek, amik siman azt hazudjak, hogy kikapcsoltak a cache-t, pedig megsem. A cache-sel persze semmi gond addig, amig el nem megy az aram. Innentol az a kerdes, mennyire bizol az UPS-ben. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
hello, BBU-t kinyomoztatom, de - bocs a lama kerdesert - write-cache nelkul ennyivel lassabb? Ill ez most koltoi volt, nem varok ra valaszt, inkabb hogy egy noname IDE vezerlon be van kapcsolva a write-cache? Akkor itt sem felek tole igazabol... :) Nem a vezerlon, a diszkben. itt vezerlohoz volt kotve a write-cache, tehat egy checkbox volt - az azt jelenti hogy minden diszken megcsinalja? A HW RAID vezerlok szepen kikapcsoljak a diszkeken a write cache-t, mondvan hogy ott van helyette a vezerlon levo. Probald meg a regi gepen hdparm -W-vel kikapcsolni a diszken levo cache-t, es ugy hasonlitsd ossze a teljesitmenyt. Bar desktop kategoriaban allitolag vannak olyan diszkek, amik siman azt hazudjak, hogy kikapcsoltak a cache-t, pedig megsem. bingo, belassult, kb 2x olyan lassu lett. A cache-sel persze semmi gond addig, amig el nem megy az aram. Innentol az a kerdes, mennyire bizol az UPS-ben. miféle UPS-ben...? :P a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
Hegedüs Ervin wrote: problema az, hogy _ha_ valoban az fs hiba eszkalalodott a rendszeren egeszen odaig, hogy leverte a particios tabladat, akkor ez erosen megkerdojelezi a linux kernel hasznalhatosagat. most hogy igy mondod, kb az ext4 proba utan volt eloszor I/O error (ket napja), a gep kb 10 napja megy, visszaneztem a logokat. de ennek kihatasa lehet a masik tombre is? vagy egyszeruen tenyleg vmi kernel feature? Nem, eppen ezert javasoltam az intenziv tesztelest, hogy valami megatalkodott hw bugot fogtal ki (van egy-ketto, pl a hw raid cache-e ritkan ecc-s, igy ha beteg egy-ket bit, az nagyon nehezen lokalizalhato, de annal rondabb hibakat tud okozni), vagy valami elfuseralt kernelverziot. Megegyszer: a disk (jelen esetben raid tomb) nullas szektoraban csak az fdisknek meg a bootloader installerenek van irnivaloja, a filesystem a kozelebe sem mehet. Kicsit Moricka jelleggel: fdisk c0d0-lal particionalod, es mkfs c0d0p1-gyel csinalsz ra filesystemet. Ha dd if=/dev/zero of=/dev/ccis/c0d0p1-et csinalsz, akkor odalesz a filesystem, ha dd if=/dev/zero of=/dev/ccis/c0d0-t akkor odalesz a minden, na ez tortent nalad. Ha az elso kivaltja a masodikat is, akkor nagy gond van, ezt kellene tesztelni az eltero filesystem + fsync teszt programmal. -- Gabor HALASZ halas...@freemail.hu _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
Hegedüs Ervin wrote: hello, bebootoltam vele, s lon Kanaan: egy menuponttal tobb lett a wizzard kepernyon, egereszve be tudtam kapcsolni a kikapcsolt allapotban leledzett write-cache-t. Szerintem azert nem lattad a biosban, mert nincs bbu-d, anelkul pedig a writecachet hasznalni nem tanacsos. ahha, bar ez a P410i eleg gagyi, max 2 tombot enged letrehozni, es nincs JBOD opcio... en siman kinezem, h ezzel is sporoltak... A bbu jelenlete eleg feltuno, valami akkumulatorpack log a kartyan. -- Gabor HALASZ halas...@freemail.hu _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
Hegedüs Ervin airw...@freemail.hu writes: nos, elokapartam valami utilitty CD-t a doboz aljarol, bebootoltam vele, s lon Kanaan: egy menuponttal tobb lett a wizzard kepernyon, egereszve be tudtam kapcsolni a kikapcsolt allapotban leledzett write-cache-t. Ez ugye nem a diszkek write-cache-e, hanem a RAID-vezérlőé? Mert ellenkező esetben a BBU sem segít rajtad (illetve az adataidon). -- Feri. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
hello, nos, elokapartam valami utilitty CD-t a doboz aljarol, bebootoltam vele, s lon Kanaan: egy menuponttal tobb lett a wizzard kepernyon, egereszve be tudtam kapcsolni a kikapcsolt allapotban leledzett write-cache-t. Ez ugye nem a diszkek write-cache-e, hanem a RAID-vezérlőé? Mert ellenkező esetben a BBU sem segít rajtad (illetve az adataidon). szerintem a vezerloe, bar Gombas Gabor egyik emailje elbizonytalanitott. Egy helyen volt write-cache, nem hiszem hogy ezzel mind a 6 diszk write-cache-t bekapcsoltam volna. a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
On Mon, Sep 28, 2009 at 03:21:56PM +0200, Hegedüs Ervin wrote: [...] En mar elvesztem egy kicsit. Jol emlekszem, hogy a disztribverziok ugyanazok? Mi a kulonbseg? Vagyis dpkg --get-selections es diff -u. Van kulonbseg a /proc/mounts-ok kozott? Udv, tamas _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
Papp Tamas írta: On Mon, Sep 28, 2009 at 03:21:56PM +0200, Hegedüs Ervin wrote: [...] En mar elvesztem egy kicsit. Jol emlekszem, hogy a disztribverziok ugyanazok? Nem. :) Itt az eredeti üzenet részlete: Hegedüs Ervin írta: Hello, adott két gép: egy régi, 2.8-as celeron, 512M RAM-mal és egy talán 80G-s IDE diszkkel. Ezen ki lett fejlesztve egy alkalmazas, működik, minden ok. A gépen Ubuntu 8.10 fut. [...] Nemrég megjött az új gép, egy HP DL350G6. SATA diszkek vannak a P410-es vezérlőn, a MySQL kapott egy raid10-es tömbböt. A gépen Ubuntu 9.10 van (tudom h alpha), 5.0.83 a MySQL verzió. -- Üdv. B. Attila _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
On Mon, Sep 28, 2009 at 01:51:38PM +0200, Hegedüs Ervin wrote: bocs, ezt nem vettem eszre: hogy konkretan ebben van-e, azt nem tudom, a P410-hez a HP SAS eseteben ad, gondolom nem szedi ki, de nem tudok egzakt pontos valaszt adni :( Hat, a HP-nel ezt irjak a gep konfiguraciojanal: Integrated HP Smart Array P410i with optional upgrades of 256MB BBWC or 512MB read cache with BBWC DL350G6-ot nem talaltam a HP-nel, csak DL360G6-ot; a High performance konfiguracioba beleertik a BBU-t, a normal konfiguracional viszont neked kell kulon bekattogtatni a Storage controller upgrade pont alatt. Szoval a szerver tipusabol meg nem egyertelmu a dolog. Ha valamelyik elore osszeallitott konfiguraciot vetted, akkor a part number alapjan meg lehet nezni; ha kezileg lett osszekattogtatva, akkor meg az Illetekes Elvtars csak emlekszik ra ill. rajta kellene, hogy legyen a szallitolevelen. Egyebkent a HP supportnal a letolteseknel van valami Linuxos CLI hozza; az nem mondja meg? BBU nelkul a HW RAID lassu, mert egy FLUSH parancs eseten kenytelen tenyleg kiirni diszkre a cuccot (raadasul a diszkeken ki szoktak kapcsolni a write cache-t), mig BBU jelenlete eseten ezt elsporolhatja. Szoval nezz utana. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
On Tue, Sep 29, 2009 at 09:44:34AM +0200, Biró Attila wrote: Papp Tamas írta: On Mon, Sep 28, 2009 at 03:21:56PM +0200, Hegedüs Ervin wrote: [...] En mar elvesztem egy kicsit. Jol emlekszem, hogy a disztribverziok ugyanazok? Nem. :) Itt az eredeti üzenet részlete: Hegedüs Ervin írta: Hello, adott két gép: egy régi, 2.8-as celeron, 512M RAM-mal és egy talán 80G-s IDE diszkkel. Ezen ki lett fejlesztve egy alkalmazas, működik, minden ok. A gépen Ubuntu 8.10 fut. [...] Nemrég megjött az új gép, egy HP DL350G6. SATA diszkek vannak a P410-es vezérlőn, a MySQL kapott egy raid10-es tömbböt. A gépen Ubuntu 9.10 van (tudom h alpha), 5.0.83 a MySQL verzió. Valo igaz, sot, igy mar be is ugrott;) Nos, en ket dolgot csinalnek meg. 1. IO tesztet a ket gepre az alkalmazastol fuggetlenul. Ha ebbol kijon a kulonbseg, akkor ott van a bibi. 2. Csak a poen kedveert akar erre a gepre, akar masikra, feltelepitenek egy ugyanolyan rendszert (akart virtualis gepre) es megneznem, ott mit produkal. Amugymeg semmikepp nem egy alpha verzioju disztribbel probalkoznek, nalam pl. egesz erdekes dolgokat produkal, igaz, php-val. tompos _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
2009. 09. 28, hétfő keltezéssel 15.21-kor Hegedüs Ervin ezt írta: Amit nem ertek, hogy ugyanazokkal a beallitasokkal egy joval erosebb gep miert produkal 2x-es futasi idot, ill ha megpiszkalom a scriptet (lasd autocommit versus rekordonkenti commit versus osszes DML utan egy commit) miert produkal kozel 30x-os gyorsulast az eros gep, a gyenge meg alig 25%-ot. Azt, hogy azonos, felejtsd el, miutan ket kulonbozo disztribuciot hasznalsz. A lassulasra egyelore nem tudok magyarazatot adni, elkepzelhetonek tartom, hogy valami adatkorrupcios vagy parhuzamossagi hibat javitottak valahol a fejlesztok (lehet ez kernel, fs, mysql) ami majdnem mindig lassulassal jar. A novekedes kulonbsegere viszonylag egyszeru a magyarazat: az autocommit eseteben diszk-bound a hatarertek, itt nem volt nagy fejlodes, a nocommit eseteben memoria-cpu-bound a hatarertek, itt volt nagy fejlodes. -- Üdvözlettel, Gábriel Ákos -=E-Mail :akos.gabr...@i-logic.hu|Web: http://www.i-logic.hu=- -=Tel/fax:+3612391618|Mobil:+36209278894 =- _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
hello, Hat, a HP-nel ezt irjak a gep konfiguraciojanal: Integrated HP Smart Array P410i with optional upgrades of 256MB BBWC or 512MB read cache with BBWC ezt koszonom, utananezek, meg nem volt idom, [...] szallitolevelen. Egyebkent a HP supportnal a letolteseknel van valami Linuxos CLI hozza; az nem mondja meg? 64bites Ubuntu van rajta, egyelore nem sikerult eletre kelteni, valami lib mindig hianyzik vagy segfaultol... BBU nelkul a HW RAID lassu, mert egy FLUSH parancs eseten kenytelen tenyleg kiirni diszkre a cuccot (raadasul a diszkeken ki szoktak kapcsolni a write cache-t), mig BBU jelenlete eseten ezt elsporolhatja. Szoval nezz utana. de akkor a korabban emlegetett commit nelkul is lassu lenne, egyebkent nincs panasz ra, ahogy irtam a dump betoltese lazan 3x gyorsabb, mint a masikon. Mertem hdparm-al, bonnie++-al, 2-3x gyorsabb a diszk benne mint a masikban a sima IDE-s. a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
hello, Nos, en ket dolgot csinalnek meg. 1. IO tesztet a ket gepre az alkalmazastol fuggetlenul. Ha ebbol kijon a kulonbseg, akkor ott van a bibi. megvolt, az uj gep 2-3x gyorsabb, mint a regi. 2. Csak a poen kedveert akar erre a gepre, akar masikra, feltelepitenek egy ugyanolyan rendszert (akart virtualis gepre) es megneznem, ott mit produkal. Amugymeg semmikepp nem egy alpha verzioju disztribbel probalkoznek, nalam pl. egesz erdekes dolgokat produkal, igaz, php-val. sorban all a request, de meg nem volt idom kitalalni sem a reszleteket. :( koszonom: a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
hello, Amit nem ertek, hogy ugyanazokkal a beallitasokkal egy joval erosebb gep miert produkal 2x-es futasi idot, ill ha megpiszkalom a scriptet (lasd autocommit versus rekordonkenti commit versus osszes DML utan egy commit) miert produkal kozel 30x-os gyorsulast az eros gep, a gyenge meg alig 25%-ot. Azt, hogy azonos, felejtsd el, miutan ket kulonbozo disztribuciot hasznalsz. ok, jogos, A lassulasra egyelore nem tudok magyarazatot adni, elkepzelhetonek tartom, hogy valami adatkorrupcios vagy parhuzamossagi hibat javitottak valahol a fejlesztok (lehet ez kernel, fs, mysql) ami majdnem mindig lassulassal jar. A novekedes kulonbsegere viszonylag egyszeru a magyarazat: az autocommit eseteben diszk-bound a hatarertek, itt nem volt nagy fejlodes, a nocommit eseteben memoria-cpu-bound a hatarertek, itt volt nagy fejlodes. hogy erted, h nem volt nagy fejlodes? Az elozo gephez kepest? Egy ICH5-os vezerlon logo Maxtor IDE helyett egy P410-esen levo RAID10-es SATA tobm van. Ill. nem ertem a novekedes kulonbseget sem: melyikre gondolsz? Koszonom: a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
2009. 09. 27, vasárnap keltezéssel 21.04-kor Hegedüs Ervin ezt írta: iowait-et neztem top-on keresztul, az az uj gepen 80-90% korul volt, a regin nehany %. a regi gepen valami fsync-szeru nincs bekapcsolva. -- Üdvözlettel, Gábriel Ákos -=E-Mail :akos.gabr...@i-logic.hu|Web: http://www.i-logic.hu=- -=Tel/fax:+3612391618|Mobil:+36209278894 =- _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
hello, iowait-et neztem top-on keresztul, az az uj gepen 80-90% korul volt, a regin nehany %. a regi gepen valami fsync-szeru nincs bekapcsolva. ezt csak ma vettem eszre, miutan Gombas Gabor barrier-es felvetese utan nyomoztam: a 9.10-es ubuntuban data=writeback-el vannak mountolva az ext3-as kotetek, a regebbi verzioban data=ordered. Felcsatoltam a particiot ordered modba, de semmit nem valtozott, ugyanolyan lassu. Annyit elertem vele, h az iowait nem megy 15-20% fole. a. ps: hol allitja be a rendszer, hogy mi legyen a default journal data ertek? ui ez nincs benne az fstab-ban, csak a /proc/mounts moutatta (hehe) meg. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
2009.09.28. 13:03 keltezéssel, Hegedüs Ervin írta: ezt csak ma vettem eszre, miutan Gombas Gabor barrier-es felvetese utan nyomoztam: a 9.10-es ubuntuban data=writeback-el vannak mountolva az ext3-as kotetek, a regebbi verzioban data=ordered. Felcsatoltam a particiot ordered modba, de semmit nem valtozott, ugyanolyan lassu. Annyit elertem vele, h az iowait nem megy 15-20% fole. cat /sys/block/disk ahol a mysql fs van/queue/scheduler mit mond? Igor _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
Hegedüs Ervin wrote: hello, iowait-et neztem top-on keresztul, az az uj gepen 80-90% korul volt, a regin nehany %. a regi gepen valami fsync-szeru nincs bekapcsolva. ezt csak ma vettem eszre, miutan Gombas Gabor barrier-es felvetese utan nyomoztam: a 9.10-es ubuntuban data=writeback-el vannak mountolva az ext3-as kotetek, a regebbi verzioban data=ordered. Felcsatoltam a particiot ordered modba, de semmit nem valtozott, ugyanolyan lassu. Annyit elertem vele, h az iowait nem megy 15-20% fole. Innodb parameterekket allitgattad? show innodb statust nezegetted insert kozben? Valami filesystemmel nem probaltad ext3 helyett? Idemasolnal egy queryt? -- Gabor HALASZ halas...@freemail.hu _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
hello, ezt csak ma vettem eszre, miutan Gombas Gabor barrier-es felvetese utan nyomoztam: a 9.10-es ubuntuban data=writeback-el vannak mountolva az ext3-as kotetek, a regebbi verzioban data=ordered. Felcsatoltam a particiot ordered modba, de semmit nem valtozott, ugyanolyan lassu. Annyit elertem vele, h az iowait nem megy 15-20% fole. cat /sys/block/disk ahol a mysql fs van/queue/scheduler mindket gepen ua: noop anticipatory [deadline] cfq a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
2009.09.28. 13:19 keltezéssel, Hegedüs Ervin írta: mindket gepen ua: noop anticipatory [deadline] cfq Mysql-nek nem árt a cfq echo cfq /sys/block/disk/queue/scheduler Igor _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
On Mon, Sep 28, 2009 at 01:03:30PM +0200, Hegedüs Ervin wrote: ezt csak ma vettem eszre, miutan Gombas Gabor barrier-es felvetese utan nyomoztam: a 9.10-es ubuntuban data=writeback-el vannak mountolva az ext3-as kotetek, a regebbi verzioban data=ordered. Ez onmagaban nem indokolna ekkora kulonbseget, es egyebkent is a writeback-nek kellene gyorsabbnak lennie. Felcsatoltam a particiot ordered modba, de semmit nem valtozott, ugyanolyan lassu. Annyit elertem vele, h az iowait nem megy 15-20% fole. a. ps: hol allitja be a rendszer, hogy mi legyen a default journal data ertek? ui ez nincs benne az fstab-ban, csak a /proc/mounts moutatta (hehe) meg. A sorrend: - mount parancssor, ha meg van adva - superblock-ban tarolt ertek (tune2fs -J) - kernel default A te esetedben a legutolso valtozott. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
On Mon, Sep 28, 2009 at 01:30:39PM +0200, Medovárszky Zoltán wrote: Mysql-nek nem árt a cfq echo cfq /sys/block/disk/queue/scheduler Az eredeti levelben RAID vezerlo es RAID tomb szerepelt; az ugyan nem volt leirva, hogy tenylegesen HW RAID van vagy SW RAID, de HW RAID eseten masok a jatekszabalyok. Egyebkent BBU van? Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
2009.09.28. 13:38 keltezéssel, Gabor Gombas írta: Az eredeti levelben RAID vezerlo es RAID tomb szerepelt; az ugyan nem volt leirva, hogy tenylegesen HW RAID van vagy SW RAID, de HW RAID eseten masok a jatekszabalyok. Egyebkent BBU van? Ez nem rémlett, jogos. Igor _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
hello, Felcsatoltam a particiot ordered modba, de semmit nem valtozott, ugyanolyan lassu. Annyit elertem vele, h az iowait nem megy 15-20% fole. mea culpa, beneztem, az uj gep 4 magos, es a top az atlagot mutatta - betoltes kozben az egyik magnal tovabbra is 80-90% kozotti io van. bocs megegyszer. a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
hello, echo cfq /sys/block/disk/queue/scheduler Az eredeti levelben RAID vezerlo es RAID tomb szerepelt; az ugyan nem volt leirva, hogy tenylegesen HW RAID van vagy SW RAID, de HW RAID eseten masok a jatekszabalyok. Egyebkent BBU van? hw raid van, bizom a HP-s P410-es vezerloben :) (1xRAID1 es 1xRAID10, utobbi a MySQL-nek) a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
hello, noop anticipatory [deadline] cfq Mysql-nek nem árt a cfq echo cfq /sys/block/disk/queue/scheduler koszi, eloszor jo lenne kozel azonos eredmenyt produkalnia, utana raernek finomhangolni, de igyekszem nem elfelejteni. Udv: a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
hello, Egyebkent BBU van? bocs, ezt nem vettem eszre: hogy konkretan ebben van-e, azt nem tudom, a P410-hez a HP SAS eseteben ad, gondolom nem szedi ki, de nem tudok egzakt pontos valaszt adni :( a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
hello, Felcsatoltam a particiot ordered modba, de semmit nem valtozott, ugyanolyan lassu. Annyit elertem vele, h az iowait nem megy 15-20% fole. Innodb parameterekket allitgattad? innodb_buffer_pool_size-t allitottam - forumokban olvastam, ahol hasonlo panasz volt, de nem hozott megoldast. show innodb statust nezegetted insert kozben? meg nem, Valami filesystemmel nem probaltad ext3 helyett? igen, most nemreg kiprobaltam ext4-el, de aa... talan meg lassabb is lett. Idemasolnal egy queryt? gondolom a lassu query-re vagy kivancsi, ami egy tok egyszeru insert into : INSERT INTO components_edit VALUES (0, 1, 1, 0, 32, '2008-07-28 9:7:32', '2008.04.01', '-00-00 00:00:00', '2009-01-20 00:00:00', '1', 12345123400, 'A-12345-1234-00', '', 0, 45900.0, 1, 0.0, '2129', '', 'user') de fontos, hogy nem maga a query a lassu, sot - az gyorsabb mint a regi gepen - a gond a comit()-tal van, valahogy igy: cursor.execute(query...) conn.comit() ebbol az execute az uj gepen 0.001-0.002 korul van, a regin 0.003-0.004. A commit() viszont a regin kb ua (fejbol mondom, nem pontos), a regin 0.007-0.008 korul van (az ertekek sec-ben, a python time modulja szamolja ki t1-t0 alakban) a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
Hegedüs Ervin wrote: hello, Felcsatoltam a particiot ordered modba, de semmit nem valtozott, ugyanolyan lassu. Annyit elertem vele, h az iowait nem megy 15-20% fole. Innodb parameterekket allitgattad? innodb_buffer_pool_size-t allitottam - forumokban olvastam, ahol hasonlo panasz volt, de nem hozott megoldast. show innodb statust nezegetted insert kozben? meg nem, Tegyed, mert az elejen reszletezi az io threadek allapotat, fuggoben levo/lezajlott fsync-eket, i/o statiszikakat, stb, igy valami fogalmad is lesz arrol, mi is tortenik. Valami filesystemmel nem probaltad ext3 helyett? igen, most nemreg kiprobaltam ext4-el, de aa... talan meg lassabb is lett. Filesystemrol volt szo, azoknak nem ext-tel kezdodik a nevuk. Probald meg reiserfs3-mal, nem mintha idealis lenne sql ala, de probanak jo. de fontos, hogy nem maga a query a lassu, sot - az gyorsabb mint a regi gepen - a gond a comit()-tal van, Nyilvan, addig nem sok minden tortenik. cursor.execute(query...) conn.comit() ebbol az execute az uj gepen 0.001-0.002 korul van, a regin 0.003-0.004. A commit() viszont a regin kb ua (fejbol mondom, nem pontos), a regin 0.007-0.008 korul van (az ertekek sec-ben, a python time modulja szamolja ki t1-t0 alakban) Pythont nem szeretem, igy mond el, mi ez a cursor.execute es miert nem cursor.commit van utana, ha mar? Csak nem full commitot csinalsz minden query utan? Ennek van valami koze az sql cursorokhoz, vagy csak szerencsetlen nevvalasztas? -- Gabor HALASZ halas...@freemail.hu _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
Hegedüs Ervin wrote: hello, Felcsatoltam a particiot ordered modba, de semmit nem valtozott, ugyanolyan lassu. Annyit elertem vele, h az iowait nem megy 15-20% fole. Innodb parameterekket allitgattad? innodb_buffer_pool_size-t allitottam - forumokban olvastam, ahol hasonlo panasz volt, de nem hozott megoldast. jah, remelem az innodb_log_file_size-t is vele allitottad, es a transaction-isolation lehet READ-COMMITTED, ha nem utkozik a designal. -- Gabor HALASZ halas...@freemail.hu _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
show innodb statust nezegetted insert kozben? meg nem, Tegyed, mert az elejen reszletezi az io threadek allapotat, fuggoben levo/lezajlott fsync-eket, i/o statiszikakat, stb, igy valami fogalmad is lesz arrol, mi is tortenik. koszi, megnezem, Valami filesystemmel nem probaltad ext3 helyett? igen, most nemreg kiprobaltam ext4-el, de aa... talan meg lassabb is lett. Filesystemrol volt szo, azoknak nem ext-tel kezdodik a nevuk. Probald meg reiserfs3-mal, nem mintha idealis lenne sql ala, de probanak jo. ezt hagyjuk, egyreszt nem hiszem h ez az oka (a masikon mukodik, X+1 gepen egyebkent tok jol mukodik), masreszt nekem ext* meg nem crash-elt el soha, reisert lattam mar szethullva, jfs-t probaltam nehanyszor, de valami bugba mindig belefutottam... de ezt most tenyleg hagyjuk. cursor.execute(query...) conn.comit() ebbol az execute az uj gepen 0.001-0.002 korul van, a regin 0.003-0.004. A commit() viszont a regin kb ua (fejbol mondom, nem pontos), a regin 0.007-0.008 korul van (az ertekek sec-ben, a python time modulja szamolja ki t1-t0 alakban) Pythont nem szeretem, igy mond el, mi ez a cursor.execute es miert nem cursor.commit van utana, ha mar? Csak nem full commitot csinalsz minden query utan? Ennek van valami koze az sql cursorokhoz, vagy csak szerencsetlen nevvalasztas? hivhatod barhogy, en nem latok egy session-on belul mast mind full commit-ot, nem tudom mas RDBMS hogy van vele, de milyen van meg, ha nem full commit? Szerintem altalaban nincs koze az sql cursor-nak a commit-hoz, legfeljebb annyi, hogy a cursoron keresztul adod meg a DML-t, ami az adott kapcsolatban neked szukseges - itt magaban a kapcsolat leiroban van a commit, szamomra ez tok logikus. Tehat nem latom ertelmet egy cursor.commit()-nak. Pythonban feluletesen igy nez ki a kapcsolat/kurzor kezeles: =%= import MySQLdb conn = MySQLdb.connect(host, user, pass, ...) cursor = conn.cursor() cursor.execute(...) for r in cursor.fetchall(): ... vagy cursor.execute(...) conn.commit() =%= Mielott megkerded: a full commit-nak mint olyannak megvan a szerepe, esetleg tobbszalu betoltesnel (nem feltetlen thread-re gondolok, hanem masik script is fut ami az eddig betoltott adatokra epit) konzisztens adatbazist kapsz, nem kell varni, az adtok hamarabb elerhetoek. De a betoltes csak pelda. Es lehet, h ez is csak hitvita. :) Amit nem ertek, hogy ugyanazokkal a beallitasokkal egy joval erosebb gep miert produkal 2x-es futasi idot, ill ha megpiszkalom a scriptet (lasd autocommit versus rekordonkenti commit versus osszes DML utan egy commit) miert produkal kozel 30x-os gyorsulast az eros gep, a gyenge meg alig 25%-ot. lasd: http://groups.google.hu/group/hun.lists.mlf.linux/msg/d40051aaa1dd6863?hl=hu a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
hello, Innodb parameterekket allitgattad? innodb_buffer_pool_size-t allitottam - forumokban olvastam, ahol hasonlo panasz volt, de nem hozott megoldast. jah, remelem az innodb_log_file_size-t is vele allitottad, es a nem, ezt nehany forumon olvastam, de nem volt sehol ez az osszefugges. transaction-isolation lehet READ-COMMITTED, ha nem utkozik a designal. ezzel mit is erek el? meg csak olyan sincs, hogy INSERT elott kellene valami mas ertek mas tablabol, nagyjabol ennyi a pszeudo kod: insert into table1 ... commit() lastid = cursor.lastrow_id insert into table2 (lastid, ...) insert into table3 (lastid, ...) insert into table4 (lastid, ...) commit() ebbol van kb 5-6 ilyen blokk. az egyeb betoltes soran elokerulo kulcsokat nem select-el oldom meg, hanem egy dict (perl-ben hash?) valtozoban, meg ez sem lassit. (az elejen van egy select, de ez konstans ido) es ez kb 2x annyi ideig tart, mint a regi gepen. a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
Hegedüs Ervin wrote: Filesystemrol volt szo, azoknak nem ext-tel kezdodik a nevuk. Probald meg reiserfs3-mal, nem mintha idealis lenne sql ala, de probanak jo. ezt hagyjuk, egyreszt nem hiszem h ez az oka (a masikon mukodik, X+1 gepen egyebkent tok jol mukodik), masreszt nekem ext* meg nem crash-elt el soha, Nem crashrol van szo, hanem teljesitmenyrol, egy probat meger. Pythont nem szeretem, igy mond el, mi ez a cursor.execute es miert nem cursor.commit van utana, ha mar? Csak nem full commitot csinalsz minden query utan? Ennek van valami koze az sql cursorokhoz, vagy csak szerencsetlen nevvalasztas? hivhatod barhogy, en nem latok egy session-on belul mast mind full commit-ot, nem tudom mas RDBMS hogy van vele, de milyen van meg, ha nem full commit? mysqlnel global es session, es az isolation level is erosen befolyasolja, hogy a gyakorlatba mikor es mennyit cimmit-et csinal: http://dev.mysql.com/doc/refman/5.1/en/set-transaction.html Szerintem altalaban nincs koze az sql cursor-nak a commit-hoz, legfeljebb annyi, hogy a cursoron keresztul adod meg a DML-t, ami az adott kapcsolatban neked szukseges - itt magaban a kapcsolat leiroban van a commit, szamomra ez tok logikus. Tehat nem latom ertelmet egy cursor.commit()-nak. Pythonban feluletesen igy nez ki a kapcsolat/kurzor kezeles: =%= import MySQLdb conn = MySQLdb.connect(host, user, pass, ...) cursor = conn.cursor() cursor.execute(...) for r in cursor.fetchall(): ... vagy cursor.execute(...) conn.commit() Huha.Ez valami nem tudom mi: Cursors are supported inside stored routines, triggers, and events. The syntax is as in embedded SQL. Cursors in MySQL have these properties: http://dev.mysql.com/doc/refman/5.1/en/cursors.html Amit nem ertek, hogy ugyanazokkal a beallitasokkal egy joval erosebb gep miert produkal 2x-es futasi idot, ill ha megpiszkalom a scriptet (lasd autocommit versus rekordonkenti commit versus osszes DML utan egy commit) miert produkal kozel 30x-os gyorsulast az eros gep, a gyenge meg alig 25%-ot. Ez tobbrendbeli flame lenne... -- Gabor HALASZ halas...@freemail.hu _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
Hegedüs Ervin wrote: hello, Innodb parameterekket allitgattad? innodb_buffer_pool_size-t allitottam - forumokban olvastam, ahol hasonlo panasz volt, de nem hozott megoldast. jah, remelem az innodb_log_file_size-t is vele allitottad, es a nem, ezt nehany forumon olvastam, de nem volt sehol ez az osszefugges. Ideznem Bartokot: Csak tiszta forrasbol ;) nstation-1:/usr/share/mysql# fgrep 'Set .._log_file_size' *.cnf my-huge.cnf:# Set .._log_file_size to 25 % of buffer pool size my-large.cnf:# Set .._log_file_size to 25 % of buffer pool size my-medium.cnf:# Set .._log_file_size to 25 % of buffer pool size my-small.cnf:# Set .._log_file_size to 25 % of buffer pool size Szoval az example konfigokban benne van, csak a disztribuciod keszitoi kihereletek. transaction-isolation lehet READ-COMMITTED, ha nem utkozik a designal. ezzel mit is erek el? Ahogyan a kovetkezot nezem, semmit. meg csak olyan sincs, hogy INSERT elott kellene valami mas ertek mas tablabol, nagyjabol ennyi a pszeudo kod: insert into table1 ... commit() lastid = cursor.lastrow_id insert into table2 (lastid, ...) insert into table3 (lastid, ...) insert into table4 (lastid, ...) commit() ebbol van kb 5-6 ilyen blokk. az egyeb betoltes soran elokerulo kulcsokat nem select-el oldom meg, hanem egy dict (perl-ben hash?) valtozoban, meg ez sem lassit. (az elejen van egy select, de ez konstans ido) Ez a lastid = cursor.lastrow_id eleg furan hangzik. Ez a lastrow_id hogyan keletkezik? -- Gabor HALASZ halas...@freemail.hu _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
hello, ezt hagyjuk, egyreszt nem hiszem h ez az oka (a masikon mukodik, X+1 gepen egyebkent tok jol mukodik), masreszt nekem ext* meg nem crash-elt el soha, Nem crashrol van szo, hanem teljesitmenyrol, egy probat meger. egyelore jusson el oda, ahol egy masik ext3 tart :) hivhatod barhogy, en nem latok egy session-on belul mast mind full commit-ot, nem tudom mas RDBMS hogy van vele, de milyen van meg, ha nem full commit? mysqlnel global es session, es az isolation level is erosen befolyasolja, hogy a gyakorlatba mikor es mennyit cimmit-et csinal: http://dev.mysql.com/doc/refman/5.1/en/set-transaction.html teljesen jogos, ez esetben session - a global most tok nem jatszik. [...] cursor.execute(...) conn.commit() Huha.Ez valami nem tudom mi: pedig itt van ni: Cursors are supported inside stored routines, triggers, and events. The syntax is as in embedded SQL. Cursors in MySQL have these properties: http://dev.mysql.com/doc/refman/5.1/en/cursors.html inside stored routines ez meg egy API-n keresztuli hozzaferes. A ketto kozott gyak semmi kapcsolat nincs: http://mysql-python.sourceforge.net/MySQLdb.html#connection-objects MySQL does not support cursors; gondolom API-n keresztul nincs, amit olvastal, az valami sajat... Amit nem ertek, hogy ugyanazokkal a beallitasokkal egy joval erosebb gep miert produkal 2x-es futasi idot, ill ha megpiszkalom a scriptet (lasd autocommit versus rekordonkenti commit versus osszes DML utan egy commit) miert produkal kozel 30x-os gyorsulast az eros gep, a gyenge meg alig 25%-ot. Ez tobbrendbeli flame lenne... pedig ez most jobban erdekel mindennel, ha gondolod linux-flame vagy maganban is akar... Koszonom: a. -- Gabor HALASZ halas...@freemail.hu _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
hello, jah, remelem az innodb_log_file_size-t is vele allitottad, es a nem, ezt nehany forumon olvastam, de nem volt sehol ez az osszefugges. Ideznem Bartokot: Csak tiszta forrasbol ;) nocsak, komolyzenei szakertok is jarnak errefele? nstation-1:/usr/share/mysql# fgrep 'Set .._log_file_size' *.cnf my-huge.cnf:# Set .._log_file_size to 25 % of buffer pool size my-large.cnf:# Set .._log_file_size to 25 % of buffer pool size my-medium.cnf:# Set .._log_file_size to 25 % of buffer pool size my-small.cnf:# Set .._log_file_size to 25 % of buffer pool size Szoval az example konfigokban benne van, csak a disztribuciod keszitoi kihereletek. forumban olvastam tobb helyen is, ezt az egyet irtak, en voltam figyelmetlen, h jobban utana olvassak. insert into table1 ... commit() lastid = cursor.lastrow_id insert into table2 (lastid, ...) insert into table3 (lastid, ...) insert into table4 (lastid, ...) commit() ebbol van kb 5-6 ilyen blokk. az egyeb betoltes soran elokerulo kulcsokat nem select-el oldom meg, hanem egy dict (perl-ben hash?) valtozoban, meg ez sem lassit. (az elejen van egy select, de ez konstans ido) Ez a lastid = cursor.lastrow_id eleg furan hangzik. Ez a lastrow_id hogyan keletkezik? auto_increment-el definialt attributumnal insert utan visszakapod a beszurt rekord ezen erteket. nativ sql-ben is van, asszem' select lastrowid v valami ilyesmi. a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
Hegedüs Ervin írta: auto_increment-el definialt attributumnal insert utan visszakapod a beszurt rekord ezen erteket. nativ sql-ben is van, asszem' select lastrowid v valami ilyesmi. mysql-ben viszont nincs, igy valahogyan implementalni kell. A python-mysql konkretan igy csinalja: def _do_get_result(self): db = self._get_db() self._result = self._get_result() self.rowcount = db.affected_rows() self.rownumber = 0 self.description = self._result and self._result.describe() or None self.description_flags = self._result and self._result.field_flags() or None self.lastrowid = db.insert_id() self._warnings = db.warning_count() self._info = db.info() Az insert_db a mysql api resze, igy ezzel nem lesz gond (http://dev.mysql.com/doc/refman/5.0/en/mysql-insert-id.html) _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
On Sun, Sep 27, 2009 at 03:25:29AM +0200, Hegedüs Ervin wrote: az autocommit/nem autocommit futasi idok aranyi eleg erdekesen alakultak: a regi gepen mondjuk 1000 rekordra 47s/35s, az ujra 322s/13s. Az generalt I/O-t nezted mar (blktrace)? Nem lehet, hogy az uj gepen van mukodo fs barrier (azaz minden commit-nal tenylegesen kimegy diszkre az adat), a regi meg futyul ra (azaz ott marad a diszk write cache-eben)? Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
2009.09.27. 9:57 keltezéssel, Gabor Gombas írta: Az generalt I/O-t nezted mar (blktrace)? Nem lehet, hogy az uj gepen van mukodo fs barrier (azaz minden commit-nal tenylegesen kimegy diszkre az adat), a regi meg futyul ra (azaz ott marad a diszk write cache-eben)? Arról nem esett szó, hogy ugyanaz az fs van mindkét gépen a mysql alatt? Igor _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
hello, az autocommit/nem autocommit futasi idok aranyi eleg erdekesen alakultak: a regi gepen mondjuk 1000 rekordra 47s/35s, az ujra 322s/13s. Az generalt I/O-t nezted mar (blktrace)? Nem lehet, hogy az uj gepen van mukodo fs barrier (azaz minden commit-nal tenylegesen kimegy diszkre az adat), a regi meg futyul ra (azaz ott marad a diszk write cache-eben)? iowait-et neztem top-on keresztul, az az uj gepen 80-90% korul volt, a regin nehany %. Nem ismerem a blktrace-t, koszono a tippet, utananezek. a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
hello, Arról nem esett szó, hogy ugyanaz az fs van mindkét gépen a mysql alatt? bocs, jogos - ua a filerendszer van mindket gepen (ext3). a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
Hello, ugy nez ki megvan a hiba oka: a Python MySQL modulja eleg regota nem hasznal autocommit-ot, en valahogy raalltam, hogy minden DML-t kezzel commit-olok. A meresek soran kijott, h eleg lassu a commit(). Az adatfajlbol feldolgozott rekordok normalizalas utan kb 5-6 tablaba toltodnek be, pontosabban ezen tablakbol 4 van, egyfajta verzio kovetes miatt, tehat 5-6 tablacsoport van. Az eredeti scriptben minden tablacsoport utan volt commit. Ha kiveszem (ertelemszeruen mindket gepen) a tablacsoportonkeni commit-ot, akkor az uj gep nagyon csunyan elveri a regit. (egy commit van a teljes betoltes vegen, de ha mar csak rekordonknet van commit, mar akkor is jobb a futasi ido) Ha a Python connect()-et atirom hogy hasznaljon autocommit-ot, akkor a regi gep meg csúnyábban megveri az újat, mint eddig. (a 2x-es szorzo kb 7x-es lesz) Mi lehet a gond? Koszonom: a. ps: mindket gepen 2.5-os Python-t hasznalok (direkt), de a python-mysqldb ujabb az uj gepen, tehat nem egyforma a verziojuk. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
Hello, es meg egy eszrevetel: az autocommit/nem autocommit futasi idok aranyi eleg erdekesen alakultak: a regi gepen mondjuk 1000 rekordra 47s/35s, az ujra 322s/13s. Udv: a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
MySQL lassu INSERT/UPDATE
Hello, adott két gép: egy régi, 2.8-as celeron, 512M RAM-mal és egy talán 80G-s IDE diszkkel. Ezen ki lett fejlesztve egy alkalmazas, működik, minden ok. A gépen Ubuntu 8.10 fut. Az egyik fő funkció, hogy egy régi VisualBasic-ben írt alkalmazás pack-olt adatfájlját kell betölteni relációs adatbázisba, ami MySQL (5.0.67). A futási idő kb 40p volt, a betöltés Python-ban lett megírva (nem gyakori a betöltés, heti 1, max 2). A rekordok száma az adatfájlban kb 130e, ez van normalizálva. Nemrég megjött az új gép, egy HP DL350G6. SATA diszkek vannak a P410-es vezérlőn, a MySQL kapott egy raid10-es tömbböt. A gépen Ubuntu 9.10 van (tudom h alpha), 5.0.83 a MySQL verzió. Ugyanaz a betöltő script ugyanazt az adatfájlt kb 100p (!) alatt tölti be. Csak a betöltés ilyen lassú, minden SELECT (beleértve a VIEW-kat) kb 3-4x gyorsabb a már betöltött adatbázisból, mint a régi gépen. Ha a régi gépen csinálok egy dump-ot, és betöltöm, az is kb 1/3-ad idő alatt bemegy az új gépen. InnoDB az engine, merre keresgéljek? Az induló konfig ua volt, most az új gépen megemeltem a fine tuning alatt található értékeket most 2x-esre, de semmi. Most az jön, de elég macerás, hogy a python scriptben az egyes query-k futását mérem, de hátha valakinek lesz egyéb ötlete... Köszönöm: a. ps: a 8.10-es ubuntuban a Python 2.5, a 9.10-ben 2.6, de 2.5-tel is ua a tempo. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
Hegedüs Ervin írta: InnoDB az engine, merre keresgéljek? Az induló konfig ua volt, most az új gépen megemeltem a fine tuning alatt található értékeket most 2x-esre, de semmi. Eddig is innodb volt? Most az jön, de elég macerás, hogy a python scriptben az egyes query-k futását mérem, de hátha valakinek lesz egyéb ötlete... felesleges, slow query log is van. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: MySQL lassu INSERT/UPDATE
hello, InnoDB az engine, merre keresgéljek? Az induló konfig ua volt, most az új gépen megemeltem a fine tuning alatt található értékeket most 2x-esre, de semmi. Eddig is innodb volt? igen, a fejlesztes kezdete ota tudatosan ez van. Most az jön, de elég macerás, hogy a python scriptben az egyes query-k futását mérem, de hátha valakinek lesz egyéb ötlete... felesleges, slow query log is van. koszi, megnezem. a. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
