On Wed, 2009-02-18 at 02:38 +0800, W B Hacker wrote:
> Richard Pitt wrote:
> > In my experience this is almost always a load issue.
> >
> > I've settled on putting the database in /dev/shm - i.e. RAM disk
> >
> > there is no major penalty for losing this database - on reboot for
> > example - the system will simply rebuild it
> >
> > Following is in my /etc/init.d/exim startup file (I run Red
> > Hat/CentOS/Fedora - YMMV)
> >
> > ---------------
> > dev_shm() {
> > # push the db into /dev/shm
> > if [ -d /dev/shm/db ]
> > then
> > echo "using old /dev/shm/db directory"
> > else
> > mkdir -p /dev/shm/db
> > chown exim.exim /dev/shm/db
> > chmod 750 /dev/shm/db
> > mkdir -p /var/spool/exim
> > fi
> > cd /var/spool/exim
> > rm -r db
> > ln -s /dev/shm/db db
> > ----------------
> >
> > The dev_shm() function is called upon each startup
> >
> > works for me on VERY heavily loaded systems.
> >
> > richard
>
>
> *trimmed*
>
> That could be taken a step further;
>
> - have cron set up for odd-day-even day or twice a day... whatever.
>
> - create the new, but empty one
>
> - move a link from old, full space to new, empty space.
>
> - destroy the old one
>
> Rewind 'X' time later.
>
> Bill
The problem with this is that you lose the retry info. Not a big issue
but losing it may cause retry to be faster on enough items in the spool
on a heavily loaded system that the result may not be good. On systems
with heavy outbound loads the result is sometimes to annoy the receiving
sites with the extra burst of traffic trying to send items that have for
some reason not gone through initially (grey-list, quota, etc.)
I note that losing the retry info is not an error situation - but it is
there for a reason so keeping it is a good idea all in all.
As long as the system has enough RAM that the SHM does not get pushed
out to disk due to swapping things are fine. Of course having enough RAM
to avoid swapping on any heavily loaded system is a must.
I also have a monitor that watches RAM use and deals with it by killing
off exim processes (usually held due to receiving site holding
connections open) rather than letting the kernel randomly kill
processes.
richard
>
>
--
Richard C. Pitt Pacific Data Capture
rcpitt@??? 604-644-9265
http://blog.pacdat.net www.pacdat.net
PGP Fingerprint: FCEF 167D 151B 64C4 3333 57F0 4F18 AF98 9F59 DD73
