Jake Vickers wrote:
On 07/10/2010 08:33 PM, Eric Shubert wrote:
David Milholen wrote:
Hi All,
Jake this may be your territory but anyways I am wanting to add a
small virtual drive for doing my clam scans.
Not sure where I should begin.
Thanks
---Dave
---------------------------------------------------------------------------------
I think you're meaning to make a tmpfs for the simscan work area,
which is used for clam and spamassassin scanning.
I believe you simply want to add a tmpfs definition for
/var/qmail/simscan in your /etc/fstab file, like so:
tmpfs /var/qmail/simscan tmpfs
size=256M,nodev,noexec,noatime,uid=clamav,mode=750 0 0
(all on one line)
The size you use should be appropriate for your system, which depends
on what you have available and how much scanning is typically done
concurrently.
You can reboot to make it effective, or I think you alternatively stop
qmail, then make sure that /var/qmail/simscan/ is empty, then make a
backup of fstab, then add the above line to fstab, then
# mount /var/qmail/simscan
# service qmail start
Having said all that, I'm not sure there's a whole lot to gain by
doing this in a typical configuration. I realize that Jake has seen
significant performance improvements with this in the past, but I
believe it also depends on how your kernel/system is tuned. On the
systems I've seen, the simscan work files are usually already still
cached, so putting them in a tmpfs doesn't gain anything significant.
While it does save physical i/o of the files, with asynchronous i/o
that is typically not a bottleneck. The only way I can see that this
change could improve performance is if the kernel is deciding not to
cache these files (for whatever reason), and/or asynchronous i/o is
not installed. It will however reduce your overall i/o a bit regardless.
YMMV. Please let us know what you find.
Ahh, never mind on getting the video back up, Eric let the cat out of
the bag.
In the 50+ systems I tested (none being virtual, all physical machines)
there was anywhere from 30%-300% performance increase in scan times. I
never tested this on virtual machines because I've only ever used VMs
for low end systems, non-production, or backup servers. Never put
anything "important" on them myself.
These were all stock kernels, supplied by the upstream vendor, using
ext3 and xfs filesystems.
On my personal system (the one QMT's mail runs on), scan times went from
1.3 seconds to <.3 seconds on average.
---------------------------------------------------------------------------------
I don't doubt Jake's results. I wonder though why I'm not seeing any
improvements. The systems I've seen are nearly all VMs though, and lower
volumes. I don't know of a reason why VMs would be any different in this
regard, though I could be missing something.
David (and others who may do this), please take note of your scan times
before and after applying this, and report your results. Scan times are
easy to obtain from either the smtp or spamd logs using qmlog:
# qmlog -g CLEAN smtp
# qmlog -g clean spamd
The spamd numbers appear to be easier to read, but they don't include
clam scanning time.
--
-Eric 'shubes'
---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
If you need professional help with your setup, contact them today!
---------------------------------------------------------------------------------
Please visit qmailtoaster.com for the latest news, updates, and packages.
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
