Как уменьшить или разделить нагрузку на почтовик.
 

Схема работы такая:
Есть AD с Эксченджем. Пользователи. Аутлк. Все работают с почтой. В обычном режиме.

Есть 1С. Которая автоматом, по определенным собитиям рассылает письма\отчеты\файлы через ЭКсчендж.
Ну т.е. есть учетка для 1С рассылки. Которая прописана в настройках 1С.
Рассылок от 1С в середине дня очень много, и они порой забивают целиком очередь на Эксчейндже.
Из-за этого порой медленно ходит почта для пользователей, как внутри компании (в локалке), так и снаружи.

Собственно вопрос. Понятно что можно поднять для 1с отдельный почтовик. И это самый логичный путь.
НО.....
Возможно если сделать отдельное хранилищие под ящики которые использует 1С и отдельный коннектор, это разгрузит почтовик?

Буду признателен за помощь\идеи\критику (обоснованную)

Благодарю!

под медленно- имею ввиду, что могут письма по 20-40 минут доставляться. Пока очередь вся от 1С сообщений не очистится.
Грешу на это.
Возможно- ошибаюсь.

Простой грамотный сайзинг может спасти. Надо еще понимать, в какой очереди повисают сообщения. Если это Mailbox Delivery, то возможно проблема в дисковой подсистеме., тогда нужно разносить нагрузку по разным физическим дискам. Если любая другая, то скорее всего упираетесь в CPU\RAM, тут не спасет отдельный коннектор (да он вообще ни от чего не спасет, на самом деле, это просто "нашлепка" к транспортному сервису, а categorizer один на сервер, будет так же забиваться). Плюс антивирусы могут вредить, если установлены на сервере Exchange. Добавьте в исключения из проверки каталоги с очередями, Exchange Bin и каталоги с базами\логами. поймать файловый антивирус там все равно ничего не сможет в силу особенностей работы Exchange, а вот вредить путем реагирования на изменения и попытки сканирования может изрядно.

И да, в момент, когда у вас пик нагрузки. попробуйте отправить письмо телнетом. Скорее всего получите insufficient system resources. Тогда читайте про механизм обратного давления: что это, когда включается, зачем и как бороться. Гуглить надо Exchange Back Pressure

Доброго дня!
А как точно определить Mailbox Delivery это или нет? я про подвисания в очереди писем.
Сейчас все ок, но скорее всего да, подвисает MapiDelivery кажется.

И да, у меня тоже подозрения на диски или на цпу. Дело в том что досталось все в наследство и вертится потчовик на виртуалке.
Т.е. это виртуальный хост с 26Гб памяти и виртуальным диском, т.е. физически диск один. И он в свою очередь в визору подключен по iSCASI с хранилища NAS Synology и qNAP. Причем оба НАСА не промышленного образца, ну т.е. скорее СОХО чем что то серьезное.
Я то же в первую очередь грешу на всю схему сразу. Так как на других проектах Эксчейндж всегда поднимал на отдельном железном севере и с быстрыми серверными САС дисками.

Есть какое либо стандартное, рекомендуемое решение по железу для развертывания Эксчейнджа? Ну например, проц не менее 8 ядер, памяти не менее 30Гб и диски не менее САС, причем разные базы на разных физических дисках.
Буду очен ьпризнателен.
Так как надо что то делать.
И скорее всего менят ьсхему и структуру целиком.

Ах да, все роли Эксчейнджа на одном сервере крутятся. База почтовых ящиков одна. На диске С. Там же и логи. Что вобщем то не правильно, ч точки зрения, что бы хранить на разных физических дисках.
Но так как в моем случае диски физически, их как бы нет. Они смапены по искази.

и да. антивируса на сервере с эксченджем нет

Я бы для начала точно определил, в чём затык, откуда тормоза. Недавно была похожая ситуация, письма по 40 мин ходили, там на E2010 стоял symantec endpoint protection и проблема была в нём. Удалили и всё сразу быстро заработало.

Я с вами полностью согласен. Вот и пытаюсь поймать причину. Антививруса нет. Уже хорошо.
В течении дня все ок. Но все начинается как только начинают активно работать с 1С и она начинает рассылать письма сотрудникам и клиентам.
Рассылает, под своей учеткой.
И вот в этот момент все встает.

И как определить в чем затык? Сегодня буду мониторить, и опробую вариант, предложенный Олегом Крыловым, выше. Про отсылку через телнет.

Павел, возможно посоветуете как то иначе определить в чем проблема?

MapiDelivery, MailboxDelivery, я путаюсь в терминах, т.к. они постоянно меняются, но суть одна - это доставка из транспортного конвейера в сторону баз данных. Т.е. запись в память и на диск.
Если дисковая подсистема хреновастенькая, как вы описываете, то попробуйте разделить нагрузку по шпинделям, т.е. дать больше одного физического диска. Exchange не любит жить в коммуналке, ему подавай отдельные диски для всего. Ну как минимум, я бы разделил системный диск и диск с базами\логами. Это может порешать проблему. Вообще в виртуализованном варианте у Exchange аппаратные требования процентов на 15-20 выше, чем если бы это была просто железка. Microsoft в своих PLA (Product Line Architecture) активно агитирует собирать инфраструктуры исключительно на железе (был доклад Бориса Лохвицкого на эту тему, очень клевый, где он рассказывает, что собирать все нужно на pizza-box, т.е. дешевых серверах 2U с встроенными дисками и отказаться от СХД. Поищите его в гугле, должен быть)
Что же касается диагностики на данный момент, то тут надо помониторить...
В момент нарастания очереди нужно посмотреть, а что с дисками. Например вот так: https://rickardnobel.se/windows-perf...or-disk-usage/, так же в Peromance Monitor можно увидеть. как именно процесс больше всех грузит диск.
Если это виртуалка, тут могут быть подводные камни следующего рода: дис в ВМ вроде бы и не загружен, но все тупит нещадно, тогда нужно смотреть на хосте гипервизора, что именно грузит тот самый диск. Возможно у вас неудачное сосуществование, когда на одном физическом диске расположены виртуальные диски от нескольких прожорливых машин.

Олег, благодарю, Вас.
Буду мониторить.

Отпишусь по результатам.