Назад | Перейти на главную страницу

Проблемы с Exchange, потому что W3SVC продолжает давать сбой

У нас есть внешний интерфейс MS Exchange 2003 Server, и в последнее время люди начали жаловаться на то, что электронные письма не доставляются. При внимательном рассмотрении журналов мы обнаружили это сообщение об ошибке:

>     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 вызывало проблему, удалив их по одному и перезапустив службы.

Электронным письмом, которое вызвало весь этот хаос, был файл PDF размером 200 КБ, который был отправлен по электронной почте на 3 500 адресов. Почему биржа так сильно испортилась? Я понимаю, что 3500 - это большое количество людей, которым нужно отправлять электронную почту, но я мог бы предположить, что SMTP-сервер ограничивал бы соединения и медленно отправлял это письмо в течение вечера или даже пары дней.

Мой вопрос:

Есть ли способ в Exchange определить максимальную нагрузку SMTP? Видели ли другие такую ​​же реакцию, или нам следует искать неправильную конфигурацию на сервере?

Когда / если нам снова потребуется отправить в большую группу, есть ли способ измерить, сколько сервер может обработать за один пакет, или мне нужен пользователь Perfmon и просто начать тестирование, чтобы увидеть, как он обрабатывает 100,250,400 и т. Д.?

Это определенно ошибка. Механизм SMTP в Exchange 2003 фактически построен как набор расширений, которые загружаются и запускаются модулем SMTP IIS. Если w3svc дает сбой, это, скорее всего, из-за искаженного сообщения (включая возможность неправильного адреса или неверного сервера получателя), а не из-за нагрузки, создаваемой размером файла или количеством получателей.

Если вы хотите проверить это дальше, вы можете попросить пользователя отправить сообщение меньшим подгруппам исходного 3500, чтобы сузить проблему.

Это не проблема емкости - это ошибка. Любое необработанное исключение в приложении - это ошибка. (Никогда не позволяйте разработчику говорить вам иначе.)

Вы в курсе патчей?

Изменить: Похоже, вы нашли ошибку для меня, если вы можете воспроизвести проблему. Я понятия не имею, как на самом деле сообщить о такой ошибке в Microsoft, но, вероятно, об этом нужно сообщить.

Сервер не должен был на этом падать. Я бы позвонил в MS для уточнения, у меня был большой опыт поддержки MS, и это того стоит. Если вы платите за билет с помощью MS, и проблема оказывается их ошибкой (как это выглядит), они возвращают билет.

В качестве примечания вы можете приобрести technet plus у MS, который стоит меньше, чем стоимость 2 обращений в службу поддержки, а technet plus включает 2 звонка в службу поддержки плюс доступ к тестируемому программному обеспечению и управляемым группам новостей.