Comments on: iiBench configuration http://tokutek.com/2008/12/iibench-configuration/ Database Performance Sat, 28 Aug 2010 12:16:29 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Peter Zaitsev http://tokutek.com/2008/12/iibench-configuration/comment-page-1/#comment-9 Peter Zaitsev Mon, 15 Dec 2008 02:36:36 +0000 http://blogs.tokutek.com/tokuview/iibench_configuration/#When:15:48:00Z#comment-9 Hm, If you're focusing on Inserts why changing so many different parameters which does not anything to do with Inserts. Also you would normally want different configurations for MyISAM and Innodb because they would compete for the same memory. Hm,

If you’re focusing on Inserts why changing so many different parameters which does not anything to do with Inserts.

Also you would normally want different configurations for MyISAM and Innodb because they would compete for the same memory.

]]> By: Bradley C. Kuszmaul http://tokutek.com/2008/12/iibench-configuration/comment-page-1/#comment-8 Bradley C. Kuszmaul Wed, 10 Dec 2008 18:15:52 +0000 http://blogs.tokutek.com/tokuview/iibench_configuration/#When:15:48:00Z#comment-8 We used a single set of mysql parameters for both InnoDB and MyISAM to avoid stopping and restarting the mysql server. Although the total memory allocated to both engines together exceeds the size of physical memory, we ran only one test at a time. Individually, each engine's allocation is less than the size of physical memory. Our thinking was that with only one engine running at a time, the working set would fit within physical memory. We ran InnoDB first, and then MyISAM, and each engine ran for at least two days, so the transition from working set to the other probably wasn't significant. My own expertise is in the underlying algorithms, rather than the specifics of MySQL parameter settings. For the contest, I would expect and encourage people to modify those settings to optimize performance. We used a single set of mysql parameters for both InnoDB and MyISAM to avoid stopping and restarting the mysql server. Although the total memory allocated to both engines together exceeds the size of physical memory, we ran only one test at a time. Individually, each engine’s allocation is less than the size of physical memory. Our thinking was that with only one engine running at a time, the working set would fit within physical memory. We ran InnoDB first, and then MyISAM, and each engine ran for at least two days, so the transition from working set to the other probably wasn’t significant. My own expertise is in the underlying algorithms, rather than the specifics of MySQL parameter settings. For the contest, I would expect and encourage people to modify those settings to optimize performance.

]]> By: Ronald Bradford http://tokutek.com/2008/12/iibench-configuration/comment-page-1/#comment-7 Ronald Bradford Sat, 06 Dec 2008 15:08:01 +0000 http://blogs.tokutek.com/tokuview/iibench_configuration/#When:15:48:00Z#comment-7 I'm curious. If this is your my.cnf for your iibench Contest, where you are inserting into a single table, why do you have innodb_buffer_pool_size and key_buffer_size set, splitting up your memory resources. The resultant table in your benchmark is one storage engine or the other. Unless you are doing something like a MyISAM table (given it's 8GB buffer), and then many InnoDB tables for additional seeding (you have plenty of innodb specific settings) I see no understand between your competition requirements and your settings. In addition, previous versions of MySQL crashed with a key_buffer_size > 4GB when accessing pointers above 4GB. I'm assuming this is no longer an issue in 5.1 I’m curious.

If this is your my.cnf for your iibench Contest, where you are inserting into a single table, why do you have innodb_buffer_pool_size and key_buffer_size set, splitting up your memory resources. The resultant table in your benchmark is one storage engine or the other.

Unless you are doing something like a MyISAM table (given it’s 8GB buffer), and then many InnoDB tables for additional seeding (you have plenty of innodb specific settings) I see no understand between your competition requirements and your settings.

In addition, previous versions of MySQL crashed with a key_buffer_size > 4GB when accessing pointers above 4GB. I’m assuming this is no longer an issue in 5.1

]]>