From: Kenneth Marshall <ktm@rice.edu>
To: Vaughn, Adam (IMS) <VaughnA@imsweb.com>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: 'pgsql-admin@postgresql.org' <pgsql-admin@postgresql.org>
Cc: Depuy, Scott (IMS) <DepuyS@imsweb.com>
Cc: Meagher, Kevin (IMS) <MeagherK@imsweb.com>
Subject: Re: long running commits
Date: Thu, 3 Mar 2011 08:10:54 -0600
Message-ID: <20110303141054.GU8169@aart.is.rice.edu> (raw)
In-Reply-To: <6B760A41CEE02F46BADF29B4A874D6010F11C13ABF@FALCON.omni.imsweb.com>
References: <6B760A41CEE02F46BADF29B4A874D6010F11C13A63@FALCON.omni.imsweb.com>
<4D67DC90020000250003B04B@gw.wicourts.gov>
<6B760A41CEE02F46BADF29B4A874D6010F11C13ABF@FALCON.omni.imsweb.com>
On Wed, Mar 02, 2011 at 01:10:37PM -0500, Vaughn, Adam (IMS) wrote:
> Thanks for the suggestions. I made all of the changes you mentioned except for the shared_buffers (which will require a downtime I have set for tonight). I do have another question though, why did you pick 512 MB for the new setting of shared_buffers? Everything I've ever read says that 25% of available RAM is a conservative value for shared_buffers.
>
> Also, we had another one of these instances earlier today. During the 23 minute commit a single CPU was at 98% and it looked like all writes were backed up waiting for the commit to finalize. During the time our writing never got above 25 MB/s (far less than we can handle). Is it possible that we're missing an index somewhere or there's something else going on?
>
> Thanks again in advance
>
Hi Adam,
Having recently been benchmarking NFS filesystem performance with
random I/O streams, I think that you do not have the I/O performance
from your filer that you think you do. A 13-disk RAID-DP gives you
at best 11 spindles for random I/O and a single spindle can give a
best 5 MB/sec write throughput for an aggregate throughput of 55MB/sec
if you were the only user of the filer. It is not unreasonable to
assume that you only have 50% of the total throughput available if
it is in use as you stated in your original message. The changes
that have been suggested should allow you to keep the write needs
below your apparent 27MB/sec cap and reduce or eliminate the pauses.
Cheers,
Ken
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: ktm@rice.edu, VaughnA@imsweb.com, Kevin.Grittner@wicourts.gov, DepuyS@imsweb.com, MeagherK@imsweb.com
Subject: Re: long running commits
In-Reply-To: <20110303141054.GU8169@aart.is.rice.edu>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox