Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UMs5z-0007p8-F7 for pgsql-performance@arkaria.postgresql.org; Tue, 02 Apr 2013 03:41:15 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1UMs5y-0005Rg-VF for pgsql-performance@arkaria.postgresql.org; Tue, 02 Apr 2013 03:41:15 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UMs5y-0005Rb-9F for pgsql-performance@postgresql.org; Tue, 02 Apr 2013 03:41:14 +0000 Received: from [2404:130:0:10::40:2] (helo=mail.catalyst.net.nz) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UMs5u-0004e4-D6 for pgsql-performance@postgresql.org; Tue, 02 Apr 2013 03:41:13 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.catalyst.net.nz (Postfix) with ESMTP id 689B132C17; Tue, 2 Apr 2013 16:41:07 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at catalyst.net.nz Received: from mail.catalyst.net.nz ([127.0.0.1]) by localhost (bertrand.catalyst.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ovTL4N-V9ev; Tue, 2 Apr 2013 16:41:06 +1300 (NZDT) Received: from [192.168.1.64] (122-60-64-230.jetstream.xtra.co.nz [122.60.64.230]) (Authenticated sender: mark.kirkwood) by mail.catalyst.net.nz (Postfix) with ESMTPSA id 7736632524; Tue, 2 Apr 2013 16:41:06 +1300 (NZDT) Message-ID: <515A5352.4030406@catalyst.net.nz> Date: Tue, 02 Apr 2013 16:41:06 +1300 From: Mark Kirkwood User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Armand du Plessis CC: pgsql-performance Subject: Re: Fwd: Problems with pg_locks explosion References: <515A2223.5080204@catalyst.net.nz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2404:130:0:10::40:2 (failed) X-Pg-Spam-Score: -1.1 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org Yeah, as I understand it you should have 6000 IOPS available for the md device (ideally). The iostats you display certainly look benign... but the key time to be sampling would be when you see the lock list explode - could look very different then. Re vm.dirty* - I would crank the values down by a factor of 5: vm.dirty_background_ratio = 1 (down from 5) vm.dirty_ratio = 2 (down from 10) Assuming of course that you actually are seeing an IO stall (which should be catchable via iostat or iotop)... and not some other issue. Otherwise leave 'em alone and keep looking :-) Cheers Mark On 02/04/13 13:31, Armand du Plessis wrote: > > > I had a look at the iostat output (on a 5s interval) and pasted it > below. The utilization and waits seems low. Included a sample below, #1 > taken during normal operation and then when the locks happen it > basically drops to 0 across the board. My (mis)understanding of the IOPS > was that it would be 1000 IOPS per/volume and when in RAID0 should give > me quite a bit higher throughput than in a single EBS volume setup. (My > naive envelop calculation was #volumes * PIOPS = Effective IOPS :/) > > > I'm looking into vm.dirty_background_ratio, vm.dirty_ratio sysctls. Is > there any guidance or links available that would be useful as a starting > point? > > Thanks again for the help, I really appreciate it. > -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance