• Competitor rules

    Please remember that any mention of competitors, hinting at competitors or offering to provide details of competitors will result in an account suspension. The full rules can be found under the 'Terms and Rules' link in the bottom right corner of your screen. Just don't mention competitors in any way, shape or form and you'll be OK.

Xeon mysql performance

kwerk

kwerk

kwerk

Wise Guy
Soldato
Joined
23 May 2009
Posts
5,748
Does anyone know how these 2 CPUs would compare on a dedicated mysqld server?

Xeon Quadcore E3-1270 v2 3.5ghz
8M cache
4 cores, 8 threads

vs

Dual CPU six-core Xeon E5-2620 2ghz
15M cache
2x 6 cores, 12 threads

The first is what i currently use and it is nearly maxed out on the CPU. The second set up would cost 3x the price, but I want to know how much better it would work as a database server.

If the first was running at say 75% cpu load what would the equivalent percent be on the second set up?
 
If you're not maxing out the E3-1270 why would you need a dual Xeon setup?

Your question is probably far too specific for anyone to give you an accurate answer.
 
You're just asking people to guess. To get a vaguely informed guess you need to provide detail on the nature of the database.

Its size
Type (basic purpose)
Transactions per second (average & peak)
Number of users (average & peak)
Target response time
Growth prediction (scalability requirements)
etc
 
Well I was wondering if it's as simple as 8x 3.5ghz vs 24 x 2ghz. I'm not up to speed on cores and threads and everything. No disk access is involved. The db queries would be spread over the cores/threads. So if now 8x 3.5G threads hit 80% on all of them, on the new one 24x 2G threads would hit 50% at the same load, roughly speaking?

This is what it looks like half of the time

Code: 
Cpu0  : 59.7%us,  0.3%sy,  0.0%ni, 37.6%id,  2.3%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  : 75.9%us,  0.3%sy,  0.0%ni, 23.4%id,  0.3%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  : 70.3%us,  0.7%sy,  0.0%ni, 26.3%id,  2.3%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu3  : 74.5%us,  0.7%sy,  0.0%ni, 24.2%id,  0.0%wa,  0.0%hi,  0.7%si,  0.0%st
Cpu4  : 52.2%us,  0.3%sy,  0.0%ni, 47.5%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  : 69.3%us,  0.3%sy,  0.0%ni, 29.3%id,  1.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu6  : 68.8%us,  0.7%sy,  0.0%ni, 30.2%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu7  : 67.9%us,  0.7%sy,  0.0%ni, 31.1%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
 
Mysql its self is multithreaded and if you're queries are splitting properly then my rough prediction is that you will get better overall performance from the E5's. Can't be much more precise than that I'm afraid, to many unknowns RE your database.
 
I think you'd be better off with 2x e3-1270 personally speaking, bear in mind that the e5s are only clocked half as fast. That is, if you can get them.
 
I would pick up a decent 'ES' Xeon E5 from somewhere.. If you look around you can get some awesome CPU's that are the same but just ES and they cost a fraction of the RRP of a Xeon...
 
I would not throw hardware at the problem .... Sack kwerk and get someone in who knows how to identify the core MySQL bottleneck and come up with a solution to scale horizontally.

Then sack the replacement as we migrate everything over to something NoSQL based :D

@kwerk This is a stop gap solution and you know it
 
Last edited:
Wucked said:
You're just asking people to guess. To get a vaguely informed guess you need to provide detail on the nature of the database.

Its size
Type (basic purpose)
Transactions per second (average & peak)
Number of users (average & peak)
Target response time
Growth prediction (scalability requirements)
etc
Click to expand...

Wucked said:
Mysql its self is multithreaded and if you're queries are splitting properly then my rough prediction is that you will get better overall performance from the E5's. Can't be much more precise than that I'm afraid, to many unknowns RE your database.
Click to expand...


The obvious ones missing that applies to both of these statements is what version of MySQL, and how is the data being accessed?

Old versions of MySQL (4.1/5.0/5.1) tend to scale poorly on multithreaded systems, unless proper analysis and restructuring takes place to avoid deadlock situations. As I understand it 5.5/5.6 improves the multithreading greatly, by making it less likely for deadlock situations to occur.

Depending on your front ends application as well, chucking away faster cores for more cores isn't necessarily the answer.

An ODBC based app we use at work linked against MySQL, works much better on a small number of faster clocked cores, as our ODBC app doesn't scale very well. Better to get a query returned faster, and then process the next one, rather than have multiple queries all running slower, and pushing the bottleneck to other areas, such as RAM and Disk performance (e.g. in the OP example, moving from 8 threads to 24, potentially means you could be tripling the disk performance requirement)
 
You must log in or register to reply here.
Back
Top Bottom