Re: Problems with pg_locks explosion

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
Cc: Armand du Plessis <adp(at)bank(dot)io>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Problems with pg_locks explosion
Date: 2013-04-02 06:08:13
Message-ID: CAMkU=1zFuG2PDzcZ4xwX20aNBF9NXzXNnz8c7Gsmrs3V1jXMWQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Armand du Plessis 2013-04-02 06:21:47 Re: Problems with pg_locks explosion
Previous Message Jeff Janes 2013-04-02 06:08:12 Re: Problems with pg_locks explosion