Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 65C7C2E005F for ; Tue, 15 Apr 2008 10:27:38 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 73319-04 for ; Tue, 15 Apr 2008 10:27:25 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by developer.postgresql.org (Postfix) with ESMTP id 59BF52E0057 for ; Tue, 15 Apr 2008 10:27:25 -0300 (ADT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1JllBt-0002Il-9R; Tue, 15 Apr 2008 15:27:17 +0200 Received: from fweimer by bfk.de with local id 1JllBw-0004Uu-4w; Tue, 15 Apr 2008 15:27:20 +0200 To: Jeff Cc: Albe Laurenz , Subject: Re: Performance increase with elevator=deadline References: From: Florian Weimer Date: Tue, 15 Apr 2008 15:27:20 +0200 In-Reply-To: (Jeff's message of "Fri, 11 Apr 2008 11:09:07 -0400") Message-ID: <82od8bi6yv.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200804/192 X-Sequence-Number: 29685 * Jeff: > Using 4 of these with a dataset of about 30GB across a few files > (Machine has 8GB mem) I went from around 100 io/sec to 330 changing to > noop. Quite an improvement. If you have a decent controller CFQ is > not what you want. I tried deadline as well and it was a touch > slower. The controller is a 3ware 9550sx with 4 disks in a raid10. > > I'll be trying this out on the big array later today. I found it > suprising this info wasn't more widespread (the use of CFQ on a good > controller). 3ware might be a bit special because the controller has got very deep queues on its own, so many assumptions of the kernel I/O schedulers do not seem to apply. Toying with the kernel/controller queue depths might help, but I haven't done real benchmarks to see if it's actually a difference. A few days ago, I experienced this: On a machine with a 3ware controller, a simple getxattr call on a file in an uncontended directory took several minutes because a PostgreSQL dump process was running in the background (and some other activity of a legacy database which caused frequent fdatasync calls). Clearly, this is unacceptable, and I've since switched to the deadline scheduler, too. So far, this particular behavior hasn't occurred again. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99