>>>>> "AL" == Allen Landsidel <all@biosys.net> writes:
AL> maxusers 256
>>
>> let the system autoconfigure maxusers...
AL> Are you sure about this? I have always understood that explicitly
AL> setting this value was the best thing to do if you knew the maximum
Yes, recent freebsd kernels autosize various tables and limits based
on existing RAM. It does pretty well.
AL> These are related to something else.. a linux developer on the system
AL> used to the way it'll always allow you access to all the memory on a
Ahhh... I guess we don't believe in multi-user systems ;-)
AL> options SHMMAXPGS=65536
>>
>> perhaps bump this and increase your shared buffers. I find that if
>> you do lots of writes, having a few more shared buffers helps.
AL> Any ideas how much of a bump, or does that depend entirely on me and I
AL> should just play with it? Would doubling it be too much of a bump?
I use 262144 for SHMMAXPGS and SHMALL. I also use about 30000 shared
buffers.
AL> I'll see if sysctl lets me write this value, or if it's a kernel
AL> config option I missed, unless you have remembered between then and
you need to bump some header file constant and rebuild the kernel. it
also increases the granularity of how the buffer cache is used, so I'm
not sure how it affects overall system. nothing like an experiment...
AL> Given this and the above about the controllers onboard cache (not to
AL> mention the per-drive cache) do you think I'll still need to lower
AL> effective_cache_size?
It is hard to say. If you tell PG you have more than you do, I don't
know what kind of decisions it will make incorrectly. I'd rather be
conservative and limit it to the RAM that the system says it will
use. The RAM in the controller is not additive to this -- it is
redundant to it, since all data goes thru that cache into the main
memory.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/