Hello, The postgres setup I'm referring here is the same that Dave Logan replied about earlier, fyi. We have no postgres experts on staff, just Dave and I, and we do what we can. As of 7.4, unbounded growth problems have gone away and with some trial and error, we've not had any major database-induced issues in some time.
> I have set my shared memory space at 512M, I would like to > go to more, but PostgreSQL doesn't seem to do anything with > the extra RAM. # cat /proc/sys/kernel/shmall 16777216 # cat /proc/sys/kernel/shmmax 67108864 > Admittedly it seems like some of the selects that dbmail > does take quite a long time to return. One of the worst is > the dbmail-util check for incorrect is_header flag. That > seems to take about 3 hours. I don't think it's ever found > a problem looking in my log, so should I not bother to do this? I'm pretty sure that's intended to be a run-once type feature for upgrading from a previous dbmail install that didn't support is_header. All new messages that get inserted should have that set properly. > What are you setting your shared_buffers at (mine is 40000)? shared_buffers = 3072 > Do you modify any of the items like FSM and such in the config? Yes; if you're having to run vacuum full to reclaim space, you probably need to increase fsm settings and/or vacuum more frequently. We have: max_fsm_relations = 100 max_fsm_pages = 5000000 A few other comments: if you're comfortable running development releases, 2.1 should give you better performance. Also, Dave tracked down a specific pop3 UPDATE query that was inducing a huge load on our system that I believe was fixed in at least 2.1 svn, if not all three branches. You might update to the latest svn (in 2.0 or 2.1), and see if this issue still exists (check the source, level 5 logs or postgres log for what updates are being run). Refer to this thread: http://mailman.fastxs.net/pipermail/dbmail-dev/2005-October/007594.html and this bug: http://www.dbmail.org/mantis/view.php?id=278 -- Jesse Norell - [EMAIL PROTECTED] Kentec Communications, Inc.
