From: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> |
---|---|
To: | Armand du Plessis <adp(at)bank(dot)io> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Problems with pg_locks explosion |
Date: | 2013-04-02 06:43:34 |
Message-ID: | 515A7E16.5080005@catalyst.net.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Also it is worth checking what your sysctl vm.zone_reclaim_mode is set
to - if 1 then override to 0. As Jeff mentioned, this gotcha for larger
cpu number machines has been discussed at length on this list - but
still traps us now and again!
Cheers
Mark
On 02/04/13 19:33, Armand du Plessis wrote:
> I had my reservations about my almost 0% IO usage on the raid0 array as
> well. I'm looking at the numbers in atop and it doesn't seem to reflect
> the aggregate of the volumes as one would expect. I'm just happy I am
> seeing numbers on the volumes, they're not too bad.
>
> One thing I was wondering, as a last possible IO resort. Provisioned EBS
> volumes requires that you maintain a wait queue of 1 for every 200
> provisioned IOPS to get reliable IO. My wait queue hovers between 0-1
> and with the 1000 IOPS it should be 5. Even thought about artificially
> pushing more IO to the volumes but I think Jeff's right, there's some
> internal kernel voodoo at play here. I have a feeling it'll be under
> control with pg_pool (if I can just get the friggen setup there right)
> and then I'll have more time to dig into it deeper.
>
> Apologies to the kittens for the interrupting your leave :)
>
From | Date | Subject | |
---|---|---|---|
Next Message | Armand du Plessis | 2013-04-02 08:16:57 | Re: Problems with pg_locks explosion |
Previous Message | Armand du Plessis | 2013-04-02 06:33:29 | Re: Problems with pg_locks explosion |