shared_buffers/SHMMAX defaults?
Hello fellow PostgreSQL packagers,
recently, I started to get quite a bunch of bug reports a la
"PostgreSQL fails to start due to too little shared memory" [1]https://launchpad.net/bugs/264336. I
have never seen this before, neither in Debian, so I guess the
SHMMAX defaults changed somewhat in Linux 2.6.27. It seems that with
other components, such as X.org, using large amounts of shared memory
as well, startup sometimes works and sometimes doesn't.
Now I wonder what I should do about it. I see these options:
(1) Ignore
+ no hidden magic
- very inconvenient, package installation does not create default
cluster sometimes, or the default cluster fails to start on
system bootBest solution for admin control freaks.
(2) Be more conservative about initdb's default setting
+ no hidden magic
+ upstream compatible solution
- suboptimal performance by default(3) Change SHMMAX in postgresql's init script if necessary
+ Always works
- Unexpected, works behind admin's back.Currently I tend towards (2), but I'd like to hear some more opinions
about it.
Does anyone else have seen this problem as well?
Thanks,
Martin
[1]: https://launchpad.net/bugs/264336
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Martin Pitt <mpitt@debian.org> writes:
Now I wonder what I should do about it. I see these options:
Consider
(4) Lobby your kernel packagers to install saner SHMMAX/SHMALL
defaults.
(I imagine BTW that it's SHMALL that's causing you issues. SHMMAX
shouldn't have any effect that varies depending on what else is using
shared memory.)
regards, tom lane
On Monday 30 March 2009 17:34:36 Martin Pitt wrote:
recently, I started to get quite a bunch of bug reports a la
"PostgreSQL fails to start due to too little shared memory" [1]. I
have never seen this before, neither in Debian, so I guess the
SHMMAX defaults changed somewhat in Linux 2.6.27. It seems that with
other components, such as X.org, using large amounts of shared memory
as well, startup sometimes works and sometimes doesn't.
I think this calls for a distribution-specific policy. E.g., why shouldn't X
be forced to use a "more conservative setting"? How do we even know how much
memory X will use today or tomorrow, or whether X is installed or will be
installed?
Tom Lane [2009-03-30 20:29 -0400]:
Consider
(4) Lobby your kernel packagers to install saner SHMMAX/SHMALL
defaults.
Sounds good. :-)
Those are the current defaults:
kernel.shmmax = 33554432
kernel.shmall = 2097152
kernel.shmmni = 4096
Thanks,
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Martin Pitt <mpitt@debian.org> writes:
Tom Lane [2009-03-30 20:29 -0400]:
Consider
(4) Lobby your kernel packagers to install saner SHMMAX/SHMALL
defaults.
Sounds good. :-)
Those are the current defaults:
kernel.shmmax = 33554432
kernel.shmall = 2097152
kernel.shmmni = 4096
Hm, those shmall and shmmni values seem large enough to not pose a
problem. I think you need to look into the failure reports a little
more closely to figure out what's really wrong.
regards, tom lane