Comments on: Evaluating IO subsystem performance for MySQL Needs

By: josh vermette

josh vermette — Fri, 07 Nov 2008 02:01:52 +0000

holy cow thank you for this. You just helped me prove conclusively (and finally!) that a mysterious I/O problem was my host’s and not, as they claimed, bad code.

By: ostblog» Home News » Performancemessung mit SysBench

ostblog» Home News » Performancemessung mit SysBench — Sat, 09 Aug 2008 09:16:44 +0000

[...] Mysqlperformanceblog – evaluating-io-subsystem-performance-for-mysql-needs [...]

By: peter

peter — Tue, 05 Aug 2008 00:39:19 +0000

Writes can be slower with O_DIRECT if you do not have BBU. However it is often not that bad as log write will require single IO anyway and the optimization for dirty page flushes may not affect subjective performance because it is happening in background.

By: Patrick Lafontaine

Patrick Lafontaine — Mon, 04 Aug 2008 18:46:15 +0000

Very very interesting post! It help me a lot to find what cause a High IOwait problem, resulting poor performance. I was not familliar with SysBench and now I use it on every servers I manage. I love it.

I use RAID 10 with no BBU. Intense writing is slower on it than my old server with a single Disk, no raid. The performance also decreases when I tried O_DIRECT to flush the log so I switched back to the default. I didn’t try with BBU, but if I can’t get all the thing faster, i will try (and buy a battery).

By: How much overhead DRDB could cause ? | MySQL Performance Blog

How much overhead DRDB could cause ? | MySQL Performance Blog — Tue, 03 Jun 2008 06:17:14 +0000

[...] good RAID as I benchmarked you can be getting over 10000 req/sec in-cache write speed (and this is what a lot of transaction [...]

By: Osma Ahvenlampi

Osma Ahvenlampi — Mon, 31 Mar 2008 20:37:12 +0000

I’m glad you asked, Peter. Since the explanation is on the longish side, I just posted it on my blog at http://www.fishpool.org/post/2008/03/31/Optimizing-Linux-I/O-on-hardware-RAID. Would love to hear your comments.

By: peter

peter — Mon, 31 Mar 2008 04:00:27 +0000

Osma,

What are you comparing ? System without BBU to system with BBU ? Why would it cause performance degradation even if what you’re describing would take place ?

What RAID did you tested ? Normally you will have TCQ or similar enabled so there is multiple of outstanding command issued to device.

By: Osma Ahvenlampi

Osma Ahvenlampi — Sat, 29 Mar 2008 13:53:08 +0000

My experience is that with a BBU on a RAID unit (whether controller or disk stack), the cfq elevator comes with a ~20% performance penalty. Why? Because unless you’re exposing the spindles to the OS one-by-one (or in RAID-1 pairs striped with MD/LVM), you’re having cfq order all the random reads/writes to the disk within one I/O queue, practically guaranteeing only a maximum of two, perhaps three of your n spindles is performing any useful work.

The noop scheduler, on the other hand, lets the requests go to the RAID (and BBU cache in the case of writes) in random order, letting it utilize all spindles to their best effect.

By: Federico Feroldi’s blog » Blog Archive » links for 2008-03-06

Federico Feroldi’s blog » Blog Archive » links for 2008-03-06 — Thu, 06 Mar 2008 20:19:37 +0000

[...] Evaluating IO subsystem performance for MySQL Needs | MySQL Performance Blog ‘m often asked how one can evaluate IO subsystem (Hard drive RAID or SAN) performance for MySQL needs so I’ve decided to write some simple steps you can take to get a good feeling about it, it is not perfect but usually can tell you quite a lot of what yo (tags: benchmark database disk mysql performance storage sysadmin io) [...]

By: peter

peter — Thu, 06 Mar 2008 20:18:52 +0000

Mark,

Exactly same number is strange as it varied even for me between runs. Being close however can be explained – for example we can come to the latency of PCI bus or something similar.

Right read cache should be normally off for MySQL – you want to save your RAID cache for writes.