X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 7F6649FA501 for ; Mon, 19 Jun 2006 03:12:23 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 82005-02 for ; Mon, 19 Jun 2006 03:12:14 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from gw.proximity.com.au (147-68-185-210.static.techex.net.au [210.185.68.147]) by postgresql.org (Postfix) with ESMTP id D3CB39FA19B for ; Mon, 19 Jun 2006 03:12:13 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by gw.proximity.com.au (Postfix) with ESMTP id 833131F2CAD; Mon, 19 Jun 2006 16:12:10 +1000 (EST) Received: from gw.proximity.com.au ([127.0.0.1]) by localhost (gw [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07464-09; Mon, 19 Jun 2006 16:12:07 +1000 (EST) Received: from [192.168.128.103] (bee.proximity.com.au [192.168.128.103]) by gw.proximity.com.au (Postfix) with ESMTP id AFFA61FD48A; Mon, 19 Jun 2006 16:12:07 +1000 (EST) Message-ID: <44964037.6060605@proximity.com.au> Date: Mon, 19 Jun 2006 16:12:07 +1000 From: Tim Allen User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Trout Cc: pgsql-performance@postgresql.org Subject: Re: SAN performance mystery References: <4491D61B.9040507@proximity.com.au> <449275A5.5090503@proximity.com.au> <922914D7-46ED-4623-905A-C56058551905@torgo.978.org> In-Reply-To: <922914D7-46ED-4623-905A-C56058551905@torgo.978.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at proximity.com.au X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200606/372 X-Sequence-Number: 19729 Jeff Trout wrote: > On Jun 16, 2006, at 5:11 AM, Tim Allen wrote: >> One curious thing is that some postgres backends seem to spend an >> inordinate amount of time in uninterruptible iowait state. I found a >> posting to this list from December 2004 from someone who reported >> that very same thing. For example, bringing down postgres on the >> customer box requires kill -9, because there are invariably one or >> two processes so deeply uninterruptible as to not respond to a >> politer signal. That indicates something not quite right, doesn't it? > > Sounds like there could be a driver/array/kernel bug there that is > kicking the performance down the tube. > If it was PG's fault it wouldn't be stuck uninterruptable. That's what I thought. I've advised the customer to upgrade their kernel drivers, and to preferably upgrade their kernel as well. We'll see if they accept the advice :-|. Tim -- ----------------------------------------------- Tim Allen tim@proximity.com.au Proximity Pty Ltd http://www.proximity.com.au/