tag:blogger.com,1999:blog-3043493300793589377.post1743104185323086365..comments2024-03-21T22:39:18.222-07:00Comments on Yoshinori Matsunobu's blog: Tables on SSD, Redo/Binlog/SYSTEM-tablespace on HDDYoshinori Matsunobuhttp://www.blogger.com/profile/14180479977952026421noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-3043493300793589377.post-31877402784913989422010-09-15T08:25:27.558-07:002010-09-15T08:25:27.558-07:00I have always wondered how to do a disk bound DBT-...I have always wondered how to do a disk bound DBT-2 benchmarking on SSD/HDD, but no one has been able to give me a hand, that's why I thank you for sharing this informative post!Sildenafil Citratehttp://www.citratesildenafil.com/noreply@blogger.comtag:blogger.com,1999:blog-3043493300793589377.post-29202244047383842162010-02-10T04:39:51.240-08:002010-02-10T04:39:51.240-08:00noop for all drives.noop for all drives.Yoshinori Matsunobuhttps://www.blogger.com/profile/14180479977952026421noreply@blogger.comtag:blogger.com,1999:blog-3043493300793589377.post-13843859566886635602010-02-09T18:46:38.207-08:002010-02-09T18:46:38.207-08:00I know this is a bit late, but did you say you use...I know this is a bit late, but did you say you used "noop" scheduler on all drives or just the ssd?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3043493300793589377.post-42674086232962470362009-08-05T10:36:05.812-07:002009-08-05T10:36:05.812-07:00Great Post.Great Post.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3043493300793589377.post-76228630098992465902009-05-15T21:26:00.000-07:002009-05-15T21:26:00.000-07:00Peter,
For insert-mostly applications, yes, seque...Peter,<br /><br />For insert-mostly applications, yes, sequential access for insert buffer, random access for *ibd, so storing on HDD would make sense (I published this benchmarking result at the UC(http://assets.en.oreilly.com/1/event/21/Mastering%20the%20Art%20of%20Indexing%20Presentation.pdf , p.41)). When massive random reads happen on insert buffer (by read-write intensive applications), storing on SSD would be better of course, but at that time I assume just disabling insert buffer functionality would be much better. Interesting to do benchmarking..Yoshinori Matsunobuhttps://www.blogger.com/profile/14180479977952026421noreply@blogger.comtag:blogger.com,1999:blog-3043493300793589377.post-31872963105001775382009-05-15T12:40:00.000-07:002009-05-15T12:40:00.000-07:00Why would you store insert buffer on HDD ?
Do you...Why would you store insert buffer on HDD ? <br />Do you think it is accessed sequential enough (if you consider on demand merges)Unknownhttps://www.blogger.com/profile/09353474813952295044noreply@blogger.comtag:blogger.com,1999:blog-3043493300793589377.post-83494263786383177892009-05-15T10:28:00.000-07:002009-05-15T10:28:00.000-07:00Hi Peter,
I tested without RAID controller on SSD...Hi Peter,<br /><br />I tested without RAID controller on SSD (enabling drive cache intentionally).<br />Yes, for DBT-2, doublewrite buffer was by far the most massively written component of ibdata1. I prefer InnoDB to have options to store doublewrite buffer, insert buffer(or just disabling), and undo segments to separate files. Then I'll store doublewrite buffer (and insert buffer) on HDD, undo segments and others on SSD.Yoshinori Matsunobuhttps://www.blogger.com/profile/14180479977952026421noreply@blogger.comtag:blogger.com,1999:blog-3043493300793589377.post-36667269797654416212009-05-15T10:26:00.000-07:002009-05-15T10:26:00.000-07:00Hi Mark,
Yes, XFS does not prevent concurrent wri...Hi Mark,<br /><br />Yes, XFS does not prevent concurrent writes as long as using O_DIRECT, but ext* prevents as you mention. I assume it also applies to ext4 because it uses the same function generic_file_aio_write(), which locks inode's mutex internally. <br />But when using write cache on H/W raid controller, write/fsync finishes much quickly than disk read so I'm not sure this really causes performance problems on HDD. On SSD, Linux kernel <-> Raid controller bandwidth overhead becomes relatively higher, so serialized writes might cause bottlenecks. Personally I'm very interested in profiling Linux filesystem internals (i.e. profiling kernel mutex contentions such as i_mutex) though I'm not sure how to do it.Yoshinori Matsunobuhttps://www.blogger.com/profile/14180479977952026421noreply@blogger.comtag:blogger.com,1999:blog-3043493300793589377.post-75642061968675051582009-05-15T08:50:00.000-07:002009-05-15T08:50:00.000-07:00When you tried SSD did you try them with RAID cont...When you tried SSD did you try them with RAID controller (w cache) or without ? <br /><br />NVRAM cache in RAID is still much faster accepting writes than SSDs though general there are few RAID controllers which are capable of working well with SSD IO rates.<br /><br />I also would note in your benchmark (DBT2) you did not use undo segment whole a lot - the short transactions meant almost no writes to the undo segment is needed.<br /><br />I would expect the most optimal solution would be to move out double write buffer to the separate file all together and keep it on hard drive while keeping ibdata1 on SSDs <br /><br />Redo logs binary logs on HDD with BBU cache make a lot of sense.Unknownhttps://www.blogger.com/profile/09353474813952295044noreply@blogger.comtag:blogger.com,1999:blog-3043493300793589377.post-59327107663858907502009-05-15T07:55:00.000-07:002009-05-15T07:55:00.000-07:00ext-2, ext-3 and probably ext-4 use a per-inode lo...ext-2, ext-3 and probably ext-4 use a per-inode lock to prevent concurrent writes to a file. XFS does not do this. This is more of an issue when write latency is higher because the write cache in the drive has been disabled. The ext variants also hold a per-inode lock for part of the read request handling. This is less of an issue with innodb_file_per_table. But many benchmarks are limited to 1 or a few hot tables and it can be a big issue there.Mark Callaghanhttps://www.blogger.com/profile/09590445221922043181noreply@blogger.comtag:blogger.com,1999:blog-3043493300793589377.post-62544614913924673632009-05-12T10:55:00.000-07:002009-05-12T10:55:00.000-07:00Continue to blog frequently. I learn a lot from th...Continue to blog frequently. I learn a lot from this.Mark Callaghanhttps://www.blogger.com/profile/09590445221922043181noreply@blogger.comtag:blogger.com,1999:blog-3043493300793589377.post-82730827416275800342009-05-12T10:28:00.000-07:002009-05-12T10:28:00.000-07:00Please let me know your PBXT test resultsPlease let me know your PBXT test resultsUnknownhttps://www.blogger.com/profile/09649034225584240597noreply@blogger.comtag:blogger.com,1999:blog-3043493300793589377.post-13759354522519118752009-05-12T01:19:00.000-07:002009-05-12T01:19:00.000-07:00Very nice post! Thank youVery nice post! Thank youAnonymousnoreply@blogger.com