Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 7FAD2B5DC33 for ; Mon, 5 Sep 2011 17:39:06 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 73637-02 for ; Mon, 5 Sep 2011 20:38:57 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from elizabeth.gransy.com (elizabeth.gransy.com [89.187.132.199]) by mail.postgresql.org (Postfix) with ESMTP id A3384B5DBC1 for ; Mon, 5 Sep 2011 17:38:57 -0300 (ADT) Received: from sq.gransy.com (localhost [127.0.0.1]) by elizabeth.gransy.com (Postfix) with ESMTP id 17A1A15E42EF; Mon, 5 Sep 2011 22:38:56 +0200 (CEST) Received: from 78.45.133.255 (SquirrelMail authenticated user tv@fuzzy.cz) by sq.gransy.com with HTTP; Mon, 5 Sep 2011 22:38:56 +0200 Message-ID: <3112082e07a5271c09b6b4435ed92385.squirrel@sq.gransy.com> In-Reply-To: <4E651DFE.805@squeakycode.net> References: <4E61D6B4.9090804@ai.wu.ac.at> <33fadeb6ac1bade5ef01bd08d1fd7807.squirrel@sq.gransy.com> <4E64D3D3.8000205@squeakycode.net> <4E64D7EA.3010704@ai.wu.ac.at> <4E651DFE.805@squeakycode.net> Date: Mon, 5 Sep 2011 22:38:56 +0200 Subject: Re: Sudden drop in DBb performance From: "Tomas Vondra" To: "Andy Colson" Cc: "Scott Marlowe" , "Gerhard Wohlgenannt" , "Tomas Vondra" , pgsql-performance@postgresql.org, "Heinz-Peter Lang" , "Gerhard Wohlgenannt" , "Weichselbraun, Albert" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201109/50 X-Sequence-Number: 44826 On 5 Září 2011, 21:07, Andy Colson wrote: > On 09/05/2011 01:45 PM, Scott Marlowe wrote: >> On Mon, Sep 5, 2011 at 8:08 AM, Gerhard Wohlgenannt >> wrote: >>> Below please find the results of vmstat 2 over some periode of time .. >>> with >>> normal database / system load. >>> > 2 1 1344204 240924 104156 31462484 350 0 1906 234 3687 4512 12 3 > 77 9 >> >> Your IO Wait is actually pretty high. On an 8 core machine, 12.5% >> means one core is doing nothing but waiting for IO. >> > > My server is 2-core, so these numbers looked fine by me. I need to > remember core count when I look at these. > > So the line above, for 2 core's would not worry me a bit, but on 8 cores, > it pretty much means one core was pegged (with 9% wait? Or is it one core > was pegged, and another was 72% io wait?) AFAIK it's as if one core was 72% io wait. Anyway that's exactly why I was asking for "iostat -x" because the util% gives a better idea of what's going on. > I have always loved the vmstat output, but its starting to get confusing > when you have to take core's into account. (And my math was never strong > in the first place :-) ) That's why I love dstat, just do this $ dstat -C 0,1,2,3,4,5,6,7 and you know all you need. > Good catch, thanks Scott. Yes, good catch. Still, this does not explain why the queries were running fast before, and why the RAID array is so sluggish. Not to mention that we don't know what were the conditions when collecting those numbers (were the VMs off or running?). Tomas