Обсуждение: Solaris initdb fails: shmmax tweak alternative?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am trying to get version 7.4.2 installed on a Solaris box, but initdb fails because of shmmax being set too low. It does this even though initdb drops shared buffers as low as it can go (50). Is there any other way of getting around this limitation? I know that 50 is pretty low, but the recommended way (changing shmmax) involves rebooting a production machine and, while possible, is not preferred. (This is for a very small database, and having a very low shared buffers is acceptable.) - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200404041539 -----BEGIN PGP SIGNATURE----- iD8DBQFAcGUZvJuQZxSWSsgRAlNbAKCPBix3GX3M5LoOaF+uGSeNtaEKLgCfR5vV zbN3wrnnbAAk3lkG2XH69fM= =6lom -----END PGP SIGNATURE-----
"Greg Sabino Mullane" <greg@turnstep.com> writes:
> I am trying to get version 7.4.2 installed on a Solaris box, but
> initdb fails because of shmmax being set too low. It does this
> even though initdb drops shared buffers as low as it can go (50).
> Is there any other way of getting around this limitation?
IIRC you can put it as low as 16 without having to resort to changing
the backend C code (you'll need to drop max_connections to 8 at the
same time). 50 is just the lowest value initdb troubles to probe,
but you could hack the initdb script easily to try smaller values.
Whether you'll get decent performance or stability at such a tiny
setting is another question.
> I know that 50 is pretty low, but the recommended way (changing
> shmmax) involves rebooting a production machine and, while possible,
> is not preferred.
[ raises eyebrow... ] So you're installing a test database server on a
production machine? That's not preferred admin practice anywhere that
I know of. If it's really going to be a production server, I won't have
a lot of sympathy for the performance problems that you'll doubtless
have, small database or no.
regards, tom lane
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > [ raises eyebrow... ] So you're installing a test database server on a > production machine? That's not preferred admin practice anywhere that > I know of. If it's really going to be a production server, I won't have > a lot of sympathy for the performance problems that you'll doubtless > have, small database or no. Not my choice, just be glad I've managed to get Postgres involved at all. :) The development is already finished, but the development box and the production box are not the same OS. Not ideal conditions, but very much out of my control. Having to recompile initdb.c is probably not an option. I'll probably push to get shmmax bumped up. Contrary to the other writer's assertion however, Sybase and Oracle both installed properly without having to change shmmax. If anyone familiar with these can assert that a low shmmax also affects their performance, that would be helpful in my argument to bump it up for the PG install. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200404050713 -----BEGIN PGP SIGNATURE----- iD8DBQFAcUE6vJuQZxSWSsgRAr80AKC/SVVm4unhMOh+Z0+rhDqn8zGSigCg5hve iKhSKUt6N7qNhuq9WRO/EH4= =OuWo -----END PGP SIGNATURE-----
Greg Sabino Mullane said: > > > Having to recompile initdb.c is probably not an option. Which version of PostreSQL are you installing on this production machine? initdb is not a C program in any released version - in 7.4.2 it is a shell script which you could trivially modify. Of course, in the next release it will be a C program. cheers andrew
"Greg Sabino Mullane" <greg@turnstep.com> writes:
> Having to recompile initdb.c is probably not an option.
initdb is just a shell script in existing releases.
> Sybase and Oracle both installed properly without having to change shmmax.
My bet is that they ate all available shmem, leaving none for Postgres...
have you checked ipcs(1) to see what's already allocated?
regards, tom lane
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Having to recompile initdb.c is probably not an option. > >initdb is just a shell script in existing releases. Yes, you are right. By sheer habit I typed in cd ~/pgsql/src/bin. > My bet is that they ate all available shmem, leaving none for > Postgres... have you checked ipcs(1) to see what's already allocated? I did that and found out that Oracle is actually installed on a different box! *sheepish grin* The good news of all this is that Oracle would probably have had the same problems (but been much more cryptic about what exactly the problem was). Thanks for the replies: I am going to push for a shmmax boost and go from there. Less pain in the long run. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200404052013 -----BEGIN PGP SIGNATURE----- iD8DBQFAcfbavJuQZxSWSsgRAr1SAJ0QZ9/Ur2NGmLnHJLzEqZ/grjq0kwCg3XpD hg4M9gvuq5XmwnCxPaWojJg= =vCPa -----END PGP SIGNATURE-----
Anyone see a benefit of adding command line flags to initdb to force
lower shared memory use without require a recompile?
Robert Treat
On Mon, 2004-04-05 at 08:53, Andrew Dunstan wrote:
> Greg Sabino Mullane said:
> >
> >
> > Having to recompile initdb.c is probably not an option.
>
> Which version of PostreSQL are you installing on this production machine?
> initdb is not a C program in any released version - in 7.4.2 it is a shell
> script which you could trivially modify. Of course, in the next release it
> will be a C program.
>
> cheers
>
> andrew
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
> > Anyone see a benefit of adding command line flags to initdb to force > lower shared memory use without require a recompile? [snip] > When I built and installed pgsql at work, on a production server, I ran into the shared memory problem. I wanted to fire pgsql up *right* *away*, to begin testing and so-on, so I hacked the shell script. Early next morning I rebooted the server, with the shared memory changes already configured. So yes: I can see a certain limited set of conditions under which doing such a thing might be useful. Jim
Robert Treat <xzilla@users.sourceforge.net> writes:
> Anyone see a benefit of adding command line flags to initdb to force
> lower shared memory use without require a recompile?
Lower than what? The bottom values it checks are already ridiculously
small. If you can't get it to initdb you really need to fix your kernel
settings ...
regards, tom lane
On Apr 4, 2004, at 3:41 PM, Greg Sabino Mullane wrote: > I am trying to get version 7.4.2 installed on a Solaris box, but > initdb fails because of shmmax being set too low. It does this > even though initdb drops shared buffers as low as it can go (50). > Is there any other way of getting around this limitation? I know You can also check out max_connections. Each one of those gobbles up shared memory. Unfortunately, there isn't anything else you can really do beyond taking down shared_buffers and max_connections. Its annoying, but if it makes you feel better, Informix or Oracle would have the same problem. -- Jeff Trout <jeff@jefftrout.com> http://www.jefftrout.com/ http://www.stuarthamm.net/
On Sun, Apr 04, 2004 at 07:41:38PM -0000, Greg Sabino Mullane wrote: > I am trying to get version 7.4.2 installed on a Solaris box, but > initdb fails because of shmmax being set too low. It does this You'll have to fix shmmax. I've never been able to get postgres started (since 7.0) on Solaris with the Solaris defaults. A -- Andrew Sullivan | ajs@crankycanuck.ca