Scott,
Am I to assume a "first in, first out" type of scenario in the way that it handles the overflow?
I have my server set to 60 delivery threads, up from the default 30. Sandy I believe indicated that 64 was the limit due to the fact that IMail is not multi-threaded or something to that tune. My E-mail backup isn't bad at the moment, just occasional stuff at peak times up to about 100, although the other day when the processors were pegged due to my not having disabled the Indexing Service, I backed it up for about 45 minutes worth. I'm probably averaging about 60% utilization (hourly average) right now.
Right now we are deleting about 75% of all E-mail (using the DELETE action). I'm pretty sure that if we are reaching 60 threads, we are only doing so with the totality of messages and not just what we might deliver or ROUTETO/COPYTO. Counting the files in my spool, I am coming up measurably short of 60 Q*.SMD files while I see messages in the overflow (which happens every few minutes). It seems that this would represent the number of threads that are open, apart from what Declude has in overflow.
Does having Declude DELETE E-mail go against the thread total? Also, how should I confirm how many threads are being used by IMail just so that I can rule out the issue with not seeing 60 such files? Lastly, you indicated multiple things that can go against this number, am I to assume that Declude counts not what IMail is limited by (IMail threads), but instead it just uses this as a guide, so maybe increasing the number in IMail even higher, while it won't have an effect on IMail, it would cause Declude to not overflow, especially when there is processing power to spare?
Although I'm definitely moving from IMail, I fear hitting a wall before that actually happens. There is definitely more I/O and processor to spare on this box, but the overflow conditions happen every few minutes.
Thanks,
Matt
R. Scott Perry wrote:
Could you please let me know what condition causes E-mail to be left in the overflow directory, and exactly how Declude determines how/when to process such messages.
The short version is that the situation is handled better than if the overflow directory isn't used (many people don't get that).
The longer version is that Declude will move E-mail (actually, just the Q*.SMD file) to the overflow directory when Declude detects that there are more than X service-started processes (where X is 30, unless you have IMail set to use a different number of maximum processes). Those can be declude.exe, smtp32.exe, or AV processes.
Once this situation occurs, Declude will continue to move E-mails to the overflow directory until the number of service-started processes is less than X. At that point, when an E-mail arrives, Declude will start enough Declude processes to hit the limit of X (each of which scans a single E-mail).
-Scott
---
Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000.
Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection.
Find out what you've been missing: Ask for a free 30-day evaluation.
----
This outgoing message is guaranteed to be authentic by Message Level users.
Guarantee the authenticity of your email @ http://www.messagelevel.com.
---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
--- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
--- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
--- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
