It’s a very complicated issue that I’ve been thinking about for a long time.

If you can get your data on SSD, and avoid caching altogether, these issues totally vanish.

The problem is that InnoDB/MySQL is not very good when you put it on an ultra-fast IO subsystem (as Peter mentioned).

All of our SSD tests were CPU bound in InnoDB. In a number of them MyISAM crushed SSD because it wasn’t using any CPU.

Hopefully some of the new performance patches will fix things but I think the data/IO path will need to be optimized.

We just simply didn’t have access to devices with these IO capabilities in the past…….

Kevin

I do not understand the reasoning behind this. With SSD, the advantage of doing sequential writes instead of random writes will be almost eliminated. Since one of the main motivations of log-based storage is to reduce the amount of random writes, I do not see how the log-based approach will make more sense with SSD.

Vote for these bugs:
http://bugs.mysql.com/bug.php?id=40603
http://bugs.mysql.com/bug.php?id=40604

Yes SSD and Flash in general will change landscape dramatically. Though I think of the Flash more than SSD – when you’re looking at Flash based systems it does not really make sense to go through the disk interface. Solutions connecting to the bus directly (such as FusionIO) are likely to be more interesting. And as you mention RAID – for the same reason there is less requirement for hot swap too

1) Getting rid of Buffer Pool is not going to happen even with SSD. Take a look at the code path for date in cache vs data on disk for Innodb (I have done work running MySQL on RAM drive and Violin Memory system)

2) Rate limiting makes sense. If you need to flush 10000 pages and do it as fast as possible you will see less bandwith available for reads and will see the dip in results. Though Innodb is doing it wrong. You can check DBT2 graph or any other flush intensive benchmarks and you will see dips still… because Innodb either flush not fast enough or starts flushing like a crazy and unable to do anything else. Adaptive and configurable limit would make much more sense (and this is what we’re doing in Percona patches)

Maria also does background LRU flushing (see http://forge.mysql.com/worklog/task.php?id=3261), but doesn’t have adaptive hash/insert buffer steps.

As for memory use – I’d have to show full profile (this one is a bit outdated and 4.0 based: http://noc.wikimedia.org/~midom/mem.pdf ), and indeed it may be possible to change that just by bumping up the page size (does anyone do that in production with nice results?). Last time I looked it was wasteful enough :)

It is possible to significantly shrink the per buffer cache page overhead from InnoDB, but that will take time. Is the current overhead really 2kb per page? I thought it was a few hundred bytes per page and the ratio is reduced if you boost the Innodb page size from 16kb to 32kb or 64kb.