Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 6A893633493 for ; Sun, 22 Mar 2009 17:17:49 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 57872-02 for ; Sun, 22 Mar 2009 17:17:41 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from westnet.com (westnet.com [216.187.52.2]) by mail.postgresql.org (Postfix) with ESMTP id 0B3AE6332EA for ; Sun, 22 Mar 2009 17:17:42 -0300 (ADT) Received: from westnet.com (localhost [127.0.0.1]) by westnet.com (8.14.0/8.14.0) with ESMTP id n2MKHeDC017317; Sun, 22 Mar 2009 16:17:40 -0400 (EDT) Received: from localhost (gsmith@localhost) by westnet.com (8.14.0/8.13.2/Submit) with ESMTP id n2MKHetu017314; Sun, 22 Mar 2009 16:17:40 -0400 (EDT) X-Authentication-Warning: westnet.com: gsmith owned process doing -bs Date: Sun, 22 Mar 2009 16:17:40 -0400 (EDT) From: Greg Smith X-X-Sender: gsmith@westnet.com To: "M. Edward (Ed) Borasky" cc: pgsql-performance@postgresql.org Subject: Re: "iowait" bug? In-Reply-To: Message-ID: References: User-Agent: Alpine 2.01 (GSO 1184 2008-12-16) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=AWL=0.000 X-Spam-Level: X-Archive-Number: 200903/319 X-Sequence-Number: 33241 On Fri, 20 Mar 2009, M. Edward (Ed) Borasky wrote: > I just discovered this on a LinkedIn user group: > http://bugzilla.kernel.org/show_bug.cgi?id=12309 I would bet there's at least 3 different bugs in that one. That bug report got a lot of press via Slashdot a few months ago, and it's picked all sort of people who all have I/O wait issues, but they don't all have the same cause. The 3ware-specific problem Laurent mentioned is an example. That's not the same thing most of the people there are running into, the typical reporter there has disks attached directly to their motherboard. The irony here is that #12309 was a fork of #7372 to start over with a clean discussion slat because the same thing happened to that earlier one. The original problem reported there showed up in 2.6.20, so I've been able to avoid this whole thing by sticking to the stock RHEL5 kernel (2.6.18) on most of the production systems I deal with. (Except for my system with an Areca card--that one needs 2.6.22 or later to be stable, and seems to have no unexpected I/O wait issues. I think this is because it's taking over the lowest level I/O scheduling from Linux, when it pushes from the card's cache onto the disks). Some of the people there reported significant improvement by tuning the pdflush tunables; now that I've had to do a few times on systems to get rid of unexpected write lulls. I wrote up a walkthrough on one of them at http://notemagnet.blogspot.com/2008/08/linux-write-cache-mystery.html that goes over how to tell if you're running into that problem, and what to do about it; something else I wrote on that already made it into the bug report in comment #150. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD