Hi,
 
we work with PostgreSQL 7.0.3 and FreeBSD (4.2 / 4.3).
the database is in production state, and daily heavy loaded.
 
i think our problems are similar to problems
described in :
http://fts.postgresql.org/db/mw/msg.html?mid=28871
 
recently, we have updated our kernel, according to this doc :
http://www.postgresql.org/idocs/index.php?kernel-resources.html
 
here the options we have tuned:
 
options         SHMALL=32768
options         SHMMAX=(SHMALL*PAGE_SIZE) 
options         SEMUME=40
options         SHMMAXPGS=32768
options         SHMSEG=256
options         SEMMNI=256
options         SEMMNS=512
options         SEMMNU=256
options         SEMMAP=256
 
 
everything looks working fine, but after 9 or 10 days
in production, some problems appeared :
 
sometimes each postmaster child stay in a strange state,
according to top, 'semwait' state.
running ipcclean clean all those children !   
 
sometimes, when the number of postmaster raise up to the limit,
we can't connect to the backend, we've got the message :
"psql: The Data Base System is in recovery mode"   
 
after a pg_ctl stop, the message changes into :
"psql: The Data Base System is shutting down"
 
but the database never shutdown ( or are we too impatient ?).
 
it appeared that the inactive memory raise, until
we'v got 10 megs of free memory, as described by
Alfred Perlstein.
after a reboot, everything looks fine but after 10 days of uptime,
the problem is the same.
 
we have just updated our FreeBSD kernel to 4.3.
is this update pertinent ?
 
are the selected values for the kernel options
speed up a memory leak problem ?
(the problems appeared faster since our kernel optimisation)

can an update of postgresql from 7.0.3 to 7.1.2 solve this
problem ?
the REAME.v7.1 talk about bug fixes on memory leak problem.
 
any experience, and/or advisory will be appreciated.
 
 
-- 
Matthieu Clavier
[EMAIL PROTECTED]

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://www.postgresql.org/search.mpl

Reply via email to