Re: Migration 4.0 to 4.1 performance problem

2005-09-13 Thread Gleb Paharenko
Hello. Sometimes, after an upgrade it is necessary to rebuild indexes in the tables (I'm not sure if it always produces an error if you haven't done it). In general - usual recommendations for optimizing queries work in your case. Use the slow query log to find slow queries. Check if indexes

Migration 4.0 to 4.1 performance problem

2005-09-13 Thread Benjamin
Hi, I host a big french website including forum (phpbb), search engine (mnogo), album (smartor), blogs... around 780Mo in MySQL Everything work fine with my old configuration : - One SQL/mail server bi-Xeon, 2.6Ghz, 3Go : FC4, MySQL 4.0, Postfix-Mysql, Courier-imap Mysql - One front serve

RE: 4.1 performance

2004-07-15 Thread Hickey,Thom
inal Message- From: Sergei Golubchik [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 14, 2004 1:09 PM To: Lachlan Mulcahy Cc: [EMAIL PROTECTED] Subject: Re: 4.1 performance Hi! On Jul 14, Lachlan Mulcahy wrote: > > Sergei, Thom.. > > I am interested in seeing this thread followe

Re: 4.1 performance

2004-07-14 Thread Sergei Golubchik
Hi! On Jul 14, Lachlan Mulcahy wrote: > > Sergei, Thom.. > > I am interested in seeing this thread followed through. As developers at my > work have experienced similar performance issues between 3.23.x and 4. Our > database is also of similar size and a full optimize has been run. Could you pr

Re: FW: 4.1 performance

2004-07-14 Thread Sergei Golubchik
Hi! On Jul 14, Hickey,Thom wrote: > I was able to rerun my tests using mysqld (as opposed to safe_mysqld). I'm > happy to report that the times now almost exactly match MySQL 3.23.58. It's VERY strange. It cannot have any affect on the speed. Are you sure you run the correct version of mysqld ?

RE: 4.1 performance

2004-07-14 Thread Przemyslaw Popielarski
"Hickey,Thom" <[EMAIL PROTECTED]> wrote: > One thing that 4.1 is better at is speeding up repeated queries, ...thanks to query cache, introduced in 4.0.1. > so > for testing we're forced to run thousands of queries through the > system to avoid speed-ups across runs. SELECT SQL_NO_CACHE is pret

FW: 4.1 performance

2004-07-14 Thread Hickey,Thom
ystem to avoid speed-ups across runs. --Th --Th -Original Message- From: Lachlan Mulcahy [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 13, 2004 10:17 PM To: [EMAIL PROTECTED] Subject: RE: 4.1 performance Sergei, Thom.. I am interested in seeing this thread followed through

RE: 4.1 performance

2004-07-14 Thread Hickey,Thom
across runs. --Th --Th -Original Message- From: Lachlan Mulcahy [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 13, 2004 10:17 PM To: [EMAIL PROTECTED] Subject: RE: 4.1 performance Sergei, Thom.. I am interested in seeing this thread followed through. As developers at my work

RE: 4.1 performance

2004-07-13 Thread Lachlan Mulcahy
Golubchik [mailto:[EMAIL PROTECTED] Sent: Tuesday, 13 July 2004 8:11 PM To: Hickey,Thom Cc: [EMAIL PROTECTED] Subject: Re: 4.1 performance Hi! On Jul 12, Hickey,Thom wrote: > I've been comparing the performance of 4.1 with the MySQL 3.23.58 that came > with our Rocks cluster software. >

Re: 4.1 performance

2004-07-13 Thread Sergei Golubchik
Hi! On Jul 12, Hickey,Thom wrote: > I've been comparing the performance of 4.1 with the MySQL 3.23.58 that came > with our Rocks cluster software. > > I'm finding that 4.1 is running approximately 1/3 slower (e.g. a 0.075 > second query goes to 0.100 seconds) than 3.23.58. Size of buffers, etc.

4.1 performance

2004-07-12 Thread Hickey,Thom
I've been comparing the performance of 4.1 with the MySQL 3.23.58 that came with our Rocks cluster software. I'm finding that 4.1 is running approximately 1/3 slower (e.g. a 0.075 second query goes to 0.100 seconds) than 3.23.58. Size of buffers, etc. seems to have little effect. The database