Re: Bug#67481: Should a package increase a kernel parameter? (Re: Bug#67481)
Oliver Elphick wrote:
>
> Andrew is suggesting a mechanism for automatically increasing a kernel
> parameter when postgresql is going to need more shared memory than the
> default allocation.
>
> While what he asks for is not difficult to do, I wonder if we should
> not have a more general way of doing this. If I do this in postgresql,
> as I already do for KERNEL_FILE_MAX, it will not take into account the
> needs of other packages. Perhaps we should have a package that can be
> used for other packages to register their requirements and thus raise
> kernel limits to meet the demands of all packages that might encounter
> those limits.
>
> Example:
> postgresql is configured to run 4096 backends (good grief!) and so
Nope. 4096 _shared_buffers_ - quite a difference. I only have it set
for 256 backends :-)
Whacking up the buffers to use the memory available is a pretty standard
heuristic to increase performance. Over time those buffers will pretty
much cache the database, if the queries tend to hit the same records.
We have a few machines here which have over 300M of RAM (not in the
least unusual) and are starting to move towards ordering 256M as
standard on newer ones. I can see 1GB coming soon enough (for us, I
mean - lot's of people already have that much RAM).
> requires 33Mb of shared memory. Another package, foo, requires 5Mb and
> bar requires 6Mb; this gives a total requirement of 44Mb. If I do the
> operation in postgresql's scripts, I will only provide 33Mb. My
> suggested kernel limits package would know that it needed to provide
> the full 44Mb.
Correct me if I'm wrong, but I think the shmmax parameter is actually
setting the maximum size. If I run two PostgreSQL postmasters with
lot's of buffers they won't need A + B they'll need MAX(A,B).
Still, I think what you are proposing is a darn fine idea. Something
like a /etc/kernelparm.d which contained files from individual
packages. Each file could contain 'stuff that controlled the
parameters' and then something in rc.d, probably running at
S01kernelparm or so would unroll them all and apply them.
It'd have to understand them a bit, some being 0 and 1, and some being
numbers that get added, max-ed, min-ed, etc, etc. Hardly an
insurmountable though, and it would get better over time.
This could also clean up stuff like 'ipmasq' having to echo
>/proc/sys/... as well of course.
Now, if only I could get through New Maintainer I could even build such
a beast :-)
Cheers,
Andrew.
--
_____________________________________________________________________
Andrew McMillan, e-mail: Andrew@cat-it.co.nz
Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington
Me: +64 (21) 635 694, Fax: +64 (4) 499 5596, Office: +64 (4) 499 2267
Reply to: