Re: [HACKERS] FreeBSD problem under heavy load

From: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
To: pgsql-hackers(at)hub(dot)org
Subject: Re: [HACKERS] FreeBSD problem under heavy load
Date: 1999-12-08 09:17:05
Message-ID: 19991208181705H.t-ishii@sra.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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
>
> ************

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-12-08 10:57:53 Re: [BUGS] uniqueness not always correct
Previous Message Tom Lane 1999-12-08 08:33:36 Re: [HACKERS] Multibyte in autoconf