Re: long running commits

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