Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 74F1C6337C5 for ; Thu, 14 Jan 2010 14:08:11 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 46827-02 for ; Thu, 14 Jan 2010 18:08:00 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mail.postgresql.org (Postfix) with ESMTP id 84C34632D2C for ; Thu, 14 Jan 2010 14:08:00 -0400 (AST) Received: from [192.168.1.3] (pool-96-244-14-10.bltmmd.fios.verizon.net [96.244.14.10]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MLC0j-1NVCzY4Azp-000XQS; Thu, 14 Jan 2010 19:07:49 +0100 Message-ID: <4B4F5D70.4020103@2ndquadrant.com> Date: Thu, 14 Jan 2010 13:07:44 -0500 From: Greg Smith User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Colson CC: Craig Ringer , pgsql-performance@postgresql.org Subject: Re: a heavy duty operation on an "unused" table kills my server References: <4B4D5698.8040808@emolecules.com> <4B4D61DA.7080008@postnewspapers.com.au> <603c8f071001130823l69804fe3m5c6fbb081c55c265@mail.gmail.com> <4B4EAD76.9030305@postnewspapers.com.au> <4B4F2F00.7070401@squeakycode.net> In-Reply-To: <4B4F2F00.7070401@squeakycode.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX19WXaNgt/Qr0B5WOvjITEuUqyfksb/+RcOjC+Y kVsRw5zkUA+xianYJAfiUXXxAAwEv7A7ZXfEZ3gyX0enhDjYHP ItcEJfpwjcPbhIIr3Uwds+OY69PpEla X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.589 tagged_above=-10 required=5 tests=BAYES_00=-2.599, FH_DATE_PAST_20XX=3.188 X-Spam-Level: X-Archive-Number: 201001/293 X-Sequence-Number: 37173 Andy Colson wrote: > On 1/13/2010 11:36 PM, Craig Ringer wrote: >> Yes. My 3ware 8500-8 on a Debian Sarge box was so awful that launching a >> terminal would go from a 1/4 second operation to a 5 minute operation >> under heavy write load by one writer. I landed up having to modify the >> driver to partially mitigate the issue, but a single user on the >> terminal server performing any sort of heavy writing would still >> absolutely nuke performance. > > On a side note, on linux, would using the deadline scheduler resolve > that? I've never seen the deadline scheduler resolve anything. If you're out of I/O capacity and that's blocking other work, performance is dominated by the policies of the underlying controller/device caches. Think about it a minute: disks nowadays can easily have 32MB of buffer in them, right? And random read/write operations are lucky to clear 2MB/s on cheap drivers. So once the drive is filled with requests, you can easily sit there for ten seconds before the scheduler even has any input on resolving the situation. That's even more true if you've got a larger controller cache in the mix. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com