Re: was there a change in FreeBSD SHM implementation from 4.4 to

On Wed, 10 Jul 2002, Vivek Khera wrote:

> I have a dual cpu box with 2GB RAM dedicated to running Postgres.
> Last week, I upgraded FreeBSD from 4.4-STABLE to 4.6-RELEASE-p1. When
> I went to restart postgres, it complained that it could not allocate
> the shared memory segment. I'm running Postgres 7.2.1.
>
> For those familiar with postgres, I was using shared_buffers=100000
> with 4.4, but had to back that down to 32000 for 4.6. This is
> obviously impacting performance...
>
> The kern.ipc.* settings have not changed. In my /etc/sysctl.conf
> file, I set
>
> kern.ipc.shmmax=268435456
> kern.ipc.shmall=65535
> kern.ipc.shm_use_phys=1

I do not know why your settings worked in 4.4-STABLE but
4.6-RELEASE behaves correctly.
If you use standard 8K tuple then shared_buffers=100000
means 100,000*8192=819,200,000 bytes.
You set kern.ipc.shmall=65535, so whole shared memory can be no
more then 65535*4096=268,431,360 bytes.
When you set shared_buffers=32000 then you ask for 262,144,000 bytes
and it's worked.

> With FreeBSD 4.6, I even upped the shmmax to 1073741824 to no avail.
> I also set this in the kernel (so as to eliminate any issues with
> setting it at boot time).
>
> However, it does produce a most peculiar error message when running
> postgres:
>
> -- cut here --
> IpcMemoryCreate: shmget(key=5432001, size=665346048, 03600) failed: Cannot allocate memory
>
> 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 665346048 bytes), reduce
> PostgreSQL's shared_buffers parameter (currently 80000) and/or
> its max_connections parameter (currently 48).
> -- cut here --
>
>
> Now, by my arithmetic, 665346048 is certainly less than 1073741824 by
> quite a bit.

Did you up shmmax or shmall ?
You need also increase shmall to 262144.

Igor Sysoev
http://sysoev.ru