Good morning all,
I figured that I might save those that might respond some time...I found
and fixed the issue.
Turns out that the MS SMTP part of the metabase was still corrupt in
some way...not sure exactly how...and this was causing FTP of all things
to behave very, very slowly (while MS SMTP was operating normally).
After a lot of playing around with things I figured out that it was the
MS SMTP segment of the metabase that when enabled as it was originally
would cause FTP to drag, and I also found that stopping the MS SMTP
service would cause FTP to return to normal. Why??? Who really knows,
but when my metabase was corrupted, it was a corruption in the MS SMTP
portion of the file and somehow it is still bad (I'm thinking that my
backup copy that I restored had the error that eventually caused the
corruption).
Thanks,
Matt
Matt wrote:
I'm at wits end with this and I figured that I would put a feeler out
here to see if anyone has a clue as to what the source of my issue
might be.
My MSFTPSVC on one server suddenly has slowed to a crawl, i.e. 15 to
60 seconds from issuing a command to receiving a response. This even
happens with the FTP client on the same server going to 127.0.0.1. I
have also tested by installing a third-party FTP server on the same
box and that worked fine. There is nothing else that is remarkable
going on with that server, and I am unsure as to what precipitated the
issue, though one possibility is the last MS security rollout that
caused my metabase to become corrupted following the reboot back on
12/22. I fixed that with a copy from a backup and all seemed normal.
The corrupted metabase showed a block of random characters in the
middle of the XML file, and it occurred in the SMTP segment. The
current working metabase looks just fine, but I'm thinking that
whatever caused the corruption might have also corrupted some other
stuff that is affecting FTP. The release notes on those patches
didn't suggest anything related to the FTP service or TCP/IP.
I have tried many different things from uninstalling and reinstalling
the FTP service, removing the last two MS patches (and reinstalling
them), and a host of smaller tasks. I have run a rootkit detector and
I have real-time virus protection on the server, but that was just to
eliminate the very small possibility as the server is well firewalled,
completely patched, has only one regular RD user (myself), unnecessary
services are disabled, and I even stay away from often exploited
software such as Perl and PHP. There is nothing else abnormal on the
server that would suggest a bug or otherwise. Curiously this isn't
affecting the Web server or SMTP services that are also part of IIS
along with FTP.
One clue to the problem is that when I reset my router, FTP works at
full speed for maybe up to a minute. Although this makes no sense in
the purest sense, the same thing happens when using a client on the
same box FTPing to 127.0.0.1...the FTP will work at normal speed for a
short while when FTPing to 127.0.0.1 immediately following a router
reload. I am 99.9% positive that my network has nothing to do with
causing the issue, but this one thing suggests that there is some
interaction with TCP/IP and the FTP service that is contributing to
the issue. This makes me think that it is a bug with the IIS rate
limiting which requires QOS to be bound to the NIC, and maybe the
router resets are resetting the QOS/rate limiting, allowing it to
operate at full speed until it adjusts back to almost no throughput.
I have rate limiting turned on for both Web and FTP, but this is only
affecting FTP. I have tried turning off QOS and rebooting, but that
had no affect on the issue, yet the way that rate limiting works, it
seems to explain why a router reload causes things to work well for a
few moments before degrading again.
At this point my next try will probably be to uninstall and reinstall
all of IIS, but I was hoping that maybe someone around here has seen
this or a similar issue, or if there were any ideas about the possible
interaction with QOS and rate limiting gone bad, and how to reinstall
that part of Windows if possible. I would like to avoid rebuilding
this box, but I won't keep it running in the present state with an
unknown issue even though I could migrate to a third-party FTP server
and avoid the issue.
I would appreciate any glimmers of hope that anyone might have for me
on this :)
Thanks,
Matt
---
[This E-mail was scanned for viruses by Declude EVA 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 EVA 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.
