Search Postgresql Archives

Re: feature: dynamic DB cache resizing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Monday December 5 2005 3:17 pm, Tom Lane wrote:
> There isn't any particularly good reason to be resizing
> shared_buffers on the fly anyway; much easier to let the
> kernel adapt the size of its disk cache instead.  Best
> practice for shared_buffers is to set it somewhere in the
> range of 10K to 50K and forget it.

Oh, how I wish it were so on these boxes.  However, HP gurus tell 
me that OS dynamic buffer caches larger than ~800MB +/- slop 
have diminishing returns due to contention between vhand and 
others.  Therefore, to most effectively take advantage of a big 
multi-cluster box with gobs of RAM for DB caching, it seems to 
me I need to specifically allocate the available RAM among the 
DB clusters.  [This is a pain and I'd much rather the OS did it 
for me.]  Of course, we don't know how many clusters we'll have 
and of what size when we start.  Thus, the need for resizing the 
DB caches as new clusters come online.  Does that make sense?

Ed



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux