Re: Problems with pg_locks explosion - Mailing list pgsql-performance

From Jeff Janes
Subject Re: Problems with pg_locks explosion
Date
Msg-id CAMkU=1zFuG2PDzcZ4xwX20aNBF9NXzXNnz8c7Gsmrs3V1jXMWQ@mail.gmail.com
Whole thread Raw
In response to Re: Problems with pg_locks explosion  (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>)
Responses Re: Problems with pg_locks explosion  (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>)
List pgsql-performance
On Monday, April 1, 2013, Mark Kirkwood wrote:

Your provisioned volumes are much better than the default AWS ones, but are still not hugely fast (i.e 1000 IOPS is about 8 MB/s worth of Postgres 8k buffers). So you may need to look at adding more volumes into the array, or adding some separate ones and putting pg_xlog directory on 'em.

However before making changes I would recommend using iostat or sar to monitor how volumes are handling the load (I usually choose a 1 sec granularity and look for 100% util and high - server hundred ms - awaits). Also iotop could be enlightening.

Hi Mark,

Do you have experience using these tools with AWS?  When using non-DAS in other contexts, I've noticed that these tools often give deranged results, because the kernel doesn't correctly know what time to attribute to "network" and what to attribute to "disk".  But I haven't looked into it on AWS EBS, maybe they do a better job there.
 
Thanks for any insight,

Jeff

pgsql-performance by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: Postgres upgrade, security release, where?
Next
From: Jeff Janes
Date:
Subject: Re: Problems with pg_locks explosion