Re: phpBB + email
On Sun, Sep 27, 2009 at 11:36:14PM +0200, Varga Zsolt wrote: Szia Hát valóban nem kapcsólódik szervesen a linuxhot :) A regisztrált felhasználó amikor megír egy hozzászólást akkor kérheti hogy értesitést kapjon a válaszra. Hogyan, mit kell beklikkelni es foleg mit kell utolag meklikkelni? Bem írtad pontosan melyik verziót használod de gondollom a 3-ast. Igen, 3.0.5. Van olyan az adminban hogy feliratkozás a témára ha ezt enhedélyezed akkor a felhasználó kaphat értsítést mailen ha a kérdésére vagy hozzászólásáta válasz érkezik. Hol? En ilyet nem talalok. Koszi, tamas _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: phpBB + email
On Sun, Sep 27, 2009 at 10:49:42PM +0200, Papp Tamas wrote: helo! Nem kotodik szorosan a linux-hoz, de talan ez a legmegfelelobb forum, ahol felrakhatom a kerdest. Van egy forumom, ahol azt kellene megoldani, hogy ha vki valaszol vkinek egy hozzaszolasara (reply with quote), akkor a valaszt kuldje el emailben is (nem feltetlenul a tartalmat, de legalabb a linket) annak, akinek a hozzaszolasara valaszolt. A problema ott kezdodik, hogy azt sem tudom, mit keressek, mi ennek a szakszeru megfogalmazasa? Megvalaszolom magamnak. User control panel (minden usernekl a belepes utan baloldalt felul)., majd ott: Board preferences - Edit posting defaults - Notify me uplon replies by default Koszi, tompos _ 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: loopmount user-kent
Apropo mount: a sudo-n kivul milyen megoldas letezik arra, hogy cd image-eket adott user is mountolhasson a loop opcioval...? (vmi pmount -szeru dologra gondolok, de az csak a /dev-ben levo eszkozt fogad el argumentumkent) fuseiso? VJP _ 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
thunderbird + exim (SMTP)
Az a problema merult fel, hogy ha (pl.) thunderbird-bol probalok bizonyos tobb cimzettes levelet kuldeni az SMTP szerverunkon keresztul, akkor van amikor csak szaladgal a kek csik, majd egy ido utan visszajelez, hogy a szerver elutasitotta az SMTP kapcsolatot v. ilyesmi. Az SMTP szerveren exim4 (lenny) figyel, de a logjaiban semmi okat nem latom, hogy miert hiusul meg a level kuldes. Tovabb tesztelve, az derult ki, hogy neha van egy-egy cim, amit nem szeret az MTA es ha az kikerul a listabol, akkor sikerul a kuldes... (persze ez nem tuti, de mintha ilyesmi lenne az ok) De erre vonatkozolag megint nincs semmi az exim logokban. (most pl. egy fibermail.hu -s cimmel lehetett gond) Bar nem vagyok nagyon otthon a levelkuldesi protokollban, de ennek nem ugy kellene mukodnie, hogy az SMTP szerver szepen atveszi a klienstol a levelet, aztan probalkozik vele, es aztan ha olyan cimeket talal, amit nem tud feloldani, vagy kapcsolatba lepni vele, akkor arrol egy ido utan ertesiti a levelkuldot? (persze, ennek ertelmezese tobbes cimzettnel megint kerdeses lehet...) Mindenesetre nekem ugy tunik mintha a levelatvetelnel egybol vegigprobalna az osszes cimet (ill. annak MX-et), es ha az OK akkor berakja a queue-ba. Ami persze nagy cimlistanal kicsit gazosnak tunik, mert mi van, ha nem megy egybol a nevfeloldas, stb.? Nem tudom, hogy ebbe a jelensegbe beleszamit-e, de termeszetesen van mailscanner is a szerveren, tehat van egy exim4_incoming meg egy outgoing queue. Ja, most probalom a fibermail.hu egyik MX-et: # telnet mx-one.avpms.hu 25 Trying 85.90.160.120... Connected to mx-one.avpms.hu. Escape character is '^]'. helo galilei 554 SMTP protocol violation Connection closed by foreign host. (Mi ez az 554-es hiba?) Szoval, itt most thunderbird, exim, lenny v. SMTP sajatossagrol van szo? -- sZs _ 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: thunderbird + exim (SMTP)
SZABO Zsolt wrote: Nem tudom, hogy ebbe a jelensegbe beleszamit-e, de termeszetesen van mailscanner is a szerveren, tehat van egy exim4_incoming meg egy outgoing queue. Ja, most probalom a fibermail.hu egyik MX-et: # telnet mx-one.avpms.hu 25 Trying 85.90.160.120... Connected to mx-one.avpms.hu. Escape character is '^]'. helo galilei 554 SMTP protocol violation Connection closed by foreign host. (Mi ez az 554-es hiba?) Az 554 a transaction failed. En mondjuk reverse resolvalhato fqdn-nel heloznek, anelkul minden jobb erzesu smtp elzavar. -- Gabor HALASZ halas...@freemail.hu _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: thunderbird + exim (SMTP)
On Mon, 28 Sep 2009, Gabor HALASZ wrote: Az 554 a transaction failed. En mondjuk reverse resolvalhato fqdn-nel heloznek, anelkul minden jobb erzesu smtp elzavar. $ telnet mx-one.avpms.hu 25 Trying 85.90.160.120... Connected to mx-one.avpms.hu. Escape character is '^]'. helo galilei.mm.bme.hu 554 SMTP protocol violation Connection closed by foreign host. -- sZs _ 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: thunderbird + exim (SMTP)
SZABO Zsolt sz...@mm.bme.hu writes: # telnet mx-one.avpms.hu 25 Trying 85.90.160.120... Connected to mx-one.avpms.hu. Escape character is '^]'. helo galilei 554 SMTP protocol violation Connection closed by foreign host. Meg kell várnod a szerver üdvözlő üzenetét, csak azután jössz te. -- Feri. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
NFS probléma
Sziasztok! Van egy problémám az NFS-el és nem tudok zöldágra vergődni vele. Két hasonló Debian Lenny alatt teljesen jól működik az oda installált NFS szerver. A megosztások teljesen jól elérhetőek, használhatóak. Van viszont egy drbd-s cluster, (drbd8, heartbeat a disztribúció eszközeivel megvalósítva) ahol az nfs szerver nem akar egyáltalán működni. A távolról kezdeményezett mount: mount: clteszt1:/tmp failed, reason given by server: Hozzáférés megtagadva ugyanez szerveroldalon: clteszt1 mountd[3562]: NFS mount of /tmp attempted from 10.192.1.220 clteszt1 mountd[3562]: Unauthorized access by NFS client 10.192.1.220. clteszt1 mountd[3562]: Blocked attempt of 10.192.1.220 to mount /tmp a /etc/exports: /tmp -10.192.0.0/16(rw,no_root_squash,insecure,anonuid=222,anongid=103) (Ez megegyezik a többi gépen működő megosztással.) A gép kernele: 2.6.26-2-686 a hiba nfs kervel és user serverrel is u.a. A névfeloldás oda vissza működik. Megakadtam, hogy mit nézzek még meg. Látszólag csak annyi a különbség, hogy egy clusteren használom, noha az nfs még nincs cluster funkcióban, csak a feltelepítés után ki szerettem volna próbálni, hogy működik-e. Minden tippet, ötletet szívesen látok és előre is köszönök. Balage _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: NFS probléma
Ferenc Wagner írta: Pápai Balázs sparhelt.fl...@gmail.com writes: mount: clteszt1:/tmp failed, reason given by server: Hozzáférés megtagadva ugyanez szerveroldalon: clteszt1 mountd[3562]: NFS mount of /tmp attempted from 10.192.1.220 clteszt1 mountd[3562]: Unauthorized access by NFS client 10.192.1.220. clteszt1 mountd[3562]: Blocked attempt of 10.192.1.220 to mount /tmp a /etc/exports: /tmp -10.192.0.0/16(rw,no_root_squash,insecure,anonuid=222,anongid=103) ^ Ez mi? -' At mcedit-ből másoltam ki, az egy tabulátor. cat /proc/nfsd/exports mit mond (ha kernel szervert használsz)? Most éppen user szerver van fenn, mert próbáltam így is, de egyik sem megy. _ 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: NFS probléma
Pápai Balázs írta: Sziasztok! Van egy problémám az NFS-el és nem tudok zöldágra vergődni vele. Két hasonló Debian Lenny alatt teljesen jól működik az oda installált NFS szerver. A megosztások teljesen jól elérhetőek, használhatóak. Van viszont egy drbd-s cluster, (drbd8, heartbeat a disztribúció eszközeivel megvalósítva) ahol az nfs szerver nem akar egyáltalán működni. A távolról kezdeményezett mount: mount: clteszt1:/tmp failed, reason given by server: Hozzáférés megtagadva ugyanez szerveroldalon: clteszt1 mountd[3562]: NFS mount of /tmp attempted from 10.192.1.220 clteszt1 mountd[3562]: Unauthorized access by NFS client 10.192.1.220. clteszt1 mountd[3562]: Blocked attempt of 10.192.1.220 to mount /tmp a /etc/exports: /tmp -10.192.0.0/16(rw,no_root_squash,insecure,anonuid=222,anongid=103) (Ez megegyezik a többi gépen működő megosztással.) A gép kernele: 2.6.26-2-686 a hiba nfs kervel és user serverrel is u.a. A névfeloldás oda vissza működik. Megakadtam, hogy mit nézzek még meg. Látszólag csak annyi a különbség, hogy egy clusteren használom, noha az nfs még nincs cluster funkcióban, csak a feltelepítés után ki szerettem volna próbálni, hogy működik-e. Minden tippet, ötletet szívesen látok és előre is köszönök. a 10.192.1.220 revdns-e rendben van? uid/gid rendben van? _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
