Search Postgresql Archives

Re: DB cache size strategies

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

 



On Wed, Feb 11, 2004 at 09:47:35AM -0700, Ed L. wrote:
> First, suppose DB processes are more important (and thus more deserving of 
> cache) than other processes in an all-on-one-box case.  For example, the 
> non-DB processes consisted strictly of various non-performance-critical 
> programs to analyze large log files, etc.  Would it then make sense to use 
> theory (2) to ensure those non-critical programs do not inadvertently 
> increase I/O for the DB processes?

Are you assuming that shared memory will not be swapped out? If you allocate
lots of the shared memory to the cluster that it's not going to used anyway
most of the time, you're just going to find it's being swapped.

> Second, suppose we have 2 clusters running on a dedicated DB server, each 
> with a large enough dataset to cause the other's data to be completely 
> crowded out of the kernel cache during backups under theory (1), causing a 
> lot of disk I/O for the other as the other gradually reloads.  If we use 
> theory (2), allocating roughly half of available RAM to each DB cache 
> (minus breathing room for admin, OS), I would expect that over time, the 
> entire DB dataset for each cluster would work its way into each cluster's 
> DB cache and be largely immune to the activities of the other cluster.  
> We'd consider that a good thing.  Would this be an appropriate scenario for 
> theory (2)?

I'd expect the kernel the swap out enough of the shared memory in each
cluster to match the actual working set. Although, I imagine PostgreSQL's
buffer management may affect the way it's gets swapped. I have no idea
whether PostgreSQL's buffer management code does a lot of page touching.

Note, some OS's don't swap out shared memory, so the above doesn't apply to
them.

-- 
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> (... have gone from d-i being barely usable even by its developers
> anywhere, to being about 20% done. Sweet. And the last 80% usually takes
> 20% of the time, too, right?) -- Anthony Towns, debian-devel-announce

Attachment: pgp00195.pgp
Description: PGP signature


[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