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
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ő
Hegedüs Ervin 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
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 haszn
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 na
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.
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
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,
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 mo
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 - felte
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-
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
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 probaln
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
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 =-
___
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
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] e
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
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 (vez
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
On Wed, Sep 30, 2009 at 11:04:54AM +0200, Hegedüs Ervin wrote:
> 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
>
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 sma
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 ra
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
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
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
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.
> A
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 hiba
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
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
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 disz
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.
>
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
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 r
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 val
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
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ész
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:
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 celero
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
__
Hegedüs Ervin írta:
>> Nem crashrol van szo, hanem teljesitmenyrol, egy probat meger.
>>
>
> egyelore jusson el oda, ahol egy masik ext3 tart :)
>
Kerdes persze, hogy a ket ext3 verzioja mennyiben ter el.
>
>
>> Cursors are supported inside stored routines, triggers, and events. The
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:
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
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 :)
> > hiv
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,
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* m
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
o
> >> 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 ne
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 p
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 p
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 m
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.rul
hello,
> > noop anticipatory [deadline] cfq
> >
> Mysql-nek nem árt a cfq
>
> echo cfq > /sys/block//queue/scheduler
koszi, eloszor jo lenne kozel azonos eredmenyt produkalnia, utana
"raernek" finomhangolni, de igyekszem nem elfelejteni.
Udv:
a.
hello,
> > echo cfq > /sys/block//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 :)
(1
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 me
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
_
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//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 jateksz
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
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//queue/scheduler
Igor
_
linux lista - linux@mlf.linux.rulez.org
http://ml
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,
> > ugyano
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=wr
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 s
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 a
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-
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/linu
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
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ó, h
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 (
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.
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, po
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 p
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,
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
73 matches
Mail list logo
