Comments on: The #1 mistake hosting providers make for MySQL servers http://www.mysqlperformanceblog.com/2008/07/25/the-1-mistake-hosting-providers-make-for-mysql-servers/ Everything about MySQL Performance Sat, 07 Nov 2009 18:35:44 -0800 http://wordpress.org/?v=2.8.4 hourly 1 By: Baron Schwartz http://www.mysqlperformanceblog.com/2008/07/25/the-1-mistake-hosting-providers-make-for-mysql-servers/comment-page-1/#comment-349217 Baron Schwartz Tue, 26 Aug 2008 13:35:51 +0000 http://www.mysqlperformanceblog.com/?p=445#comment-349217 I mean it was unnecessary if the OS had been 64-bit to start with. If you have to upgrade now, you have to either shut down your server for the upgrade (downtime) or you need another server to avoid downtime. I mean it was unnecessary if the OS had been 64-bit to start with. If you have to upgrade now, you have to either shut down your server for the upgrade (downtime) or you need another server to avoid downtime.

]]> By: Vincent Theeten http://www.mysqlperformanceblog.com/2008/07/25/the-1-mistake-hosting-providers-make-for-mysql-servers/comment-page-1/#comment-349215 Vincent Theeten Tue, 26 Aug 2008 13:34:16 +0000 http://www.mysqlperformanceblog.com/?p=445#comment-349215 >> Then they call us and we help them go through the rather unnecessary process of buying another server so they can juggle data back and forth to upgrade without downtime. @Baron: Can you explain how one can get the advantages of a 64bit server without "the rather unnecessary process of buying another server". We seem have outgrown our 32bit setup as well. Any advise is greatly appreciated >> Then they call us and we help them go through the rather unnecessary process of buying another server so they can juggle data back and forth to upgrade without downtime.

@Baron:
Can you explain how one can get the advantages of a 64bit server without “the rather unnecessary process of buying another server”. We seem have outgrown our 32bit setup as well. Any advise is greatly appreciated

]]> By: Baron Schwartz http://www.mysqlperformanceblog.com/2008/07/25/the-1-mistake-hosting-providers-make-for-mysql-servers/comment-page-1/#comment-339067 Baron Schwartz Sat, 02 Aug 2008 13:18:16 +0000 http://www.mysqlperformanceblog.com/?p=445#comment-339067 If you're not using InnoDB, your concurrency on that single table is very limited, so you will effectively run only one query at a time. If you’re not using InnoDB, your concurrency on that single table is very limited, so you will effectively run only one query at a time.

]]> By: Stefan A http://www.mysqlperformanceblog.com/2008/07/25/the-1-mistake-hosting-providers-make-for-mysql-servers/comment-page-1/#comment-339014 Stefan A Sat, 02 Aug 2008 10:15:48 +0000 http://www.mysqlperformanceblog.com/?p=445#comment-339014 Your quess is very close: I'm using MySQL (no joke!) Thanks for the offer, I new I will meet experts here. I'll come back on this, in case I'm in real trouble. Currently, I can go with the 25% as my tests are topping the demmand by 50... I'm just interested, why it is like this, so I don't want to invest Money, now. I'm running several Perl scripts. - one is inserting lots of sets in table1 with a name and a date field - one is adding into sets of table1 (oldest set first at 30/s) (this will not show more MySQL usage, but opens a second perl by about 25% - I have to check the waitings in this script) - one is creating a set in table2 if not already available for that name (Currently about 350/s having 17% Mysql and 8% Perl) - the same is looking up table1 and if a math over three fields comes to a result higher than x, than it adds the result into an other table2 (this will do the job up to 150/s, while the Update job is doing 200/s - and an other job is closing sets in table2, if an maximum amount is reached (some...) As i mentioned: no joins! every perl is reading from one table, updating the current set in this table and is bossibly updating/inserting into the other table... These does not look like single queries.... There must be something else. Your quess is very close: I’m using MySQL (no joke!)

Thanks for the offer, I new I will meet experts here.
I’ll come back on this, in case I’m in real trouble. Currently, I can go with the 25% as my tests are topping the demmand by 50… I’m just interested, why it is like this, so I don’t want to invest Money, now.

I’m running several Perl scripts.
- one is inserting lots of sets in table1 with a name and a date field
- one is adding into sets of table1 (oldest set first at 30/s) (this will not show more MySQL usage, but opens a second perl by about 25% – I have to check the waitings in this script)
- one is creating a set in table2 if not already available for that name (Currently about 350/s having 17% Mysql and 8% Perl)
- the same is looking up table1 and if a math over three fields comes to a result higher than x, than it adds the result into an other table2 (this will do the job up to 150/s, while the Update job is doing 200/s
- and an other job is closing sets in table2, if an maximum amount is reached (some…)

As i mentioned: no joins! every perl is reading from one table, updating the current set in this table and is bossibly updating/inserting into the other table…

These does not look like single queries….
There must be something else.

]]> By: Baron Schwartz http://www.mysqlperformanceblog.com/2008/07/25/the-1-mistake-hosting-providers-make-for-mysql-servers/comment-page-1/#comment-338714 Baron Schwartz Fri, 01 Aug 2008 18:42:27 +0000 http://www.mysqlperformanceblog.com/?p=445#comment-338714 Hmmm, let me guess. You have 4 cores, and the CPU is at 25%. That means 1 core is at 100% utilization. I've got it! You must be using MySQL! Joking aside: MySQL doesn't parallelize a single query across multiple cores. If you want help getting better performance out of this hardware, we're happy to help: submit the contact form on www.percona.com. Or you can just buy our book. There's a link at the top right of the page. Hmmm, let me guess. You have 4 cores, and the CPU is at 25%. That means 1 core is at 100% utilization.

I’ve got it! You must be using MySQL!

Joking aside: MySQL doesn’t parallelize a single query across multiple cores. If you want help getting better performance out of this hardware, we’re happy to help: submit the contact form on http://www.percona.com. Or you can just buy our book. There’s a link at the top right of the page.

]]> By: Stefan A http://www.mysqlperformanceblog.com/2008/07/25/the-1-mistake-hosting-providers-make-for-mysql-servers/comment-page-1/#comment-338710 Stefan A Fri, 01 Aug 2008 18:37:12 +0000 http://www.mysqlperformanceblog.com/?p=445#comment-338710 I'm running Mysql 64 from SUN coolstack on my Sun Solaris 10 x86 2*DualCore... Having some 400-700 reads and writes per second concurrently on different tables (no joins) using perl, the CPU is fixed to 25% and the rest is ideling.... OK perl is sometimes going th 25% too.... Where the hell do I have to tell the Software to use the hardware? I’m running Mysql 64 from SUN coolstack on my Sun Solaris 10 x86 2*DualCore…
Having some 400-700 reads and writes per second concurrently on different tables (no joins) using perl, the CPU is fixed to 25% and the rest is ideling…. OK perl is sometimes going th 25% too….

Where the hell do I have to tell the Software to use the hardware?

]]> By: Sergi http://www.mysqlperformanceblog.com/2008/07/25/the-1-mistake-hosting-providers-make-for-mysql-servers/comment-page-1/#comment-337632 Sergi Wed, 30 Jul 2008 21:42:57 +0000 http://www.mysqlperformanceblog.com/?p=445#comment-337632 No problem Baron. I hope one day we'll find the solution or at least change our cheap machines for better ones without that problem ;) No problem Baron. I hope one day we’ll find the solution or at least change our cheap machines for better ones without that problem ;)

]]> By: Baron Schwartz http://www.mysqlperformanceblog.com/2008/07/25/the-1-mistake-hosting-providers-make-for-mysql-servers/comment-page-1/#comment-337612 Baron Schwartz Wed, 30 Jul 2008 20:32:06 +0000 http://www.mysqlperformanceblog.com/?p=445#comment-337612 Sergi, I see now -- sorry I didn't read back through the comments again. I agree with Peter. Sorry you're having this trouble -- it has not happened to me, though. Sergi, I see now — sorry I didn’t read back through the comments again. I agree with Peter. Sorry you’re having this trouble — it has not happened to me, though.

]]> By: Sergi http://www.mysqlperformanceblog.com/2008/07/25/the-1-mistake-hosting-providers-make-for-mysql-servers/comment-page-1/#comment-337610 Sergi Wed, 30 Jul 2008 20:27:01 +0000 http://www.mysqlperformanceblog.com/?p=445#comment-337610 Baron, I'm not mixing. 32 bits OS/MySQL works fine both in dual and quad core machines. 64 bit OS/MySQL replicates correctly in my dual core machines, but fails in the quad core machines. That's why we think is a hardware bug. That and also because our hosting provider uses cheap SuperMicro machines. Baron, I’m not mixing. 32 bits OS/MySQL works fine both in dual and quad core machines. 64 bit OS/MySQL replicates correctly in my dual core machines, but fails in the quad core machines. That’s why we think is a hardware bug. That and also because our hosting provider uses cheap SuperMicro machines.

]]> By: Baron Schwartz http://www.mysqlperformanceblog.com/2008/07/25/the-1-mistake-hosting-providers-make-for-mysql-servers/comment-page-1/#comment-337544 Baron Schwartz Wed, 30 Jul 2008 17:41:32 +0000 http://www.mysqlperformanceblog.com/?p=445#comment-337544 Edwin, the limit may be a different number on 32-bit windows, but it's not over 4GB, because that's all a 32-bit pointer can address. Sergi, it sounds like you are mixing 64-bit vs 32-bit with dual-core vs. quad-core. They are different things. Richard, this isn't about our systems -- this is a warning to all people who might read this blog. They are the ones who get stuck with 32-bit systems. Then they call us and we help them go through the rather unnecessary process of buying another server so they can juggle data back and forth to upgrade without downtime. Edwin, the limit may be a different number on 32-bit windows, but it’s not over 4GB, because that’s all a 32-bit pointer can address.

Sergi, it sounds like you are mixing 64-bit vs 32-bit with dual-core vs. quad-core. They are different things.

Richard, this isn’t about our systems — this is a warning to all people who might read this blog. They are the ones who get stuck with 32-bit systems. Then they call us and we help them go through the rather unnecessary process of buying another server so they can juggle data back and forth to upgrade without downtime.

]]>