Re: high shared buffer and swap - Mailing list pgsql-hackers

Sorry for top-posting - the iphone mail client sucks.

I think what's happening is that the sytem is seeing that some pages
of shared memory haven't been used recently and because there's more
shared memory than filesystem cache less recently than the filesystem
cache pages. So it pages out the shared memory. This is really awful
because we use a kind of lru algorithm for shared memory so the pages
that it's paging out are precisely the pges likely to be used soon.

I wonder if we should try to mlock shared buffers.

--
Greg


On 4 May 2009, at 10:10, Laurent Laborde <kerdezixe@gmail.com> wrote:

> Friendly greetings !
> I found something "odd" (something that i can't explain) this weekend.
>
> An octocore server with 32GB of ram, running postgresql 8.3.6
> Running only postgresql, slony-I and pgbouncer.
>
> Just for testing purpose, i tried a setting with 26GB of
> shared_buffer.
>
> I quickly noticed that the performances wasn't very good and the
> server started to swap slowly but surely.
> (but still up to 2000query/second as reported by pgfouine)
>
> It used all the 2GB of swap.
> I removed the server from production, added 10GB of swap and left it
> for the weekend with only slony and postgresql up to keep it in sync
> with the master database.
>
> This morning i found that the whole 12GB of swap were used :
> Mem:  32892008k total, 32714728k used,   177280k free,    70872k
> buffers
> Swap: 12582896k total, 12531812k used,    51084k free, 27047696k
> cached
>
> # cat /proc/meminfo
> MemTotal:     32892008 kB
> MemFree:        171140 kB
> Buffers:         70852 kB
> Cached:       27065208 kB
> SwapCached:    4752492 kB
> Active:       24362168 kB
> Inactive:      7806884 kB
> HighTotal:           0 kB
> HighFree:            0 kB
> LowTotal:     32892008 kB
> LowFree:        171140 kB
> SwapTotal:    12582896 kB
> SwapFree:        53064 kB
> Dirty:          122636 kB
> Writeback:           0 kB
> AnonPages:      280336 kB
> Mapped:       14118588 kB
> Slab:           224632 kB
> PageTables:     235120 kB
> NFS_Unstable:        0 kB
> Bounce:              0 kB
> CommitLimit:  29028900 kB
> Committed_AS: 28730620 kB
> VmallocTotal: 34359738367 kB
> VmallocUsed:     12916 kB
> VmallocChunk: 34359725307 kB
>
> While i understand that a very high shared_buffer wasn't a good idea,
> i don't understand this behaviour.
> Any tought ?
>
> I tried this setup because having 2 level of data caching doesn't make
> sense to me. (1 in OS filesystem cache and 1 in shm (shared_buffer)).
>
> I'd love to understand what's happening here ! Thank  you :)
>
> --
> F4FQM
> Kerunix Flan
> Laurent Laborde
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org
> )
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance