Bug 712, 914..... and now 1027

Hi Folks,

I've finally isolated the salient bug that led to report 712 (although
that report actually got a different bug fixed that I uncovered at the
same time). I think it is different to what the MySQL guys have found
with regards 914... hence there's another one called 1027 and thankfully
this time it appears to be REALLY easy to repeat!

http://bugs.mysql.com/bug.php?id=1027

Cheers,

Paul.


--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: Bug 712, 914..... and now 1027

Paul,

Paul Coldrey wrote:
> Hi Folks,
>
> I've finally isolated the salient bug that led to report 712 (although
> that report actually got a different bug fixed that I uncovered at the
> same time). I think it is different to what the MySQL guys have found
> with regards 914... hence there's another one called 1027 and thankfully
> this time it appears to be REALLY easy to repeat!

No. It is not only easy to repeat. This time it is meaningless.

You send Benchmark against 2 different versions of MySQL started on 2 different
servers - RedHat 7.3 vs RedHat 9.0 is quite big difference.

3.23.49 on RedHat 7.3 vs 4.0.14 on RedHat 9

You also didn't say a bit about configurations of both MySQL servers, not to
mention difference in hardware if any. Maybe you have tested it on same machine,
but you didn't say it in #1027

It has NOTHING in common with your previous Bug reports #712 and #914!
In both of them you have talked about speed of MyISAM INSERT speed.


In #1027 it is InnoDB INSERT speed. These are very different issues. There are
conditions when InnoDB INSERT can be slower by magnitude than MyISAM INSERT and
also cases when it can be much faster.

Sorry to say this, but providing such "Benchmark results" is incorrect to say the
least.


> http://bugs.mysql.com/bug.php?id=1027
>
> Cheers,
>
> Paul.
>
>

--
Are you MySQL certified? -> http://www.mysql.com/certification
For technical support contracts, visit https://order.mysql.com/?ref=msal
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Alexander Keremidarski
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time Developer
/_/ /_/\_, /___/\___\_\___/ Sofia, Bulgaria
<___/ www.mysql.com




--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: Bug 712, 914..... and now 1027

Paul,

Paul Coldrey wrote:
> Hi Alexander,


> The simple fact is that I have some code that runs really poorly on both
> MyISAM tables and InnoDB when using 4.0.14/RedHat 9.0 and runs quickly
> on 3.23.49/RedHat 7.3 - I believe the test case I have sent in will show
> this.... I think you should at least give it a try..... after all it's
> more than a 60x slow down, that's pretty hard to miss.

Can you please explain how this is supposed to be MySQL bug?

> I believe this is the main source of my problems, the fact that in
> tracking it down I have isolated two other bugs perhaps warrants some
> reflection.

What are these two other Bugs you have isolated? For #712 yes you did.

For #914 I can't agree you have provided repeatable test case which exposes any Bug.

You initially talked about "Slower INSERTs" which turned out into using bad
sequence of DELETE, INSERT, DELETE, INSERT which effectively prevents concurrent
SELECTs during INSERT. This is known, documented and easily avoidable limitation
of concurrent INSERTs with MyISAM tables.

http://www.mysql.com/doc/en/MyISAM.html
7.1 MyISAM Tables
....
You can INSERT new rows in a table that doesn't have free blocks in the middle of
the datafile, at the same time other threads are reading from the table
(concurrent insert). A free block can come from an update of a dynamic length row
with much data to a row with less data or when deleting rows. When all free blocks
are used up, all future inserts will be concurrent again.


> [24 Jul 5:32pm] Paul Coldrey
> ...
> . When permissions are rebuilt the insert in mysqlbug2 happens and insert around
> 120,000 rows. All these rows have the same SequenceId. Once the new permissions
> have been fully inserted the previous permissions (with a lower SequenceId) are
> deleted.


After that you switched to:


> [4 Aug 6:10am] Paul Coldrey
>
> As a quick update for anyone who may be working on this.... it appears the
> problem may be related to RedHat 9.0. Firstly I moved all the tables that might
> suffer from concurrency issues to InnoDB and this fixed some problems but the
> speed was still dismal.
>
> I then installed an old machine with RedHat 7.3 and did some tests with both
> 4.0.14 and 3.23.57. Performance is similar for both versions.


Later you wrote:

> [7 Aug 9:27pm] Paul Coldrey
> ...
> Sadly, (at least in the interests of getting this fixed!) from the command-line
> I couldn't replicate the problem! Hence, it's only slow when run from PHP 4.3.2
> on RedHat 9 with any MySQL 4.0 or 4.1.....

Later you provided vmstat output without where it came from - 3.23 on RH 7.3, 3.23
on RH9, 4.0 on RH7.3 or 4.0 on RH9


All you are saying so far in this Bug report is that MySQL is slower on RedHat 9
than on RedHat 7.3

Yes different versions of MySQL appears to run differently on different versions
of RedHat.

Please explain how can we consider this MySQL bug when none of your tests so far
can demonstrate degradation in speed between 3.23 and 4.0 when both are running
under same RedHat version?

Send us please test case which demonstrates difference in speed between
MySQL 3.23 under RedHat RedHat 7.3 and MySQL 4.0 under RedHat 7.3
and also test case which demonstrates difference in speed between
MySQL 3.23 RedHat 9 and MySQL 4.0 on RedHat 9

Anything else is irrelevant.

Test case you provided for #1027 runs at same speed when both 3.23 and 4.0 are
running under RedHat 9

Here it is:

3.23.58
date; mysql < inserts.sql; date
Tue Aug 12 04:28:32 EEST 2003
Tue Aug 12 04:28:45 EEST 2003

= 13 seconds

4.0.15
# date; mysql < inserts.sql; date
Tue Aug 12 04:32:03 EEST 2003
Tue Aug 12 04:32:18 EEST 2003

= 15 seconds

Considering that machine runs several other processes I don't agree this is
noticeable difference

Yes 4.0.15 appears to be slower, but not 60 times slower.

3.23.58
date; mysql < ./inserts.sh; date;

Tue Aug 12 04:33:41 EEST 2003
Tue Aug 12 04:34:50 EEST 2003
date; mysql < ./inserts.sh; date;

= 1 min 09 seconds

4.0.15
date; mysql < ./inserts.sh; date;

Tue Aug 12 04:38:01 EEST 2003
Tue Aug 12 04:39:11 EEST 2003

= 1 min 10 seconds



Please note that I don't say there is no such bug in MySQL! What I am saying is
that your report does not demonstrate how to repeat this bug.
Without being able to repeat it we can't test it nor we can fix it.


Note also that none of our binary is optimized for RedHat 9

RedHat 9 is only major Linux distribution so far which implements both NPTL and
LinuxThreads.

NPTL is neither stable nor standard yet. That is why we don't build NPTL-optmized
binaries. We can't afford doing this before we have tested NPTL thoroughly.

Best regards

--
Are you MySQL certified? -> http://www.mysql.com/certification
For technical support contracts, visit https://order.mysql.com/?ref=msal
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Alexander Keremidarski
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time Developer
/_/ /_/\_, /___/\___\_\___/ Sofia, Bulgaria
<___/ www.mysql.com




--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

RE: Bug 712, 914..... and now 1027

Like a lot of others I have been investigating the work involved in
migrating our company and clients servers to a MySQL 4.0 base due to MySQL
4.0's improved fulltext indexing and replication. But the recent issues
bought to my attention via the bug reports submitted by Paul Coldrey have
left me reconsidering my decision to upgrade and, indeed, reconsidering my
choice of open source database product.

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'.

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.

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.

Under MySQL 4.0.14, RedHat 9.0 both insert.sh and insert.sql took around 3
minutes and 30 seconds to insert 10,000 rows into an un-ndexed MyISAM table.

Under MySQL 3.23.49, RedHat 7.3 insert.sh took around 1 minute 30 seconds
while insert.sql took a mere 4 seconds.

Given the test cases insert a pitiful 10,000 rows into an un-indexed MyISAM
table which of the following does the MySQL team consider acceptable?

1) The 3 minutes 30 seconds I experienced under MySQL 4.0.14, RedHat 9.0 ?

2) The 1 minute 45 seconds Alexander Keremidarski experienced under MySQL
4.0, RedHat 9.0 ?

3) The 4 seconds I experienced under MySQL 3.23.49, RedHat 7.3 ?

As Alexander rightly points out Pauls test case demonstrates that MySQL
performs differently on different versions of RedHat which is
understandable. But what baffles me is why when such a marked DECREASE in
performance is bought to the attention of the MySQL developers is it
dismissed as an OS issue and investigated no further? Even if it is a
RedHat 9.0 issue it manifests itself most obviously in MySQL which will
leave the majority of users blaming MySQL for the bad performance.

Be it a MySQL issue, be it a Red Hat issue, whatever it is, isn't it
important to the MySQL developers to maintain performance on releases
regardless of operating system version? Its not like we're comparing RedHat
9.0 with Windows 98 here.

When my clients come to me asking to upgrade their servers what advice shall
I give? That the MySQL development team acknowledges that "different
versions of MySQL appear to run differently on different versions of RedHat"
but refuses to do anything about it so stick with MySQL 3.23.49 on RedHat
7.3????

In understand Paul Coldrey's frustration completely. This is an issue that
warrants serious attention and unless there is a solid commitment by the
MySQL development team to ensure no performance degradation between releases
regardless of operating system versions all of us who recommend MySQL
products to our clients are putting our reputation on the line each time we
do so ... and thats something I am not prepared to do.

Yes, different versions of MySQL do run differently on different versions of
RedHat. But when upgrading both MySQL and the OS one expects an increase
in, or similar performance not a decrease, and to say openly that is not an
issue is a slap in the face to all the developers who have loyally supported
your product over the years.

Byron Kidd.

-----Original Message-----
From: Alexander Keremidarski [mailto:salle@mysql.com]
Sent: Tuesday, 12 August 2003 11:14 AM
To: Paul Coldrey
Cc: bugs@lists.mysql.com
Subject: Re: Bug 712, 914..... and now 1027


Paul,

Paul Coldrey wrote:
> Hi Alexander,


> The simple fact is that I have some code that runs really poorly on both
> MyISAM tables and InnoDB when using 4.0.14/RedHat 9.0 and runs quickly
> on 3.23.49/RedHat 7.3 - I believe the test case I have sent in will show
> this.... I think you should at least give it a try..... after all it's
> more than a 60x slow down, that's pretty hard to miss.

Can you please explain how this is supposed to be MySQL bug?

> I believe this is the main source of my problems, the fact that in
> tracking it down I have isolated two other bugs perhaps warrants some
> reflection.

What are these two other Bugs you have isolated? For #712 yes you did.

For #914 I can't agree you have provided repeatable test case which exposes
any Bug.

You initially talked about "Slower INSERTs" which turned out into using bad
sequence of DELETE, INSERT, DELETE, INSERT which effectively prevents
concurrent
SELECTs during INSERT. This is known, documented and easily avoidable
limitation
of concurrent INSERTs with MyISAM tables.

http://www.mysql.com/doc/en/MyISAM.html
7.1 MyISAM Tables
....
You can INSERT new rows in a table that doesn't have free blocks in the
middle of
the datafile, at the same time other threads are reading from the table
(concurrent insert). A free block can come from an update of a dynamic
length row
with much data to a row with less data or when deleting rows. When all free
blocks
are used up, all future inserts will be concurrent again.


> [24 Jul 5:32pm] Paul Coldrey
> ...
> . When permissions are rebuilt the insert in mysqlbug2 happens and insert
around
> 120,000 rows. All these rows have the same SequenceId. Once the new
permissions
> have been fully inserted the previous permissions (with a lower
SequenceId) are
> deleted.


After that you switched to:


> [4 Aug 6:10am] Paul Coldrey
>
> As a quick update for anyone who may be working on this.... it appears the
> problem may be related to RedHat 9.0. Firstly I moved all the tables that
might
> suffer from concurrency issues to InnoDB and this fixed some problems but
the
> speed was still dismal.
>
> I then installed an old machine with RedHat 7.3 and did some tests with
both
> 4.0.14 and 3.23.57. Performance is similar for both versions.


Later you wrote:

> [7 Aug 9:27pm] Paul Coldrey
> ...
> Sadly, (at least in the interests of getting this fixed!) from the
command-line
> I couldn't replicate the problem! Hence, it's only slow when run from PHP
4.3.2
> on RedHat 9 with any MySQL 4.0 or 4.1.....

Later you provided vmstat output without where it came from - 3.23 on RH
7.3, 3.23
on RH9, 4.0 on RH7.3 or 4.0 on RH9


All you are saying so far in this Bug report is that MySQL is slower on
RedHat 9
than on RedHat 7.3

Yes different versions of MySQL appears to run differently on different
versions
of RedHat.

Please explain how can we consider this MySQL bug when none of your tests so
far
can demonstrate degradation in speed between 3.23 and 4.0 when both are
running
under same RedHat version?

Send us please test case which demonstrates difference in speed between
MySQL 3.23 under RedHat RedHat 7.3 and MySQL 4.0 under RedHat 7.3
and also test case which demonstrates difference in speed between
MySQL 3.23 RedHat 9 and MySQL 4.0 on RedHat 9

Anything else is irrelevant.

Test case you provided for #1027 runs at same speed when both 3.23 and 4.0
are
running under RedHat 9

Here it is:

3.23.58
date; mysql < inserts.sql; date
Tue Aug 12 04:28:32 EEST 2003
Tue Aug 12 04:28:45 EEST 2003

= 13 seconds

4.0.15
# date; mysql < inserts.sql; date
Tue Aug 12 04:32:03 EEST 2003
Tue Aug 12 04:32:18 EEST 2003

= 15 seconds

Considering that machine runs several other processes I don't agree this is
noticeable difference

Yes 4.0.15 appears to be slower, but not 60 times slower.

3.23.58
date; mysql < ./inserts.sh; date;

Tue Aug 12 04:33:41 EEST 2003
Tue Aug 12 04:34:50 EEST 2003
date; mysql < ./inserts.sh; date;

= 1 min 09 seconds

4.0.15
date; mysql < ./inserts.sh; date;

Tue Aug 12 04:38:01 EEST 2003
Tue Aug 12 04:39:11 EEST 2003

= 1 min 10 seconds



Please note that I don't say there is no such bug in MySQL! What I am saying
is
that your report does not demonstrate how to repeat this bug.
Without being able to repeat it we can't test it nor we can fix it.


Note also that none of our binary is optimized for RedHat 9

RedHat 9 is only major Linux distribution so far which implements both NPTL
and
LinuxThreads.

NPTL is neither stable nor standard yet. That is why we don't build
NPTL-optmized
binaries. We can't afford doing this before we have tested NPTL thoroughly.

Best regards

--
Are you MySQL certified? -> http://www.mysql.com/certification
For technical support contracts, visit https://order.mysql.com/?ref=msal
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Alexander Keremidarski

/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time Developer
/_/ /_/\_, /___/\___\_\___/ Sofia, Bulgaria
<___/ www.mysql.com




--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=bkidd@sola.com.au

--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: Bug 712, 914..... and now 1027

Hi!

On Aug 12, bkidd@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
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Senior Software Developer
/_/ /_/\_, /___/\___\_\___/ Osnabrueck, Germany
<___/ www.mysql.com

--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: Bug 712, 914..... and now 1027

Hello,

bkidd@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'.

Yes irrelevant.

I said TEST case is irrelevant, not Speed Difference Issue.

I also stated that if there is test which demonstrates difference in speed between
MySQL vresions running on same platform (OS + hardware) this is to be considered
MySQL problem.

Quoting my previous email:

> Send us please test case which demonstrates difference in speed between
> MySQL 3.23 under RedHat RedHat 7.3 and MySQL 4.0 under RedHat 7.3
> and also test case which demonstrates difference in speed between
> MySQL 3.23 RedHat 9 and MySQL 4.0 on RedHat 9

I insyst on fact that Benchmarking between different Versions of MySQL (actually
any software) runnign on different platforms (OS + Hardware) is irrelevant.

Benchmarking MySQL 3.23 on RedHat 7.3 against MySQL 4.0 on RedHat 9 is irrelevant.
Benchmarking MySQL 3.23 on RedHat 7.3 against MySQL 4.0 on RedHat 7.3 is relevant
as well as benchmarking MySQL 3.23 on RedHat 9 against MySQL 4.0 on RedHat 9

Add to above equation "with diffrent mysqld startup options". 3.23.49 and 4.0.14
have different default startup options.

> 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.
>
> Under MySQL 4.0.14, RedHat 9.0 both insert.sh and insert.sql took around 3
> minutes and 30 seconds to insert 10,000 rows into an un-ndexed MyISAM table.
>
> Under MySQL 3.23.49, RedHat 7.3 insert.sh took around 1 minute 30 seconds
> while insert.sql took a mere 4 seconds.


> Given the test cases insert a pitiful 10,000 rows into an un-indexed MyISAM
> table which of the following does the MySQL team consider acceptable?

I disagree. Paul Coldrey test case creates table as:

CREATE DATABASE BugMe3;
USE BugMe3;

CREATE TABLE GroupMemberLookup (
GroupId int(11) default NULL,
PersonId int(11) default NULL,
SequenceId int(11) default NULL,
KEY GroupId (GroupId),
KEY PersonId (PersonId),
KEY groupmemberlookup_sequenceid_i (SequenceId)
) TYPE=InnoDB;

Therefore it tests InnoDB INSERT speed not MyISAM test speed.

MyISAM INSERT speed and InnoDB INSERT speed are very different due to lot of
reasons. There are cases where one is faster than another and vice versa.


By the way it is important to run above test against MySQL-Max-3.23 as in 3.23
InnoDB is compiled only in Max releases while in 4.0 it is compiled in standard
releases too. There is one more huge difference. Max versions are dynamically
linked while standard are statically linked.

> 1) The 3 minutes 30 seconds I experienced under MySQL 4.0.14, RedHat 9.0 ?
>
> 2) The 1 minute 45 seconds Alexander Keremidarski experienced under MySQL
> 4.0, RedHat 9.0 ?
>
> 3) The 4 seconds I experienced under MySQL 3.23.49, RedHat 7.3 ?

We don't run same test under same conditions. 1) and 3) are comparable, 2) is not
comparable to any of 1) and 3).


> As Alexander rightly points out Pauls test case demonstrates that MySQL
> performs differently on different versions of RedHat which is
> understandable. But what baffles me is why when such a marked DECREASE in
> performance is bought to the attention of the MySQL developers is it
> dismissed as an OS issue and investigated no further? Even if it is a
> RedHat 9.0 issue it manifests itself most obviously in MySQL which will
> leave the majority of users blaming MySQL for the bad performance.
>
> Be it a MySQL issue, be it a Red Hat issue, whatever it is, isn't it
> important to the MySQL developers to maintain performance on releases
> regardless of operating system version? Its not like we're comparing RedHat
> 9.0 with Windows 98 here.

Yes it is important. No we don't have RedHat 9 tested well.

> When my clients come to me asking to upgrade their servers what advice shall
> I give? That the MySQL development team acknowledges that "different
> versions of MySQL appear to run differently on different versions of RedHat"
> but refuses to do anything about it so stick with MySQL 3.23.49 on RedHat
> 7.3????

Why 3.23.49? Why not benchmarking it against 4.0.14 on the very same RedHat 7.3?
Why not benchmarking it against current stable 3.23 which is 3.23.57?

Don't you take into consideration the fact that 3.23.49 is year and half old
release and there is bug amount of bugs fixed since then?

> In understand Paul Coldrey's frustration completely. This is an issue that
> warrants serious attention and unless there is a solid commitment by the
> MySQL development team to ensure no performance degradation between releases
> regardless of operating system versions all of us who recommend MySQL
> products to our clients are putting our reputation on the line each time we
> do so ... and thats something I am not prepared to do.

I also understand and share Paul Coldrey's frustration. I have spend lot of time
trying to pinpoint the problem, but so far I don't see anything which can help us
find what exactly is going wrong.

> Yes, different versions of MySQL do run differently on different versions of
> RedHat. But when upgrading both MySQL and the OS one expects an increase
> in, or similar performance not a decrease, and to say openly that is not an
> issue is a slap in the face to all the developers who have loyally supported
> your product over the years.

I don't agree with your point. Upgrading OS unfortunately in most cases slows down
machines as new versions are usually more demanding than old ones. True for Linux
distributions too. Yes upgrading from kernel 2.2 to kernel 2.4 improves your CPU
performance, but first thing you read is that 2.4 is more demanding to amount of
RAM and so on.

My personal experience shows that upgrading from RH 7.3 to RH 9 slows down all and
every program.
But this is just my impression. I have no tests to prove it.

Therefore I don't state that every program which slows down has bugs and it's
programmers must take it into consideration. I just assume that RedHat 9 is most
demanding to resources and this is something to live with.





Here are results of Paul Coldrey test case against 3.23.49, 3.23.57 and 4.0.15 on
same machine:


inserts.sh

mysql-max-3.23.49a 1 min 39 sec
mysql-max-3.23.57 1 min 40 sec

mysql-debug-4.0.15 1 min 5 sec

inserts.sql

mysql-max-3.23.49a 3.9 sec
mysql-max-3.23.57 3.3 sec

mysql-debug-4.0.15 3.9 sec

RedHat 9
kernel 2.4.20-19.9
CPU Intel(R) Pentium(R) 4 CPU 1.60GHz
528Mb RAM


As you see I can't repeat "degradation in speed between MySQL versions".


> Byron Kidd.

Best regards

--
Are you MySQL certified? -> http://www.mysql.com/certification
For technical support contracts, visit https://order.mysql.com/?ref=msal
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Alexander Keremidarski
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time Developer
/_/ /_/\_, /___/\___\_\___/ Sofia, Bulgaria
<___/ www.mysql.com




--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: Bug 712, 914..... and now 1027

Paul,


I have a proposal with regard of Bugs #914 and #1027

Your last comments to #1027 add valuable information. They correspond to my
experience with RedHat 7.3 -> 9 upgrade - old, slow machines run well while new
fast machines seem to work slower (at least feel like) sometimes much slower.

However MySQL relies completely on OS for file operations. There are no
optimizations against any specific filesystem.

If you agree with me that there is no problem with Upgrading MySQL itself on same
OS, but there IS serious degradation on RedHat 9 under some circumstances here is
proposed plan.

I will close both tickets #914 and #1027 as "duplicates" combining them into new
ticket.
If it turns out into SCSI or RAID or whatever filesystem or VM problem there is
no problem at MySQL side at all.

This new ticket I will open will be put into "Feature Request" category. It will
be based on your comments to #1027


> Can you guys out in MySQL-land test this on a RedHat 9, SCSI, software-RAID5
> machine?
>
> I'm hoping that your previous apparent ambivalence to this problem was due to a
> philosophical objection to my test case rather than an indifference to operating
> system bugs that manifest themselves in MySQL. It seems to me it would still be
> best if MySQL confirmed this problem and approach RedHat with suggestions about
> where the issue might lie. If you don't agree then let me know and I'll consider
> putting together a case for RedHat.

The reason of putting it into "Feature Request" is that there are two goals there

1. Investigate reported MySQL performance problems under RedHat 9
2. Provide MySQL binaries optimized for RedHat 9

I admit there is reason in doing it as RedHat 9 is huge step into *possible* Linux
future.

I hope you understand how big such task is for MySQL AB. It will involve different
departments and it will require changes in our binaries distribution policy. So
far we never had binaries optimized for specific version of specific Linux
distribution. My personal opinion is that doing it is wise only with close with OS
vendor.


Do you agree with this plan?

Best regards

--
Are you MySQL certified? -> http://www.mysql.com/certification
For technical support contracts, visit https://order.mysql.com/?ref=msal
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Alexander Keremidarski
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time Developer
/_/ /_/\_, /___/\___\_\___/ Sofia, Bulgaria
<___/ www.mysql.com




--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: Bug 712, 914..... and now 1027

On Wed, Aug 13, 2003 at 09:50:15AM +0300,
Alexander Keremidarski is thought to have said:

> The reason of putting it into "Feature Request" is that there are two goals
> there
>
> 1. Investigate reported MySQL performance problems under RedHat 9
> 2. Provide MySQL binaries optimized for RedHat 9
>
> I admit there is reason in doing it as RedHat 9 is huge step into
> *possible* Linux future.

It's more than that. At the end of this year RedHat is stopping errata
updates for versions < 9. See http://www.redhat.com/apps/support/errata/ for
details.

I'd like to see better RH9 support to be something that is a higher priority
than Feature Request because these EOL dates make running older versions of
RH much less attractive.

Tabor

--
------------------------------------------------------------ --------
Tabor J. Wells twells@fsckit.net
Fsck It! Just another victim of the ambient morality

--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

RE: Bug 712, 914..... and now 1027

> > I admit there is reason in doing it as RedHat 9 is huge step into
> > *possible* Linux future.
>
> It's more than that. At the end of this year RedHat is stopping errata
> updates for versions < 9. See
> http://www.redhat.com/apps/support/errata/ for
> details.
>
> I'd like to see better RH9 support to be something that is a
> higher priority
> than Feature Request because these EOL dates make running
> older versions of
> RH much less attractive.
>
Are we absolutely sure Microsoft don't have shares in RedHat?
>


--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: Bug 712, 914..... and now 1027

Hi,

Tabor J. Wells wrote:
> On Wed, Aug 13, 2003 at 09:50:15AM +0300,


> I'd like to see better RH9 support to be something that is a higher priority
> than Feature Request because these EOL dates make running older versions of
> RH much less attractive.

I can agree or disagree with you, but this is definitely not an issue for Bugs List.


MySQL AB provides binaries build and tested on different versions of (in
alphabetical order)

AIX, FreeBSD, HP-UX, Irix, Linux (sic!), MacOS X, NetWare, OSF, QNX, SCO, Solaris,
Windows

For Linux only we build MySQL binaries for 4 different platforms:
x86, SPARC, IA64 (Itanium), AMD64 (Opteron), S/390, Alpha

I don't dare to predict future, but the fact is nowadays RedHat is just one of
Linux distributions and Linux is just one of OS supported by MySQL.

> Tabor

Best regards

--
Are you MySQL certified? -> http://www.mysql.com/certification
For technical support contracts, visit https://order.mysql.com/?ref=msal
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Alexander Keremidarski
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time Developer
/_/ /_/\_, /___/\___\_\___/ Sofia, Bulgaria
<___/ www.mysql.com




--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org