Daniel 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? See http://www.ijs.si/software/amavisd/#faq-gen This may explain most everything. > 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-. In the future I would limit the allowed message size in postfix: message_size_limit = 15728640 # 15MB for example > 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? There must be timeout/timing issues. I would look through the logs for evidence of this. I guess Postfix does not think the transaction has been completed (I'm thinking that when it first sent a message to amavisd-new, it did not get a reply from amavisd-new in a timely fashion). I'm not sure, but I suppose it's possible amavisd-new just kept humming along, and eventually delivered the message back to Postfix (on the output side of amavisd-new), but Postfix had given up on a reply from amavisd-new some time ago (on the input side). Following the sequence of events in the logs would be interesting. Raise $log_level to gain more details if needed. To end the agony, I would look in your log to obtain the postfix queue_id's of the messages that are stuck in the deferred queue (the ones that are From: the offending sender, and To: the ones she sent them to, and have timed out). Use the mailq command to help with that. Then I would delete them from the deferred queue, one by one. postsuper -d queue_id Gary V ------------------------------------------------------- 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/
