Обсуждение: OSX 10.3.7 broke Postgresql 8.0.0b5?
I *think* the 10.3.7 upgrade broke my postgresql implementation...
I am getting this error at startup.
FATAL: could not create shared memory segment: Cannot allocate memory
DETAIL: Failed system call was shmget(key=5432001, size=10403840,
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 10403840 bytes), reduce PostgreSQL's
shared_buffers parameter (currently 1000) and/or its max_connections
parameter (currently 100).
The PostgreSQL documentation contains more information about
shared memory configuration.
The first time I noticed the problem I found that the shmmax was set low
at a bit more than 4MB ( perhaps the upgrade replaced /etc/rc ).
I increased the shmmax to about 64MB and still get the same error.
Here are the current kernel settings
kern.sysv.shmmax: 67108864
kern.sysv.shmmin: 1
kern.sysv.shmmni: 32
kern.sysv.shmseg: 8
kern.sysv.shmall: 1024
kern.sysv.semmni: 87381
kern.sysv.semmns: 87381
kern.sysv.semmnu: 87381
kern.sysv.semmsl: 87381
kern.sysv.semume: 10
Do I need to increase anything else?
I am on the digest, if someone knows the answer please CC to me also...
Jerry
Ok, I got postgres to start... I used these settings. kern.sysv.shmmax: 167772160 kern.sysv.shmmin: 1 kern.sysv.shmmni: 32 kern.sysv.shmseg: 8 kern.sysv.shmall: 65536 kern.sysv.semmni: 87381 kern.sysv.semmns: 87381 kern.sysv.semmnu: 87381 kern.sysv.semmsl: 87381 kern.sysv.semume: 10 On Dec 17, 2004, at 3:41 PM, Jerry LeVan wrote: > I *think* the 10.3.7 upgrade broke my postgresql implementation... > > I am getting this error at startup. > > FATAL: could not create shared memory segment: Cannot allocate memory > DETAIL: Failed system call was shmget(key=5432001, size=10403840, > 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 10403840 bytes), reduce PostgreSQL's > shared_buffers parameter (currently 1000) and/or its max_connections > parameter (currently 100). > The PostgreSQL documentation contains more information about > shared memory configuration. > > The first time I noticed the problem I found that the shmmax was set > low > at a bit more than 4MB ( perhaps the upgrade replaced /etc/rc ). > > I increased the shmmax to about 64MB and still get the same error. > > Here are the current kernel settings > > kern.sysv.shmmax: 67108864 > kern.sysv.shmmin: 1 > kern.sysv.shmmni: 32 > kern.sysv.shmseg: 8 > kern.sysv.shmall: 1024 > kern.sysv.semmni: 87381 > kern.sysv.semmns: 87381 > kern.sysv.semmnu: 87381 > kern.sysv.semmsl: 87381 > kern.sysv.semume: 10 > > Do I need to increase anything else? > > I am on the digest, if someone knows the answer please CC to me also... > > Jerry >
Jerry LeVan <jerry.levan@eku.edu> writes:
> Ok, I got postgres to start...
> I used these settings.
FWIW, I just updated to 10.3.7 from 10.3.6 and compared the kern.sysv.*
sysctl settings before and after. I see no indication that the default
values have changed.
regards, tom lane
Well, what might be some good settings for a smallish db with the default configuration? Jerry On Dec 17, 2004, at 5:40 PM, Tom Lane wrote: > Jerry LeVan <jerry.levan@eku.edu> writes: >> Ok, I got postgres to start... >> I used these settings. > > FWIW, I just updated to 10.3.7 from 10.3.6 and compared the kern.sysv.* > sysctl settings before and after. I see no indication that the default > values have changed. > > regards, tom lane >
I'm getting the same error now too, although postgres was running without problem this morning (I updated the OS yesterday). OS X 10.3.7 Server, PostgreSQL 8.0RC1. Basically, I did a pg_dump, stopped the server and then tried to start it again. Any ideas? On Dec 17, 2004, at 2:41 PM, Jerry LeVan wrote: > I *think* the 10.3.7 upgrade broke my postgresql implementation... > > I am getting this error at startup. > > FATAL: could not create shared memory segment: Cannot allocate memory > DETAIL: Failed system call was shmget(key=5432001, size=10403840, > 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 10403840 bytes), reduce PostgreSQL's > shared_buffers parameter (currently 1000) and/or its max_connections > parameter (currently 100). > The PostgreSQL documentation contains more information about > shared memory configuration. > > The first time I noticed the problem I found that the shmmax was set > low > at a bit more than 4MB ( perhaps the upgrade replaced /etc/rc ). > > I increased the shmmax to about 64MB and still get the same error. > > Here are the current kernel settings > > kern.sysv.shmmax: 67108864 > kern.sysv.shmmin: 1 > kern.sysv.shmmni: 32 > kern.sysv.shmseg: 8 > kern.sysv.shmall: 1024 > kern.sysv.semmni: 87381 > kern.sysv.semmns: 87381 > kern.sysv.semmnu: 87381 > kern.sysv.semmsl: 87381 > kern.sysv.semume: 10 > > Do I need to increase anything else? > > I am on the digest, if someone knows the answer please CC to me also... > > Jerry > > > ---------------------------(end of > broadcast)--------------------------- > TIP 8: explain analyze is your friend >
Timothy Perrigo <tperrigo@wernervas.com> writes:
> I'm getting the same error now too, although postgres was running
> without problem this morning (I updated the OS yesterday). OS X 10.3.7
> Server, PostgreSQL 8.0RC1. Basically, I did a pg_dump, stopped the
> server and then tried to start it again.
Fascinating. As far as I can tell on my machine, 10.3.7 did not change
the kernel IPC limits. So if it's not working for you guys that would
suggest that 10.3.7 added some new background usage of IPC resources,
which in combination with the PG postmaster exceeds the same-as-it-ever-
was kernel limit.
If ipcs worked then we'd have some chance of investigating this, but OS
X doesn't provide ipcs. (Thank you Apple ... not)
FWIW, my installation of PG on OS X defaults to
max_connections = 50
shared_buffers = 300
because values higher than that exceed the default kernel limits.
It looks like yours has 100/1000 --- did you hand-modify that? Or maybe
you hand-modified the kernel limits? Another possible explanation is
that the 10.3.7 update overwrote any local changes you'd made to the IPC
limits.
regards, tom lane
On Dec 17, 2004, at 11:10 PM, Tom Lane wrote: > > Fascinating. As far as I can tell on my machine, 10.3.7 did not change > the kernel IPC limits. So if it's not working for you guys that would > suggest that 10.3.7 added some new background usage of IPC resources, > which in combination with the PG postmaster exceeds the > same-as-it-ever- > was kernel limit. > > If ipcs worked then we'd have some chance of investigating this, but OS > X doesn't provide ipcs. (Thank you Apple ... not) > > FWIW, my installation of PG on OS X defaults to > max_connections = 50 > shared_buffers = 300 > because values higher than that exceed the default kernel limits. > > It looks like yours has 100/1000 --- did you hand-modify that? Or > maybe > you hand-modified the kernel limits? Another possible explanation is > that the 10.3.7 update overwrote any local changes you'd made to the > IPC > limits. > > regards, tom lane > > I dropped the shared_buffers from 300 (the number determined by initdb) to 200 and I am now able to start the server. Tim
> It looks like yours has 100/1000 --- did you hand-modify that? Or maybe > you hand-modified the kernel limits? Another possible explanation is > that the 10.3.7 update overwrote any local changes you'd made to the IPC > limits. All the recent OS X .x updates have replaced /etc/rc. For all I know they may always have done so, but of course prior to 10.3 we didn't have to modify /etc/rc directly. -- Scott Ribe scott_ribe@killerbytes.com http://www.killerbytes.com/ (303) 665-7007 voice
Scott Ribe <scott_ribe@killerbytes.com> writes:
>> It looks like yours has 100/1000 --- did you hand-modify that? Or maybe
>> you hand-modified the kernel limits? Another possible explanation is
>> that the 10.3.7 update overwrote any local changes you'd made to the IPC
>> limits.
> All the recent OS X .x updates have replaced /etc/rc. For all I know they
> may always have done so, but of course prior to 10.3 we didn't have to
> modify /etc/rc directly.
Bingo. So I didn't see any change in behavior, because I hadn't edited
/etc/rc on my machine; the complainants are probably those who had
edited /etc/rc to raise the kern.sysv limits.
I'll add something to the Admin Guide pointing out that OS X updates are
likely to overwrite any manual changes to /etc/rc.
regards, tom lane
On 12/18/04 11:03 AM, "Scott Ribe" <scott_ribe@killerbytes.com> wrote: > All the recent OS X .x updates have replaced /etc/rc. For all I know they > may always have done so, but of course prior to 10.3 we didn't have to > modify /etc/rc directly. You shouldn't be modifying /etc/rc directly anyway. Create a startup script in /Library/StartupItems, or /etc/mach_init.d. I believe the latter is new with 10.3 and is now the preferred method. Granted, modifying /etc/rc is a lot easier, but you pay for it later when an update wipes out your changes and you beat your head against the wall trying to find the problem. Wes
Wes <wespvp@syntegra.com> writes:
> On 12/18/04 11:03 AM, "Scott Ribe" <scott_ribe@killerbytes.com> wrote:
>> All the recent OS X .x updates have replaced /etc/rc. For all I know they
>> may always have done so, but of course prior to 10.3 we didn't have to
>> modify /etc/rc directly.
> You shouldn't be modifying /etc/rc directly anyway.
*Tell* us about it. Apple used to have a more reasonable method for
setting the SysV IPC parameters, but AFAICT you have to hack /etc/rc.d
now; anyplace else runs too late to affect them.
regards, tom lane
> You shouldn't be modifying /etc/rc directly anyway. Create a startup script > in /Library/StartupItems, or /etc/mach_init.d. I believe the latter is new > with 10.3 and is now the preferred method. Granted, modifying /etc/rc is a > lot easier, but you pay for it later when an update wipes out your changes > and you beat your head against the wall trying to find the problem. Startup items can no longer change the sysv kernel settings. I forget whether that is a 10.2 change, or a 10.3 change, but setting them in a startup item has no effect and hasn't for a pretty long time. I was not aware of /etc/mach_init.d, a quick glance at the docs make it obvious that it runs earlier than SystemStarter, looking at /etc/rc shows that it runs not that much later than the normal settings of the sysv parameters. Are you sure changing sysv kernel parameters at that point will work? -- Scott Ribe scott_ribe@killerbytes.com http://www.killerbytes.com/ (303) 665-7007 voice