Re: was there a change in FreeBSD SHM implementation from 4.4 to
От | Igor Sysoev |
---|---|
Тема | Re: was there a change in FreeBSD SHM implementation from 4.4 to |
Дата | |
Msg-id | Pine.BSF.4.21.0207102347280.67795-100000@is обсуждение исходный текст |
Ответ на | was there a change in FreeBSD SHM implementation from 4.4 to 4.6? (postgres trouble) (Vivek Khera <khera@kcilink.com>) |
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: