FOLLOW US
sysctl
Occasionally my shared memory segment settings in my /etc/rc file aren’t applied correctly during startup and I get the following error when I try to start Postgres:
|
1 2 3 4 |
FATAL: could not create shared memory segment: Cannot allocate memory
DETAIL: Failed system call was shmget(key=5432001, size=33554432, 03600).
HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory or swap space. To reduce the request size (currently 33554432 bytes), reduce PostgreSQL's shared_buffers parameter (currently 3584) and/or its max_connections parameter (currently 103).
The PostgreSQL documentation contains more information about shared memory configuration. |
I would expect my shared memory size to be 167772160 instead of 33554432 since my /etc/rc file looks like this:
|
1 2 3 4 5 |
sysctl -w kern.sysv.shmmax=167772160
sysctl -w kern.sysv.shmmin=1
sysctl -w kern.sysv.shmmni=32
sysctl -w kern.sysv.shmseg=8
sysctl -w kern.sysv.shmall=65536 |
Restarting my machine helps, but doing that is just painful.
This may be obvious, but I learned that you can apply the sysctl command even if it doesn’t happen during startup. So all I had to do to fix my Postgres problem was:
|
1 2 3 4 5 6 |
> sudo sysctl -w kern.sysv.shmmax=16777216
kern.sysv.shmmax: 33554432 -> 167772160
> sudo sysctl -w kern.sysv.shmseg=8
kern.sysv.shmseg: 64 -> 8
> sudo sysctl -w kern.sysv.shmall=65536
kern.sysv.shmall: 8192 -> 65536 |
To see a list of all the kernel variables, type sysctl -A. Check out the sysctl man page for more details.
2 Comments
It seems that either your /etc/rc is not getting called, or that some other program or process with root privileges is calling sysctl or issuing system calls and changing your shmem settings.
After boot, run sysctl -a and see if the settings in your startup file are getting run. If not, there’s the problem; fix that by checking with your distribution and finding out the correct way to get those settings run at startup.
If it’s getting set up correctly at boot, but changed later “mysteriously”, then you will have some forensics to do. Some process is changing them, and you’ll want to know what and why.
Manually running systcl commands when things go haywire is a hack. You should probably figure out what is causing the problem in the first place, and fix that.
Thanks for the comment. Absolutely agree with you. Hacking the system with sysctl was probably not the best approach, but under deadline, it was the immediate option I went with.
In the end, I actually ended up getting a new system. My mac had a bunch of issues related to hardware: airport kept on failing (I tried every trick on the web to fix it), my battery needed replacing, and my trackpad started sticking.