Re: [HACKERS] FreeBSD problem under heavy load

Note that same phenomen happens on current too.
--
Tatsuo Ishii

> I seem to run into a serious problem. With 6.5.x + FreeBSD 3.2, I get
> a core under heavy load (16 or more concurrent users). FreeBSD 2.2.x
> seems more stable but soon or later same thing happens. Examing a
> core, I found it segfaulted in hash_search(). It was not possible to
> get more info having a -g compiled backend becasue it did not fail if -
> g was given. It is likely that random memory corruptions occured. It
> is also reported by a user that he often sees:
> 
>     NOTICE:  LockReplace: xid table corrupted
> 
> Note that these problems never happen on Linux (even running 128 users
> are ok on Linux). Only FreeBSD is suffered as far as I can see(not
> sure about other *BSD). Increasing shmem or semaphore never helps.
> 
> How to reproduce the problem:
> 
> 1) obtain pgbench source from
> ftp.sra.co.jp/pub/cmd/postgres/pgbench/pgbench-1.1.tar.gz
> 
> 2) unpack the archive and run configure
> 
> 3) edit the first line in Makefile
> 
> POSTGRESHOME = /usr/local/pgsql
> 
> 4) make. you will get an executable "pgbench" there.
> 
> 5) make a fresh DB (suppose it is "test")
> 
> 6) initialize DB
> 
> pgbench -i test
> 
> this will take for a while
> 
> 7) run the test
> 
> pgbench -n -c numeber_of_concurrent users test
> 
> I see problems with numeber_of_concurrent users ~ 16 or more.
> 
> Here are my shmem settings:
> 
> shminfo:
>         shmmax: 41943041        (max shared memory segment size)
>         shmmin:       1 (min shared memory segment size)
>         shmmni:      32 (max number of shared memory identifiers)
>         shmseg:       8 (max shared memory segments per process)
>         shmall:   10240 (max amount of shared memory in pages)
> 
> seminfo:
>         semmap:     40  (# of entries in semaphore map)
>         semmni:     32  (# of semaphore identifiers)
>         semmns:    256  (# of semaphores in system)
>         semmnu:     30  (# of undo structures in system)
>         semmsl:    256  (max # of semaphores per id)
>         semopm:    100  (max # of operations per semop call)
>         semume:     10  (max # of undo entries per process)
>         semusz:     92  (size in bytes of undo structure)
>         semvmx:  32767  (semaphore maximum value)
>         semaem:  16384  (adjust on exit max value)
> 
> Any thoughts?
> --
> Tatsuo Ishii
> 
> ************