Skip site navigation (1) Skip section navigation (2)

Re: shared_buffers and shmmax

From: Valentin Bogdanov <valiouk(at)yahoo(dot)co(dot)uk>
To: posgres support <pgsql-admin(at)postgresql(dot)org>, dx k9 <bitsandbytes88(at)hotmail(dot)com>
Subject: Re: shared_buffers and shmmax
Date: 2008-07-22 14:08:32
Message-ID: 818191.79570.qm@web25804.mail.ukl.yahoo.com (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-docspgsql-hackers
shared_buffers is in disk block size, typically 8K, at least that's what it is on Linux platforms. shmmax is quite simply in bytes.

The default shared_buffer of a 1000 is quite conservative. A good starting value is something like 15-25 percent of your main memory or so I am being told. It really depends on how the machine you have your database on is being used. If postgres is the only application using your box then you can even set this to 80% of the memory. You're fine as long as postgres does not have to resort to using the swap space.

If you set shared_buffers so high that it doesn't agree with your systems shmmax then postgres will give you the required value on startup.


Regards,

Val


--- On Tue, 22/7/08, dx k9 <bitsandbytes88(at)hotmail(dot)com> wrote:

> From: dx k9 <bitsandbytes88(at)hotmail(dot)com>
> Subject: [ADMIN] shared_buffers and shmmax
> To: "posgres support" <pgsql-admin(at)postgresql(dot)org>
> Date: Tuesday, 22 July, 2008, 2:39 PM
> Hi,
> I'm trying to understand what the documentation means
> by bytes per increment, what is the increment supposed to
> be bytes, MB, or Kb.  I have my shared_buffers set to 577
> MB(4 instances) and I'm multiplying by 8400 bytes.  I
> would think I would want to keep everything in bytes and
> not mulitply bytes times MB, but this is what table 17-2
> implies.  If I convert 577 to bytes and multiply, my
> calculator goes exponential on me. I'm going through
> this table and adding up to see what my shmmax should be
> (it's 7.5 GB) out of a total memory of 16 GB with 1000
> max_connections right now.  What should I use as the
> "increment" value in regards to shared buffers,
> 577, 590848 or 605028352 ? 
>  
> a) 577 MB (This seems too small)
> b) 590,848 Kb (this seems just right)
> c) 605,028,352 bytes  (this seems too big, I hope it's
> not c)
>  
> Thanks,
> ~DjK
>  
> Table 17-2. Configuration parameters affecting
> PostgreSQL's shared memory usage
> 
> 
> 
> 
> 
> 
> 
> Name
> Approximate multiplier (bytes per increment) as of 8.3
> 
> 
> max_connections
> 1800 + 270 * max_locks_per_transaction
> 
> autovacuum_max_workers
> 1800 + 270 * max_locks_per_transaction
> 
> max_prepared_transactions
> 770 + 270 * max_locks_per_transaction
> 
> shared_buffers
> 8400 (assuming 8 kB BLCKSZ)
> 
> wal_buffers
> 8200 (assuming 8 kB XLOG_BLCKSZ)
> 
> max_fsm_relations
> 70
> 
> max_fsm_pages
> 6
> 
> Fixed space requirements
> 770 kB
> _________________________________________________________________
> Stay in touch when you're away with Windows Live
> Messenger.
> http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_messenger2_072008


      __________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

In response to

Responses

pgsql-docs by date

Next:From: Tom LaneDate: 2008-07-22 14:45:59
Subject: Re: [ADMIN] shared_buffers and shmmax
Previous:From: dx k9Date: 2008-07-22 13:39:57
Subject: shared_buffers and shmmax

pgsql-hackers by date

Next:From: Zdenek KotalaDate: 2008-07-22 14:32:39
Subject: Re: [WIP] collation support revisited (phase 1)
Previous:From: Dave PageDate: 2008-07-22 13:47:11
Subject: Re: Do we really want to migrate plproxy and citext into PG core distribution?

pgsql-admin by date

Next:From: Tom LaneDate: 2008-07-22 14:45:59
Subject: Re: [ADMIN] shared_buffers and shmmax
Previous:From: dx k9Date: 2008-07-22 13:39:57
Subject: shared_buffers and shmmax

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group