Re: [PERFORM] shared_buffers advice
On 11 March 2010 16:16, Ben Chobot wrote: > I *can* say a 10GB shared_buffer value is working "well" with my 128GB of > RAM. whether or not it's "optimal," I couldn't say without a lot of > experimentation I can't afford to do right now. You might have a look at the > pg_buffercache contrib module. It can tell you how utilized your shared > buffers are. Thanks Ben and Greg, I shall start with something relatively sane (such as 10GB) and then see how we go from there. Once this server has brought online and bedded in I will be updating our other three servers which are identical in hardware spec and all have the same replicated data so I'll be able to do some real world tests with different settings withn the same load. (Currently one is currently running postgresql 8.1 on 32bit OS under a VM, the other two running 8.3 on 64bit OS with 64gig of memory but with Postgres still tuned for the 8 gigs the servers originally had and under a VM). Paul -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
[PERFORM] shared_buffers advice
Hi there, I'm after a little bit of advice on the shared_buffers setting (I have read the various docs on/linked from the performance tuning wiki page, some very helpful stuff there so thanks to those people). I am setting up a 64bit Linux server running Postgresql 8.3, the server has 64gigs of memory and Postgres is the only major application running on it. (This server is to go alongside some existing 8.3 servers, we will look at 8.4/9 migration later) I'm basically wondering how the postgresql cache (ie shared_buffers) and the OS page_cache interact. The general advice seems to be to assign 1/4 of RAM to shared buffers. I don't have a good knowledge of the internals but I'm wondering if this will effectively mean that roughly the same amount of RAM being used for the OS page cache will be used for redundantly caching something the Postgres is caching as well? IE when Postgres reads something from disk it will go into both the OS page cache and the Postgresql shared_buffers and the OS page cache copy is unlikely to be useful for anything. If that is the case what are the downsides to having less overlap between the caches, IE heavily favouring one or the other, such as allocating shared_buffers to a much larger percentage (such as 90-95% of expected 'free' memory). Paul -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
[PERFORM] shared_buffers advice
Hi there, I'm after a little bit of advice on the shared_buffers setting (I have read the various docs on/linked from the performance tuning wiki page, some very helpful stuff there so thanks to those people). I am setting up a 64bit Linux server running Postgresql 8.3, the server has 64gigs of memory and Postgres is the only major application running on it. (This server is to go alongside some existing 8.3 servers, we will look at 8.4/9 migration later) I'm basically wondering how the postgresql cache (ie shared_buffers) and the OS page_cache interact. The general advice seems to be to assign 1/4 of RAM to shared buffers. I don't have a good knowledge of the internals but I'm wondering if this will effectively mean that roughly the same amount of RAM being used for the OS page cache will be used for redundantly caching something the Postgres is caching as well? IE when Postgres reads something from disk it will go into both the OS page cache and the Postgresql shared_buffers and the OS page cache copy is unlikely to be useful for anything. If that is the case what are the downsides to having less overlap between the caches, IE heavily favouring one or the other, such as allocating shared_buffers to a much larger percentage (such as 90-95% of expected 'free' memory). Paul (Apologies if two copies of this email arrive, I sent the first from an email address that wasn't directly subscribed to the list so it was blocked). -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
SHMMAX / SHMALL Was (Re: [PERFORM] postgresql-8.0.1 performance tuning)
On 6/1/05, Mark Kirkwood <[EMAIL PROTECTED]> wrote: > Cosimo Streppone wrote: > > # Config > >> /etc/sysctl.conf: > >> kernel.shmall = 786432000 > >> kernel.shmmax = 786432000 > > > > I think you have a problem here. > > kernel.shmmax should *not* be set to an amount of RAM, but > > to maximum number of shared memory pages, which on a typical linux system > > is 4kb. Google around: > > > This is somewhat confusing : > > kernel.shmmax is in bytes (max single segment size) > kernel.shmall is in (4k) pages (max system wide allocated segment pages) Can someone resummarize the situation with these linux parameters for the dummies? I thought I had my calculations all sorted out but now I've confused myself again. The documentation at http://www.postgresql.org/docs/8.0/interactive/kernel-resources.html puts the same figure into both values but the posts here seem to suggest that is wrong? Or is it different on a 2.4 kernel and the documentation needs updating? In my specific case I have about 800meg of memory on a linux 2.4 kernel box. Based on the powerpostgresql.com Performance Checklist [1] and Annotated Postgresql.conf [2] I understand that: -I should have less than 1/3 of my total memory as shared_buffers -For my server 15000 is a fairly reasonable starting point for shared_buffers which is ~120MB -I have 100 max_connections. So I was going to set SHMMAX to 134217728 (ie 128 Meg) What should SHMALL be? The current system values are [EMAIL PROTECTED]:~/data$ cat /proc/sys/kernel/shmmax 33554432 [EMAIL PROTECTED]:~/data$ cat /proc/sys/kernel/shmall 2097152 ie SHMALL seems to be 1/16 of SHMMAX Paul [1] http://www.powerpostgresql.com/PerfList/ [2] http://www.powerpostgresql.com/Downloads/annotated_conf_80.html ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
