Re: shared memory
От | Bruce Momjian |
---|---|
Тема | Re: shared memory |
Дата | |
Msg-id | 200006011939.PAA24084@candle.pha.pa.us обсуждение исходный текст |
Ответ на | shared memory ("John Henderson" <jrh@is.com.fj>) |
Список | pgsql-general |
Was this ever resolved on BSDI and PostgreSQL? [ Charset ISO-8859-1 unsupported, converting... ] > Hi y'all, > Here is the latest update. > > The problem is with PostgreSQL allocating shared memory in BSD/OS 3.0. > The system has 128M of RAM and 262M of swap. > Currently postgres starts as: > > su -l postgres -c '/usr/local/pgsql/bin/postmaster -i -d 3 -B 887 -o "-eF > -S 1024" >> /var/log/postgres 2>&1 &' > > without problems. However, try to start with -B 1024 (which allocates 1024 > of 8K blocks used for shared memory buffers) > and the following is logged: > > FindExec: found "/usr/local/pgsql/bin/postgres" using argv[0] > binding ShmemCreate(key=52e2c1, size=8852184) > IpcMemoryCreate: shmget failed (Invalid argument) key=5432001, size=8852184, > per > mission=600 > FATAL 1: ShmemCreate: cannot create region > proc_exit(0) [#0] > shmem_exit(0) [#0] > exit(0) > > OK, so we have to get BSD/OS to allocate more shared memory. > > Note that the actual postgres error is related to calloc and malloc and > something else that specifically tells me to increase -B. > When -B is increased to 1024 the daemon dies as soon as it starts. The error > is not with memory usage but with memory allocation. > > In this case setting > > #options SYSVSHM > #options SYSVSEM > #options SYSVMSG > > have no value. In some older version of BSD these would tell the compiler to > include the optional shared memory header files which are automatically > included in this version of BSD so these configs are redundant. > > In previous attempts I have mucked with: > #options "KMEMSIZE=\(16*1024*1024\)" > #options "DFLDSIZ=\(32*1024*1024\)" > #options "DFLSSIZ=\(4*1024*1024\)" > #options "SOMAXCONN=128" > #options "MAXDSIZ=\(256*1024*1024\)" > and made them available to the shell with ulimit. All to no avail. > Currently I use the default values from BSD so my front end processes get: > moe:~ $ ulimit -a > core file size (blocks) unlimited > data seg size (kbytes) 32768 > file size (blocks) unlimited > max memory size (kbytes) 126280 > stack size (kbytes) 32768 > cpu time (seconds) unlimited > max user processes 64 > pipe size (512 bytes) 2 > open files 128 > virtual memory (kbytes) 65536 > > The backend of PostgreSQL is booted from a script /etc/rc.postgres with > ulimit -d unlimited just before the daemon is started so I am assuming that > postgres gets lots of data space. > (In fact I have checked this out and it is true). > > Adjusting > #options "SHMMAXPGS=4096" > has no effect. The BSD default seems to be 2048 pages and pages are 4K. > That means the BSD default is around 8M which is just above my -B 886 (*8 = > 7.5M) allocation for shared memory. > Allowing the system to soak up some shared mem for whatever reason I would > say this is the variable that I have to adjust. > So why doesn't it adjust!!?? > Sin'ichiro M from sdi-users suggested it might be related to semaphore > identifiers: > but when I used a config from Daniel Kalchev > options "KMAPENTRIES=4000" #prevents kmem malloc errors > options "SHMMAXPGS=32768" > options "SHMMNI=400" > options "SHMSEG=204" > options "SEMMNS=600" > Nothing different happens. > > Finally there is a tip from Bruce that I need to increase SYSPTSIZE, the > number of dynamically allocated page tables for the kernel. > SYSPTSIZE is discovered by > bpatch -r sysptsize > In my case 28. > You can adjust this directly into the finished kernel by > bpatch sysptsize 40 > Don't forget to reboot so that the change becomes effective. > This should actually allow me to allocate 12*4 = 48 extra Megs of shared > memory. > Guess what, no difference. > > Thanks to anyone who has read this far. > Here are some questions: > 1) What part of memory do shared memory buffers get loaded into: kernel? > data? This is to determine which of the ulimitable variables to concentrate > on. > 2) Is it universally agreed that SHMMAXPGS is the key variable to address > and we just need to figure out what is related directly to it? > 3) I don't have a clue - do you? > Best, > John Henderson > > > > > > ************ > > -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
В списке pgsql-general по дате отправления: