☰

由于 W3SVC 不断崩溃而导致的 Exchange 问题

tag-icon • tag-icon exchange smtp
由于 W3SVC 不断崩溃而导致的 Exchange 问题

我们有一个前端 MS Exchange 2003 服务器，最近有人开始抱怨电子邮件无法送达。仔细查看日志后，我们发现了以下错误消息：

>     Event Type:   Error
>     Event Source: Service Control Manager
>     Event Category:   None
>     Event ID: 7031
>     Date:     6/4/2009
>     Time:     11:08:00 AM
>     User:     N/A
>     Computer: <Server>
>     Description:
>     The IIS Admin Service service terminated unexpectedly.  It has done
>     this 39 time(s).  The following
>     corrective action will be taken in 1
>     milliseconds: Run the configured
>     recovery program.

我们发现MS KB 文章 Q304166并且能够通过逐个删除它们并重新启动服务来确定 Exchsrvr\Mailroot\vsi 1 文件夹中的哪条消息导致了问题。

造成这一切混乱的电子邮件是一个 200K 大小的 PDF 文件，它被发送到 3,500 个地址。Exchange 为何会受到如此严重的破坏？我知道 3500 人是一个很大的数字，但我猜 SMTP 服务器会限制连接，并在晚上甚至几天内慢慢发送这封电子邮件。

我的问题：

Exchange 中是否有方法可以确定最大 SMTP 负载？其他人是否也看到了同样的反应，还是我们应该寻找服务器上的错误配置？

当/如果我们需要再次向一个大组发送消息时，有没有办法判断服务器在一批消息中可以处理多少消息，或者我是否需要使用 Perfmon 并开始测试以查看它如何处理 100,250,400 等？

答案1

这不是容量问题——这是错误。应用程序中任何未处理的异常都是错误。（千万不要让开发人员告诉你不是这样的。）

您有最新的补丁吗？

编辑：听起来你发现了一个错误，如果你能重现这个问题的话。我不知道如何向微软报告这样的错误，但可能需要报告。

答案2

这肯定是个错误。Exchange 2003 中的 SMTP 引擎实际上是作为一组扩展构建的，由 IIS SMTP 引擎加载和运行。如果 w3svc 崩溃，很可能是因为邮件格式错误（包括地址错误或收件人服务器行为异常）——而不是因为文件大小或收件人数量产生的负载。

如果您想进一步测试，您可以让用户将消息发送给原始 3500 个子组中的较小子组，以缩小问题范围。

答案3

服务器不应该因此崩溃。我会打电话给 MS 进行跟进，我对 MS 支持有很好的体验，这非常值得。如果您向 MS 支付了票款，而问题最终被证明是他们的错（看起来是这样），他们会退还票款。

附注：您可以从 MS 购买 Technet Plus，其费用低于 2 次支持事件的费用，并且 Technet Plus 还包括 2 次支持电话以及测试软件和管理新闻组的访问权限。

相关内容