From: | Sven Willenberger <sven(at)dmv(dot)com> |
---|---|
To: | Claus Guttesen <kometen(at)gmail(dot)com> |
Cc: | Jon Brisbin <jon(dot)brisbin(at)npcinternational(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Performance on SUSE w/ reiserfs |
Date: | 2005-10-11 13:52:30 |
Message-ID: | 1129038750.1975.13.camel@lanshark.dmv.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, 2005-10-11 at 09:41 +0200, Claus Guttesen wrote:
> I have a postgresql 7.4.8-server with 4 GB ram.
<snip>
>
> > #effective_cache_size = 1000 # typically 8KB each
>
> This is computed by sysctl -n vfs.hibufspace / 8192 (on FreeBSD). So I
> changed it to:
>
> effective_cache_size = 27462 # typically 8KB each
Apparently this formula is no longer relevant on the FreeBSD systems as
it can cache up to almost all the available RAM. With 4GB of RAM, one
could specify most of the RAM as being available for caching, assuming
that nothing but PostgreSQL runs on the server -- certainly 1/2 the RAM
would be a reasonable value to tell the planner.
(This was verified by using dd:
dd if=/dev/zero of=/usr/local/pgsql/iotest bs=128k count=16384 to create
a 2G file then
dd if=/usr/local/pgsql/iotest of=/dev/null
If you run systat -vmstat 2 you will see 0% diskaccess during the read
of the 2G file indicating that it has, in fact, been cached)
Sven
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-10-11 14:17:12 | Re: Massive delete performance |
Previous Message | Andy | 2005-10-11 13:27:48 | Re: Massive delete performance |