How does MySQL perform on a sunfire?
Posted by Ian Holsman
If you have been reading my previous entries the answer you will think is ‘not bloody well’.
After about 3 days of tuning we doubled the throughput, and got a much nicer picture, outperforming a x86-64 machine by 2.5 times in one case.
Thanks to Luojia Chen (Jenny) from Sun, Peter Zaitsev from Mysql, and Colm MacCárthaigh & Mads Toftum from the ASF.
oh.. the benchmark.. I nearly forgot ;-)
(Oh people..please link to the blog entry, and not the paper itself.. Thanks)
update: people were having issues downloading the PDF. so I placed a mirror of it here
the individual images will be made available here as will the config files in about 24 hours.
Great write up.
Hi there,
I don’t run Sun so I cannot relate directly.
I do want to make my compliments regarding your article. It’s great!
It reads well, and is very informative. Great Graphs! Outstanding.
kind regards, Roland.
It seems like the server you’re linking to is not responding. Is there any mirror for your cool PDF report? :)
The T2000 side of things looks useful. But, I think you should correct some errors and omissions:
1. You say you are using 16 T1 processors on the T2000, which is impossible. You you really are using one 4-core T1.
2. (a) How did you measure the power requirements of the servers? In particular, HP claims that a single processor (dual core) DL385 only draws 244W, so I would expect a dual processor (single core) DL385 to draw around 300W, not 575W. (b) Could you post the price of the HP machine you used? I have previously priced a slightly faster HP385 at around $7,800.
3. On the final set of graphs, were all the tests on that line done with 1M rows? Is the x86-64 plot for MySQL 5.1.7 or 5.1.bk?
4. Did you do any memory utilization measurements during the tests? The results of your first test indicate that the 10K row test required way less than 2GB of memory, probably less than 1GB—otherwise, the MacBook would be swapping and would perform horribly. If the 1M row tests are not using a substantial percentage of the 8GB that the servers have available, then that would throw the numbers off a lot. The fact that you could run the load-generator on the same machine as MySQL indicates that there was plenty of memory not being utilized by MySQL.
5. How close to 100% utilization were the cores on the T1 and both processors on the X64 machine? Being able to run the load generator on the same box as the MySQL server is an indication that there are a lot of spare CPU cycles left over.
6. Is ”#threads” on the graph representing concurrent OLTP users? If so, that seems like too low of an upper bound for testing systems of this class.
7. Could you explain in more detail how the disks were configured? In particular, what filesystems were in use and were the disks striped or mirrored?
P.S. Make sure you read the rules for the contest very carefully, particularly regarding profanity, etc.
Hi Brian. Thanks for taking the time to review the benchmark.
here are my responses.
1. ok.. fair enough.. I just used the output of prdiag. I’m cool with it being 4…
2. a. I got it off HP’s website, which is down at the moment.. I double checked it said 545.. If you say it says 245.. OK.. I belive you. but I could have sworn it said 545… the only adjustment here is the SWaP metric. but even with the power difference it wouldn’t make the number better than the sunfire’s
b. I do not know the exact price of the machine (hence why it is omittied). Using HP’s calculator gives it at about $11k US. note.. I didn’t put the price of the sunfire that I was testing either.. just that the top of the range version was too expensive for me.
3. on the final set of graphs it is showing 1m row results. I mentioned on the front page that I did not build the ‘bk’ version on x86-64, and that the x86-64 were not tuned. ( Disclaimer we didn’t tune the x86-64 machine, I’m sure we could have made it go a lot faster as well, and we never built the ‘bleeding edge’ version on it either. )
4. I didn’t calculate if the 1m row table was large enough not to fit into memory. Judging by the x86-64’s performance I am guessing that it was larger than it’s memory. MySQL is reporting the average row length was 261. which makes the size about 200M overall. big enough to cache I’m thinking. I promised Peter Z I would re-run the 1m row tests on the HP box with ‘tuned’ mysql parameters.. I’ll do that shortly.
5. I was concious of having the load generator affect the test. The main reason why I chose to do it this way because I think it is a common configuration to have mysql run on the same machine as the application/webserver. I ran a benchmark to see how much affect this would have by running the load from a remote machine. I noticed some difference, but at the end of the day, it had the same contention. This may have been the reason why the PRIOCNTL test had a good result at the end of the tail… it was giving MySQL more processor time.
6. #threads running the test. From my observations, it was ‘game over’ at about thread 20 for all tests except the ‘bk’ one. What the tests are highlighting (pre-bk) is there is mutex-contention
7. Disks.. for the sunfire they were configured ‘out of the box’ no attempt was made to change disk layouts. The HP was raid5 I believe. I stopped after 9 pages of tests.. I wasn’t getting paid for this, and my paying clients were getting starved of my attention.
as for profanity? thanks for the tip.. are you talking about RTFM or ‘screwed’? I guess we are living in different cultures.. we’re you offended? If so I apolagize.
just finished running a ‘tuned’ x86-64 version. it basically puts the 1m row result along the same curve as the 10k row for the x86-64. I’ll update the paper shortly with this result, and the other things Brian pointed out.
basically it means I have to rewrite the exec summary for the 3rd time. (the 2nd time was after I ran the ‘bk’ version)
as for running more tests.. sorry.. I am flat out for the next month with exams, a house move, conferences and client work. If I have the machine past the try&buy period I’ll go into other options and try and see If I can figure out the bottlenecks
response time comparing a tuned x86-64 machine:
read/writes with a tuned x86-64 machine
my.cnf file http://media.zilbo.com/img/feh/mysql/my.cnf
#threads: If you look at your final graph (the one you posted in your comments), you can see that all the tests should responses fast enough for most people, even the 5.1.7/Niagara one. The graph seems to indicate that 5.1.bk would given sub-second response times through 50-100 concurrent threads on both servers, at least.
HP power usage: Were you using the power supply rating or the estimated power draw? The rating and the actual draw are totally different (550W rated vs. ~300W actual for Niagara, for example). I just reported the number I read off HP’s site: http://www.google.com/url?sa=t&;ct=res&cd=1&url=http%3A//h71028.www7.hp.com/ERC/cache/280124-0-0-0-121.html&ei=08o3RK3DG6HkqQLy-P3lBA&sig2=D3Tr8WImPbdCf0ZqIkx1sg http://h18004.www1.hp.com/products/servers/proliantdl385/cooling.html They have a calculator too (using Excel though): http://h30099.www3.hp.com/configurator/calc/Power%20Calculator%20Catalog.xls
profanity: No, I wasn’t offended. When I saw “RTFM/bitched/screwed” I thought it was odd since I got the link to the rules directly off your website.
the DL 385’s Power utilization was from here:HP Technical Specs
Power SupplyOutput Power (per power supply) Rated Steady-State Power 575W Maximum Peak Power 575WI think BTU’s are a better unit of measure, but SWaP wanted Watts.
HP DL 385 2508 BTU/HR Sunfire T20001365 BTU/HRsource: CMPNet Asia
regards Ian
OK.. PDF’s are updated with to reflect your comments Brian.
Thanks!