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

Re: FreeBSD config

From: Dror Matalon <dror(at)zapatec(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: FreeBSD config
Date: 2004-02-27 18:27:26
Message-ID: (view raw or whole thread)
Lists: pgsql-performance
I guess the thing to do is to move this topic over to a freebsd list
where we can get more definitive answers on how disk caching is handled.
I asked here since I know that FreeBsd is often recommended,
as a good platform for postgres, and with Modern machines often having
Gigabytes of memory the issue of, possibly, having a disk cache of 200MB
would be one often asked.

On Fri, Feb 27, 2004 at 12:46:08PM +0530, Shridhar Daithankar wrote:
> Dror Matalon wrote:
> >Let me try and say it again. I know that setting effective_cache_size
> >doesn't affect the OS' cache. I know it just gives Postgres the *idea*
> >of how much cache the OS is using. I know that. I also know that a
> >correct hint helps performance.
> >
> >I've read Matt Dillon's discussion about the freebsd VM at
> > and I didn't see him
> >saying that Freebsd uses all the free RAM for disk cache. Would you care
> >to provide a URL pointing to that?
> I don't believe freeBSD yses everything available unlike linux. It is 
> actually a good thing. If you have 1GB RAM and kernel buffers set at 600MB, 
> you are guaranteed to have some mmory in crunch situations.
> As far you original questions, I think you can increase the kernel buffer 
> sizes for VFS safely. However remembet that more to dedicate to kernel 
> buffers, less space you have in case of crunch for whatever reasons.
> FreeBSD gives you a control which linux does not. Use it to best of your 
> advantage..
>  Shridhar

Dror Matalon
Zapatec Inc 
1700 MLK Way
Berkeley, CA 94709

In response to

pgsql-performance by date

Next:From: Vivek KheraDate: 2004-02-27 18:33:33
Subject: Re: FreeBSD config
Previous:From: postgresDate: 2004-02-27 16:52:39
Subject: Select-Insert-Query

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