Comments on: Tokyo Tyrant – The Extras Part II : The Performance Wall http://www.mysqlperformanceblog.com/2009/11/11/tokyo-tyrant-the-extras-part-ii-the-performance-wall/ Percona's MySQL & InnoDB performance and scalability blog Sat, 11 Feb 2012 16:45:54 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: kenny http://www.mysqlperformanceblog.com/2009/11/11/tokyo-tyrant-the-extras-part-ii-the-performance-wall/comment-page-1/#comment-675930 kenny Thu, 12 Nov 2009 03:40:04 +0000 http://www.mysqlperformanceblog.com/?p=1662#comment-675930 hello， there is a problem troubles me so long. Why the size of a InnoDB page is 16k？ As the page size of system is 4k. If the InnoDB page is also 4k, perhaps system io can be reduce? As we know that InnoDB wirtes a least a whole page whenever it writes. But I think there must be more advantages for the setting. Can pls tell me why or how to find the answer. Much thanks. hello， there is a problem troubles me so long.
Why the size of a InnoDB page is 16k？

As the page size of system is 4k.
If the InnoDB page is also 4k, perhaps system io can be reduce?
As we know that InnoDB wirtes a least a whole page whenever it writes.

But I think there must be more advantages for the setting.
Can pls tell me why or how to find the answer.
Much thanks.

]]> By: matt http://www.mysqlperformanceblog.com/2009/11/11/tokyo-tyrant-the-extras-part-ii-the-performance-wall/comment-page-1/#comment-675741 matt Wed, 11 Nov 2009 20:57:39 +0000 http://www.mysqlperformanceblog.com/?p=1662#comment-675741 @herodiade, I think your correct, the only difference is how the kernel handles mmaped files... i have looked for details but have not found out, so I need to put together a test to research this further. I think what's happening here is all the writes that exceed the allocated cabinet memory are hitting the FS cache, where the kernel takes care of these in the background. This means very little slowdown in the write process when cabinet flushes dirty pages to make room for new pages. Mounting the FS as sync means we are writing directly to disk, so each new page read into memory requires a page to be written to disk, which slows this down to a crawl. Adding more memory means there is a great change the record I am changing is already in memory. These tests are the based on the benchmark I put together for my first tests. Each transaction does two reads and one write. @herodiade,

I think your correct, the only difference is how the kernel handles mmaped files… i have looked for details but have not found out, so I need to put together a test to research this further. I think what’s happening here is all the writes that exceed the allocated cabinet memory are hitting the FS cache, where the kernel takes care of these in the background. This means very little slowdown in the write process when cabinet flushes dirty pages to make room for new pages. Mounting the FS as sync means we are writing directly to disk, so each new page read into memory requires a page to be written to disk, which slows this down to a crawl. Adding more memory means there is a great change the record I am changing is already in memory.

These tests are the based on the benchmark I put together for my first tests. Each transaction does two reads and one write.

]]> By: herodiade http://www.mysqlperformanceblog.com/2009/11/11/tokyo-tyrant-the-extras-part-ii-the-performance-wall/comment-page-1/#comment-675651 herodiade Wed, 11 Nov 2009 18:58:23 +0000 http://www.mysqlperformanceblog.com/?p=1662#comment-675651 This is strange because afaik most linux filesystems do flush dirty pages every 5 second per default (commit kernel param) unless sync syscall or mount option. So with "NoSync: 31 MB/s" we should expect 5*31 + small overhead would be enough to keep all writes in dirty buffers for a whole pdflush cycle, and then 512MB should be enough to handle the load exactly as 1024MB would, no? Or... what /proc/sys/vm/dirty_ratio value did you use for this test? Though "I use 256M of memory and run my test with writes going directly to disk" confuses me a lot; are you saying that the second test ran sync too? (if so I don't understand why memory size do impact results); or are you measuring read perfs in this second test? or mixed r+w with w being sync? But I guess the question ("As your data grows does Tokyo Cabinet slow down") was probably more about read performances than write performances, wasn't it? Maybe justing testing reads (on different keys) after a cache purge (like sync && echo 3 > /proc/sys/vm/drop_caches) would show worst case (similar to when a very small proportion of data do fit in kernel buffers and everything is retrieved from disk) for read perfs? This is strange because afaik most linux filesystems do flush dirty pages
every 5 second per default (commit kernel param) unless sync syscall
or mount option. So with “NoSync: 31 MB/s” we should expect 5*31 + small
overhead would be enough to keep all writes in dirty buffers for a whole
pdflush cycle, and then 512MB should be enough to handle the load exactly
as 1024MB would, no? Or… what /proc/sys/vm/dirty_ratio value did you
use for this test?

Though “I use 256M of memory and run my test with writes going directly to
disk” confuses me a lot; are you saying that the second test ran sync too?
(if so I don’t understand why memory size do impact results); or are you
measuring read perfs in this second test? or mixed r+w with w being sync?

But I guess the question (“As your data grows does Tokyo Cabinet
slow down”) was probably more about read performances than write
performances, wasn’t it?

Maybe justing testing reads (on different keys) after a cache purge
(like sync && echo 3 > /proc/sys/vm/drop_caches) would show worst
case (similar to when a very small proportion of data do fit in
kernel buffers and everything is retrieved from disk) for read perfs?

]]>