From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | pgsql-hackers(at)hub(dot)org |
Subject: | FreeBSD problem under heavy load |
Date: | 1999-12-08 08:26:14 |
Message-ID: | 19991208172614V.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-12-08 08:33:36 | Re: [HACKERS] Multibyte in autoconf |
Previous Message | Tom Lane | 1999-12-08 08:23:52 | Re: [HACKERS] Raising funds for PostgreSQL |