> If these emails have been successfully sent,
> why ARE they showing back up in /var/amavis
> like this in the first place?
Since you are clued enough to know that search-fu exists, I'm guessing
that my thoughts are obvious and already tried...
It is not impossible that somebody clueless enough to send 63M
attachments to all her friends may not be on top of their delivery
status. Perhaps not all messages have not successfully been sent and are
hanging in the exim's queue. Until amavis says that the msgs have been
delivered, exim will keep trying.
It might be worth looking exim's queue managing tools..
It might also be worth setting the maximum message size exim will accept...
Daniel Bentley wrote:
My search-fu is apparently weak, as I couldn't find this answer elsewhere.
Simply put, what exactly is the purpose of subdirectories in
/var/amavis, mainly in the form like
'/var/amavis/amavis-20050930T192802-19231'? It appears to be the
location where amavis temporarily stores emails (raw, and separated into
parts) for processing. What is the average duration for these
sub-directories?
The reason: someone thought it'd be a brilliant idea to put a series of
emails with images through email. We're talking 63M file attachments to
-each- mail, and enough of these emails to total up to around 2.9 -GIG-.
We noticed that the email server was acting particularly sluggish, and
'top' revealed CPU usage of up to mid 90% and amavisd (running
amavisd-new 2.3.1, spamd, uvscan, postfix, on Mandrake LE 2005 (aka.
10.2)) taking 500-600M of combined memory and swap. In trying to figure
out where these problems were coming from, I visited the sender of all
the files (I hate .bmp files more than ever now... -.- ), and she
informed me that all emails had been sent, and had been received at the
other end. So I thought, "Okay, I can clean those directories out of
/var/amavis, maybe that'll help." As there were other sub-directories
from 2004, I figured amavis might not always clear out temp email
storage in /var/amavis/amavis-{date}T{number}-{number} sub-directories.
So I stopped amavis and postfix, and wiped these sub-directories from
/var/amavis.
Only... the majority of these emails (sent Mon. and Tues., wiped end of
the working day on Tues.) started showing up again on Wed. o.o; Same
emails, same dates for the bodies as evidenced in email.txt files,
showing up aprox. every 30 min. So I wiped these sub-dirs again earlier
today (Thurs.). In the past few hours, they've been coming back AGAIN.
@.@
When I initially cleaded out /var/amavis, system usage by amavis and
overall performance went back to normal. Each time one of these
sub-directories shows up in /var/amavis again, there's a corresponding
jump in CPU usage, often back up in the mid-90% range, and the amavisd
process seems to continually grow in memory usage as more of these
emails come back from the dead.
Any thoughts/ideas? Am I only exacerbating the problem by fiddling with
these sub-directories in /var/amavis? If these emails have been
successfully sent, why ARE they showing back up in /var/amavis like this
in the first place?
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
AMaViS-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
AMaViS-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/
