Comments on: Missing Data – rows used to generate result set

By: peter

peter — Wed, 23 Jul 2008 03:08:34 +0000

Right. Speaking about spikes should not delayed flushing take care about this in most cases ?
Though I’ve seen the spikes and stalls waiting for flush too because of Innodb flush policy suboptimalities.

By: Mark Callaghan

Mark Callaghan — Tue, 22 Jul 2008 15:25:34 +0000

You can use more than 1 writer thread if you apply the Google patch. I doubt I am write bound like Kevin Burton, but there are spikes and I want concurrent writes for that case.

By: peter

peter — Tue, 22 Jul 2008 03:49:12 +0000

So some of you do not get to use fancy stuff but all of you get to run with same MySQL settings ?

I’m speaking about RAID with BBU rather than SAN. I’m not a big fan of SAN with MySQL. Generally when it comes to latency for single outstanding request, like logging for example SAN is going to be significantly slower than directly good RAID controller. Something which is not obviously to some people.

Speaking about expensive SAN and 1 thread doing all writes – it is 1 thread anyway, if you have O_DIRECT or not. True you get more outstanding requests because if OS buffers things and flushes in parallel but are you really so much write bound it is going to be the problem ?

By: Mark Callaghan

Mark Callaghan — Tue, 22 Jul 2008 03:08:01 +0000

Some of us don’t get to use fancy stuff like that. I also don’t get to use SAN. Is the problem worse there? I would be unhappy if I bought an expensive SAN and then watched 1 thread handle most writes to it.

By: peter

peter — Tue, 22 Jul 2008 02:54:49 +0000

With 32bit I can see it

With 64bit O_DIRECT can be slow in case writes can’t keep up… this however typically problem only for heavy writes and system without BBU. The RAID cards I’ve seen can take over 10.000 writes/sec to cache which is typically enough to take the write load.

By: Mark Callaghan

Mark Callaghan — Mon, 21 Jul 2008 19:03:58 +0000

We were using 32-bit builds until recently. Even with 64-bit builds, buffered IO has advantages. Unless you use the Google patch, dirty page writes can be slow because there is one background thread to handle them. One thread is sufficient for buffered IO because most writes to the buffer cache are fast.

By: peter

peter — Mon, 21 Jul 2008 18:46:55 +0000

Mark,

Yeah. thanks for info. Speaking about O_DIRECT very interesting you do not use it – did you discover any problems with it ?

By: peter

peter — Mon, 21 Jul 2008 18:46:10 +0000

Baron,

Indeed, something like that could work. Though I would also look at LIMIT carefully.

By: Mark Callaghan

Mark Callaghan — Mon, 21 Jul 2008 13:22:21 +0000

We use Linux 2.6 and clock_gettime from librt provides the CPU time. That library isn’t used by MySQL by default. Because of all difficulties of accounting for IO that you mention, I am not in a rush to count it. We use don’t use O_DIRECT, so many reads for InnoDB may only be from the OS buffer cache.

By: Baron Schwartz

Baron Schwartz — Mon, 21 Jul 2008 11:23:13 +0000

Peter, I think there need to be at least 2 new status variables: Filtered_by_where_clause and Filtered_by_having_clause.