I finally got time to finish up the new version. Sorry for the lateness.
http://cdn.stardoll.com/cms/peter/segmented_keycache_v2.diff
Monday, August 10, 2009
Thursday, July 2, 2009
New version
A new version will be up in the next few days, just need some more time testing it first.
Fixes:
Overflow in statistics, no more wierd data every 2^32 key requests
Number of segments is a system variable instead of a compile time constant
Fixes:
Overflow in statistics, no more wierd data every 2^32 key requests
Number of segments is a system variable instead of a compile time constant
Tuesday, June 23, 2009
Dataset
And here is the script used to generate the dataset and queries to run these benchmarks:
http://cdn.stardoll.com/cms/peter/db_load.tar.gz
http://cdn.stardoll.com/cms/peter/db_load.tar.gz
Monday, June 22, 2009
Patch
As promised, rip it to shreds and tell me what I did wrong.
http://cdn.stardoll.com/segmented_keycache.diff
http://cdn.stardoll.com/segmented_keycache.diff
Wednesday, June 17, 2009
MySQL Performance with SSDs
During the last few weeks we have been trying out some different SSDs as storage for MySQL. The performance of some of these drives are just amazing, 3000 IOPS against a single drive is enough to make me happy atleast.
However, when MySQL runs on a very fast storage subsystem the performance is held back by issues in MySQL itself.
I spent some time profiling MySQL and prepared a quick fix, and thanks to Sun and Inserve, I got the chance to try it out and tweak it on some neat systems:
32 core X4600 with 64GB RAM
128 core M9000 with 224GB RAM
The datafiles are stored on a RAM drive (/dev/shm in Linux and /tmp in Solaris) for these tests and the load is running on the same server. This is to avoid potential IO bottlenecks as I'm interested in what MySQL can actually do given the resources.
The results:


Some more testing and I'll be ready to post the patch. Stay tuned.
However, when MySQL runs on a very fast storage subsystem the performance is held back by issues in MySQL itself.
I spent some time profiling MySQL and prepared a quick fix, and thanks to Sun and Inserve, I got the chance to try it out and tweak it on some neat systems:
32 core X4600 with 64GB RAM
128 core M9000 with 224GB RAM
The datafiles are stored on a RAM drive (/dev/shm in Linux and /tmp in Solaris) for these tests and the load is running on the same server. This is to avoid potential IO bottlenecks as I'm interested in what MySQL can actually do given the resources.
The results:


Some more testing and I'll be ready to post the patch. Stay tuned.
Subscribe to:
Comments (Atom)