Re: heavy swapping, not sure why - Mailing list pgsql-general

> -----Original Message-----
> From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-
> owner@postgresql.org] On Behalf Of Scott Marlowe
> Sent: Tuesday, August 30, 2011 3:52 AM
> To: Sim Zacks
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] heavy swapping, not sure why
>
> On Tue, Aug 30, 2011 at 2:50 AM, Sim Zacks <sim@compulab.co.il> wrote:
> >
> > On a machine with lots of memory, I've run into pathological
> behaviour
> > with both the RHEL 5 and Ubuntu 10.04 kernels where the kswapd starts
> > eating up CPU and swap io like mad, while doing essentially nothing.
> > Setting swappiness to 0 delayed this behaviour but did not stop it.
> > Given that I'm on a machine with 128G ram, I just put "/sbin/swapoff
> > -a" in /etc/rc.local and viola, problem solved.
> >
> > I've tried running without swap and the problem is if you actually do
> run
> > out of memory then the process killer can take out your postgresql.
>
> My postgres is configured to never use more than 10 or 20 gig at max
> load.  That leaves about 80+Gig for caching the database by the
> kernel.  work_mem is pretty small (8MB) given the maximum connections
> (1000) So 8Gig if everybody sorts at once.  Even under very heavy load
> memory usage has never really gone anywhere near that high.


Scott,
1000 max connections ? I thought that was several times more than
recommended these days, even for 24 or 48 core machines. Or am I living in
the past ? (I admit that my most recent runs of pgbench showed that best
throughput at around 250 backends from a 2 cpu VM which kind of surprised me
for a synthetic load and all that)

Thanks.



To the broader list, regarding troubles with kswap. I am curious to what
others seeing from /proc/zoneinfo for DMA pages (not dma32 or normal) -
basically if it sits at 1 or not.  Setting swappiness to 0 did not have any
affect for us on kswap issues. Another thing I have not had time and
resources to go work on... interested in what kernel they are running and
what storage drivers they might be using.

FWIW (to the list vm. swappiness) at 0 didn't play well for us, with a
postgresql fork, until we had a swap partition the size of memory. We were
recommended to make that setting change for the fork that we are using and
didn't, we learn the hard way sometimes. Granted what works well there isn't
always applicable to Postgres.

-Mark






>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general