A performance upgrade

[Lindsay Snider]

> Who said anything about putting stuff other than "working" files into
> tmpfs? My assumption (and that's all it is, at this point) would be that MS
> puts its copy of the message into incoming (which we all agree is safe  to
> keep in tmpfs), and that *if* SA routines cause files to be put into /tmp
> (a big "if", in my mind), then those files are derived from the file MS

Here is a snippet out of the 'USAGE' doc that comes with SA 2.60
---------------------------------------------------------------------------------------------------
  - SpamAssassin now uses a temporary file in /tmp (or $TMPDIR, if that's
    set in the environment) for Pyzor and DCC checks.  Make sure that this
    directory is either (a) not writable by other users, or (b) not shared
    over NFS, for security.
---------------------------------------------------------------------------------------------------

> keeps in the incoming directory.  And as such, those files are also safe to
> lose in the event of a system crash.
>
> Having not checked through the code at all, nor profiled a running MS/SA
> process, I have no idea whether MailScanner's use of the SA modules causes
> files to be created in /tmp, but IF it does (as Lindsay's post suggests),

You can see the spamassassin files created in /tmp.  On a decently busy 
machine, ls -al /tmp/sa.* and cat /tmp/sa.* frequently shows files.  They are 
of the format sa.[proc id].[random characters].  You can see this name being 
built on line 2545 of lib/Mail/SpamAssassin/PerMsgStatus.pm.

> then it seems reasonable (IMO) to speed things up by creating those files
> in some other location that can be mounted as tmpfs instead.

I agree, it seems that since sa is running during the mailscanner process, the 
original files still reside in the mqueue.in and are thus safe.

<TF>What's the name of the env variable?

It uses either $TMPDIR or $TMP then defaults to /tmp

<TF>When you say you tried setting it in the init script, did you remember to
<TF>export it?

Yeah, I added: 
TMPDIR=/dev/shm
export TMPDIR

If you examine the parent process during runtime, the parent MailScanner has 
an environmental variable set for TMPDIR.  If you examine a child however, it 
has no environmental variables set.  I'm not familar enough with 
MailScanner's code or perl forking to know why this is happening.

-lindsay
<snip'd>