> Mem: 71M Active, 23M Inact, 72M Wired, 436K Cache, 48M Buf, 208M Free
> Swap: 368M Total, 2852K Used, 366M Free
>
> It's right that I can figure that I can use 384M (total RAM) - 72M
> (wired) - 48M (buf) = 264M for PostgreSQL.
> Hence, if I set effective_cache_size to 24M (3072 8K blocks),
> reasonable value (less than 240M, say 48M) for sort_mem, some value for
> shared_buffers (i.e. 24M, or 6144 4K blocks (FreeBSD), or 3072 8K blocks
> (PostgreSQL)), and rest of RAM 264M (total free with OS cache) - 24M
> (reserved for OS cache) - 48M (sort) - 24M (shared) = 168M PostgreSQL
> allocate dynamically by himself?
Totally, utterly the wrong way around.
Start with 384M, subtract whatever is in use by other processes,
excepting kernel disk cache, subtract your PG shared buffers, subtract
(PG proc size + PG sort mem)*(max number of PG processes you need to run
- should be same as max_connections if thinking conservatively), leave
some spare room so you can ssh in without swapping, and *the remainder*
is what you should set effective_cache_size to. This is all in the
docs.
The key thing is: set effective_cache_size *last*. Note that Postgres
assumes your OS is effective at caching disk blocks, so if that
assumption is wrong you lose performance.
Also, why on _earth_ would you need 48MB for sort memory? Are you
seriously going to run a query that returns 48M of data and then sort
it, on a machine with 384M of RAM?
M
