10 messages in com.mysql.lists.bugsRe: Bug 712, 914..... and now 1027
FromSent OnAttachments
Paul Coldrey11 Aug 2003 00:42 
Alexander Keremidarski11 Aug 2003 03:35 
Alexander Keremidarski11 Aug 2003 18:43 
bki...@sola.com.au11 Aug 2003 22:09 
Sergei Golubchik12 Aug 2003 02:18 
Alexander Keremidarski12 Aug 2003 03:18 
Alexander Keremidarski12 Aug 2003 23:49 
Tabor J. Wells13 Aug 2003 07:04 
Jim Smith13 Aug 2003 07:18 
Alexander Keremidarski13 Aug 2003 09:11 
Subject:Re: Bug 712, 914..... and now 1027
From:Sergei Golubchik (se@mysql.com)
Date:08/12/2003 02:18:29 AM
List:com.mysql.lists.bugs

Hi!

On Aug 12, bki@sola.com.au wrote:

Alexander Keremidarski indicated that he can not repeat the issue bought to light by Paul's test case (bug #1027), yet he has not once attempted to run the test case on RedHat 7.3 (nor even on MySQL 4.0.14) which the bug report calls for as he considers testing performance issues between RedHat releases to be 'irrelevant'.

You are missing the point here. I was able to reproduce Paul's timings on my home FreeBSD-4.7 - same box - running 4.0.14 - same binary - with innodb_flush_log_at_trx_commit=0 and innodb_flush_log_at_trx_commit=1.

As Salle noted innodb_flush_log_at_trx_commit=0 is default settings before MySQL 4.0.13. Since 4.0.13 it's innodb_flush_log_at_trx_commit=1.

Irrelevant to whom I may ask? Certainly not irrelevant to those of us enjoying current performance on RH 7.3 who have now chosen to upgrade to RH 9.0. I would not consider an upgrade from MySQL 3.23.49, RedHat 7.3 to MySQL 4.0.14, RedHat 9.0 an unusual case, nor one where you would expect to get your fingers burned yet I have run the test case provided by Paul and quite easily reproduced the poor performance he has uncovered.

Irrelevant in this particular case - sorry it must be language problems, English is not my mother tongue, that's why I, probably, understand Salle better sometimes - means that you cannot base any judgements on this. There are results from two different hardware configurations, different my.cnf settings, different MySQL versions and different RedHat versions.

Any factor from the above can affect the results. According to my tests (as above) I suppose it was different default settings for innodb_flush_log_at_trx_commit.

Using identical hardware (previously a master/slave backup system) I ran BOTH test cases provided by Paul Coldrey on MySQL 3.23.49, RedHat 7.3 and MySQL 4.0.14, RedHat 9.0 and can verify that I received similar poor performance easily and repetedly.

Can you please confirm that your test results were NOT affected by innodb_flush_log_at_trx_commit settings ? (may be you had this variable set in your my.cnf ?)

Regards, Sergei

-- __ ___ ___ ____ __ / |/ /_ __/ __/ __ \/ / Sergei Golubchik <se@mysql.com> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Senior Software Developer /_/ /_/\_, /___/\___\_\___/ Osnabrueck, Germany <___/ www.mysql.com