-----Original
Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of Matt
Sent: Tuesday,
January 25, 2005
10:25
AM
To: Declude.JunkMail@declude.com
Subject: Re: [Declude.JunkMail]
Overflow directory and a note about Windows 2003 DNS
Well, I can say definitively that the hotfix
worked. My DNS process is averaging less than 1% of CPU now during
full traffic and 12 hours after the last restart with a very heavy config
and well over 100,000 messages a day. I saw an article on MS's site
showing that their DNS server could handle 9,500 requests per minute running
on a single 733 MHz processor (plus other activity), and I'm not doubting
that now.
The backups in Declude/IMail were definitely being caused
by the sluggishness of the DNS queries against this server, so that problem
is now fixed as well.
With this cleared up, it also appears that the
server as a whole is running faster than the previous box despite the
downgrade in disk I/O (all other things being the same exact
platform). I can't be certain as yet, but it does appear to be about
30% more efficient so far. Windows 2003 might well be worth the
money...after Service Pack 2 finally hits the
streets.
Matt
Matt wrote:
Thanks Darrell, that definitely sounds like it's the
culprit:
http://support.microsoft.com/?kbid=830381
This
didn't come up in my searches because it is described so generically and I
was searching for things like processor utilization and memory leaks.
I like the part where the describe the workaround:
"There is no suggested workaround. To minimize the effects of the problem,
periodically stop and then restart the DNS Server service."
The
hotfix has been requested, I'll update the list as to whether or not this
works. It certainly sounds
promising.
Matt
Darrell ([EMAIL PROTECTED])
wrote:
Matt,
I seen a few articles about memory leaks in Win2K3 DNS. One specific one
comes to mind about a leak when adding zones via scripting. Another one
that we ran into (internally) was KB 830381. (Server Responsiveness
Degrades and Queries Time Out When You Run the DNS Server Service).
Darrell
-------------------------------------------
Check out http://www.invariantsystems.com for utilities for Declude And
Imail. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG
Integration, and Log Parsers.
----- Original Message -----
From: "Matt" <[EMAIL PROTECTED]>
To: <Declude.JunkMail@declude.com>
Sent: Monday, January 24, 2005 10:31 PM
Subject: Re: [Declude.JunkMail] Overflow directory and a note about Windows
2003 DNS
I found MaxQueProc in the registry and changed that to 60. There is no
GUI config for this option.
I also looked at the issue with MS DNS 2003. After a restart of DNS,
utilization dropped from an average of about 25% to under 1% (I had it
in performance monitor)...but then over the next couple of hours, it has
crept back up to 10%. I have watched it enough to verify that it's
utilization grows consistently over time. Disabling the EDNS thing has
no effect. I've found nothing really telling about this in Google, but
it looks like a classic memory leak. This installation was fresh and
there is hardly anything installed on it. I would be a bit surprised to
see a memory leak in DNS go undetected/unfixed at this point. If anyone
else has experienced this, or can confirm my findings, please speak up.
I was intending on using this server for my Web hosting DNS, but this
may keep me from going there.
Matt
R. Scott Perry wrote:
You seemed to indicate that service launched processes count against
the threads...meaning that smtp32.exe launches declude.exe, which
launches F-Prot and McAfee. So would this count for 4 threads (not
according to Declude, but Windows/IMail)? What about Sniffer and
each external test that I have configured within Declude, would those
count as well?
Unfortunately, we are not aware of a way to determine if a process was
started by a service or not. Currently, Declude looks for
declude.exe, smtp32.exe, scan.exe, F-Prot.exe processes (and any
processes listed in the rarely used DAISYCHAIN option).
Note that SMTPD32.exe -- the IMail process/service that starts Declude
-- is just a single process, so it will only count once.
Message Sniffer and other external tests won't count, since Declude
doesn't specifically look for it (but it does indeed count as a
service-started process, and could cause the memory limit to be
reached). However, there would only be a maximum of one of them per
E-mail (since Declude runs the external tests in serial, not in
parallel).
I also re-read the following post by Sandy:
http://www.mail-archive.com/imail_forum@list.ipswitch.com/msg94576.html
It seems to indicate that there is no "thread limit", but something
else instead; a limit of "64 objects per thread".
That's not related here. The overflow issue deals with processes, not
threads. Processes are what are listed in the "Process" tab in the
Task Manager (such as one SMTPD32.exe process, 0 to 30 or so
Declude.exe processes, etc.). Each process can have from 1 to an
(almost) infinite number of threads.
I'm not sure how that might apply here. So if I am seeing overflow
with processing power to spare, I should be able to increase the
threads in IMail to a higher number than 60 in order to better
utilize my server's capacity. With memory utilization below 50%, it
doesn't seem like there is much risk in doing this, would that be
correct?
Anything referring to "thread" or "threads" in IMail settings is not
relevant to this (IMail v8 introduced one or more "thread" options).
Declude JunkMail looks at the MaxQueProc IMail registry setting (which
may also be an advanced setting in IMail Administrator, with a name
such as "maximum number of processes"). Any other settings are not
used.
-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.
---
[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.
