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.
|
