none
Очень медленная работа свежеустановленного сервера Exchange. RRS feed

  • Вопрос

  • Всем привет,

    недавно поставил Exchange 2016 на Windows Server 2012R2 x64 (Xeon E5-2420 1.90, 12Gb). Сейчас всего порядка 15 ящиков гоняют через него почту. Сервак лагает ужасно, загрузка ЦП минимальная, а вот оперативку жрет постоянно под 99% львиную часть ОЗУ сжирает процесс w3wp.exe (IIS Worker) порядка 4,3гб.

    Помимо Exchange на сервере установлен только Eset Mail Security, но и без него он очень туго работал.


    6 февраля 2017 г. 8:24

Ответы

  • А вот не соглашусь, что переезд на другой хост поможет.

    Depends.

    1-2 нормальные цифры для одного диска (spindel), а если, как Вы говорите у вас массив, то можно сказать то 2*количество дисков Raid, и получить что нормой в вашем случае точно будут значения выше 4-5.

    Это все, конечно лирика, но тем не менее вам будет полезно.

     Пока (пока) я не увидел криминала.

    Есть дневные счетчики, которые можно проанализировать вполне чтобы понять картину с тз Exchange.

    Но не нужно забывать, что это ВМ, а на хосте у Вас может твориться нехорошее.

    Поэтому Exchange и может работать медленно, просто потому что дисковая система хоста виртуализации загружена.

    Если есть возможность сдвинуть машину в сторонку в тихое место, сдвиньте  и расскажите о результатах.

    Если будет возможность увеличить RAM в период окна обслуживания- тоже можете попробовать. Но меня (меня) берут сомнения, что это поможет, я повторюсь видел конфигурации на 12 Гб по 500 "обычных" 1-2 Гб ящиков. А тут 50. Но всё бывает.

    https://blogs.technet.microsoft.com/askcore/2012/03/16/windows-performance-monitor-disk-counters-explained/

    (перевод)

    Avg. Disk Queue Length

    Cредняя длина очереди запросов к диску. Отображает количество запросов к диску, ожидающих обработки в течении определенного интервала времени. Нормальным считается очередь не больше 2 для одиночного диска. Если в очереди больше двух запросов, то возможно диск перегружен и не успевает обрабатывать поступающие запросы. Уточнить, с какими именно операциями не справляется диск, можно с помощью счетчиков Avg. Disk Read Queue Length (очередь запросов на чтение) и Avg. Disk Wright Queue Length (очередь запросов на запись).

    Значение Avg. Disk Queue Length не измеряется, а рассчитывается по закону Литтла из математической теории очередей. Согласно этому закону, количество запросов, ожидающих обработки, в среднем равняется частоте поступления запросов, умноженной на время обработки запроса. Т.е. в нашем случае Avg. Disk Queue Length = (Disk Transfers/sec) * (Avg. Disk sec/Transfer).

    Avg. Disk Queue Length приводится как один из основных счетчиков для определения загруженности дисковой подсистемы, однако для его адекватной оценки необходимо точно представлять физическую структуру системы хранения. К примеру, для одиночного жесткого диска критическим считается значение больше 2, а если диск располагается на RAID-массиве из 4-х дисков, то волноваться стоит при значении больше 4*2=8.

    8 февраля 2017 г. 8:20

Все ответы

  • Добрый день.

    Коллега, а что дисковая подсистема сервера из себя представляет?

    По симптомам у вас просто нехватка оперативки и как следствие активный свопинг - диски ложатся, все лагает.

    6 февраля 2017 г. 8:47
  • Всем привет,

    недавно поставил Exchange 2016 на Windows Server 2012R2 x64 (Xeon E5-2420 1.90, 12Gb). Сейчас всего порядка 15 ящиков гоняют через него почту. Сервак лагает ужасно, загрузка ЦП минимальная, а вот оперативку жрет постоянно под 99% львиную часть ОЗУ сжирает процесс w3wp.exe (IIS Worker) порядка 4,3гб.


    Память в потолок на сервере это абсолютно нормально, вот к примеру сервер, стоящий на земле в гибридной конфигурации, все ящики в облаке, на нем около 40 ящиков.

    Так что если память загружена на 95% и даже выше- это абсолютно нормально для Exchnage сервера.

    А теперь давайте определимся с понятиями. Что значит "Сервак лагает ужасно"? В вашей конфигурации я порядка 500 пользователей в продуктивной среде видел, на одном сервере, которые жили и были здоровы.

    Если это все претензии к серверу, что были озвучены, скажу, что ситуация штатная.

    6 февраля 2017 г. 16:34
  • Добрый день,

    физическая машина raid 10, виртуальный Exchange скази

    7 февраля 2017 г. 6:12
  • Лагает это когда тулбокс запускается 2 минуты)) и пока он запускает ты отвлекаешься на другую задачу и забываешь про то что хотел на эксченже..

    Лагает это когда не закрываешь PS на эксченже чтобы в следующий раз не ждать пока он подгрузится. В таком духе :) да даже когда запускаешь ECP она выполняет задачи с приличной задержкой (мне это напоминает тестовые машины на курсах майкрософта)

    7 февраля 2017 г. 6:47
  • Ну я так примерно и думал :) Подключитесь к серверу удаленно со своей р.с. и оцените, насколько быстро работает удаленная сессия. Именно поэтому на сервере обычно делать нечего- все можно сделать через PS remoting либо EAC. Отвыкайте ходить на сервер и открывать консоль там, в общем. Удивите себя приятно открыв браузер и PS с рабочей станции, и посмотрев насколько быстрее и удобнее это будет.
    7 февраля 2017 г. 6:52
  • Т.к. я пока сижу на 7ке, нет возможности юзать удаленный PS. Т.е. вы хотите сказать, что это нормально что на самом сервере эксченж все работает мега медленно? =\ даже зайти на сервер посмотреть лог событий это ждать 2-3 минуты пока прогрузятся оснастки
    7 февраля 2017 г. 7:04
  • Абсолютно нормально, разумеется. У вас вся память забрана Exchange, а Вы хотите скоростей работы.

    Resmon-disk-disk queue, видите цифры больше единицы постоянно? Если нет, значит нет проблем с дисками никаких, и все работает штатно.

    И Вам ничего не мешает использовать удаленный PS на семерке. Хоть на висте используйте, работает одинаково.

     
    7 февраля 2017 г. 7:15
  • Лаги - это не нормально, что на эксче, что на любом другом сервере.

    Посмотрите хотя бы через системный монитор загрузку диска и если она будет приближаться к 100%, то проблема либо в слабых дисках, либо в нехватке оперативки.

    Вот загрузка виртуализованного эксча на 300 ящиков:

    И что-то я не вижу загрузки оперативки на 99%. Да, бывает она доходит до 95-97, но это пиковые значения и длятся они совсем недолго. При этом даже при 99% загрузки оперативки нагрузка на диски не поднимается дольше чем на 10 минут до 100%.

    7 февраля 2017 г. 7:17
  • Егор, вот придет ТС, и нас рассудит, пока мы только гадаем хорошо ему или плохо. Подождём.
    7 февраля 2017 г. 9:14
  • Увеличить ОЗУ пока не было возможности.

    А вот Resmon-disk-disk queue прыгает 1-2, по этому по возможности попробую перенести эксченж на другую виртуалку, менее нагруженную. 

    Всем спасибо за ответы.

    8 февраля 2017 г. 6:38
  • А вот не соглашусь, что переезд на другой хост поможет.

    Depends.

    1-2 нормальные цифры для одного диска (spindel), а если, как Вы говорите у вас массив, то можно сказать то 2*количество дисков Raid, и получить что нормой в вашем случае точно будут значения выше 4-5.

    Это все, конечно лирика, но тем не менее вам будет полезно.

     Пока (пока) я не увидел криминала.

    Есть дневные счетчики, которые можно проанализировать вполне чтобы понять картину с тз Exchange.

    Но не нужно забывать, что это ВМ, а на хосте у Вас может твориться нехорошее.

    Поэтому Exchange и может работать медленно, просто потому что дисковая система хоста виртуализации загружена.

    Если есть возможность сдвинуть машину в сторонку в тихое место, сдвиньте  и расскажите о результатах.

    Если будет возможность увеличить RAM в период окна обслуживания- тоже можете попробовать. Но меня (меня) берут сомнения, что это поможет, я повторюсь видел конфигурации на 12 Гб по 500 "обычных" 1-2 Гб ящиков. А тут 50. Но всё бывает.

    https://blogs.technet.microsoft.com/askcore/2012/03/16/windows-performance-monitor-disk-counters-explained/

    (перевод)

    Avg. Disk Queue Length

    Cредняя длина очереди запросов к диску. Отображает количество запросов к диску, ожидающих обработки в течении определенного интервала времени. Нормальным считается очередь не больше 2 для одиночного диска. Если в очереди больше двух запросов, то возможно диск перегружен и не успевает обрабатывать поступающие запросы. Уточнить, с какими именно операциями не справляется диск, можно с помощью счетчиков Avg. Disk Read Queue Length (очередь запросов на чтение) и Avg. Disk Wright Queue Length (очередь запросов на запись).

    Значение Avg. Disk Queue Length не измеряется, а рассчитывается по закону Литтла из математической теории очередей. Согласно этому закону, количество запросов, ожидающих обработки, в среднем равняется частоте поступления запросов, умноженной на время обработки запроса. Т.е. в нашем случае Avg. Disk Queue Length = (Disk Transfers/sec) * (Avg. Disk sec/Transfer).

    Avg. Disk Queue Length приводится как один из основных счетчиков для определения загруженности дисковой подсистемы, однако для его адекватной оценки необходимо точно представлять физическую структуру системы хранения. К примеру, для одиночного жесткого диска критическим считается значение больше 2, а если диск располагается на RAID-массиве из 4-х дисков, то волноваться стоит при значении больше 4*2=8.

    8 февраля 2017 г. 8:20
  • Коллега, вам бы не в реалтайме данные отслеживать, а поставить их на постоянный мониторинг. Тогда бы вы смогли увидеть пики по нагрузке и определили бы что к чему.

    очередь диска 1-2 на десятом рейде - абсолютно нормальное явление, ведь там как минимум 4 диска, а значит потолок нормальных значений очереди упирается в значение 8. Если будет больше, то значит диски с нагрузкой не справляются.

    В вашем случае просто банальная нехватка оперативки.

    8 февраля 2017 г. 8:23
  • Как успехи?
    14 февраля 2017 г. 10:23
  • К сожалению возможности перенести виртуалку пока не было, скорее всего в эти выходные займусь этим.

    Накинул оперативки до 14гб, ничего не изменилось. 

    14 февраля 2017 г. 11:25
  • Ну о чем я и говорил с самого начала- на том оборудовании, которое имеется в вашем распоряжении- это нормальные цифры. Будут быстрее диски- будет быстрее и отзывчивее работать Ваш сервер.

    14 февраля 2017 г. 11:29