☰

Высокая очередь физического диска в почтовом хранилище Exchange 2003

tag-icon • tag-icon exchange-2003
Высокая очередь физического диска в почтовом хранилище Exchange 2003

У меня есть массив RAID 10 с 10 дисками SATA 7200 об/мин. Длина моей очереди дисков в рабочее время составляет в среднем около 100. Для настройки справедливо следующее:

  1. Массив имеет одно почтовое хранилище с 95 активными почтовыми ящиками. (Это единственное, никаких журналов или системных файлов)
  2. Средний размер почтового ящика ~ 400 Мегабайт
  3. Массив представляет собой один большой раздел размером 1,3 ТБ, который был выровнен по полосе RAID.
  4. Объем почтового хранилища составляет ~ 48 ГБ (для файлов etm и stm)
  5. Почтовое хранилище было только что дефрагментировано.
  6. Журналы транзакций находятся на другом массиве, средняя очередь на диске которого меньше 1.

Это кажется высоким? Если да, то что-то не так с этой настройкой? Стоит ли мне посмотреть на другие счетчики?

Обновления после комментариев:

  1. Сам массив выглядит нормально, просто в прошлые недели он показал хорошие результаты после нескольких дней испытаний на реактивную нагрузку.
  2. В массиве нет файла подкачки :-)
  3. Есть программное обеспечение Symantec AV. Самые высокие два показателя IO Reads и IO Writes, если смотреть на диспетчер задач, это conduit.exe ( symantec anti spam / virus ) и store.exe. У conduit 18 миллионов чтений и 25 миллионов записей, у store 144 миллиона чтений и 9 миллионов записей. На данный момент, поскольку у меня есть серверы-шлюзы, я рассматриваю возможность отключения AV с внутреннего сервера.

решение1

Это больше, чем "довольно высоко" — эточрезвычайно, ошеломляющевысоко. У меня есть ящики с вдвое большим количеством почтовых ящиков, работающих на RAID-5 на старых как мир дисках Ultra160 SCSI со скоростью вращения 7200 об/мин и гораздо меньшими дисковыми очередями.

Что-то еще, кроме Exchange, загружает ваши диски. Я бы открыл Perfmon и построил график "IO Data Operations / sec" в объекте "Process" для каждого отдельного процесса и посмотрел, какой процесс вызывает так много IO.

Редактировать:

Статья, на которую вы ссылаетесь в своем комментарии Джиму Б., содержит несколько очень хороших счетчиков perfmon, на которые стоит взглянуть. Мне также интересно, не поместили ли вы файл подкачки виртуальной памяти на эти диски и не видите ли вы чрезмерного подкачки.

У меня есть некоторые подозрения, после прочтения статьи и связанных статей по теме: Entourage, что у вас могут быть некоторые проблемы, связанные с этими клиентами. Outlook Anywhere (он же RPC через HTTP) не вызовет тех же проблем, что и Entourage, хотя это совсем другое (MAPI через HTTP, а не WebDAV, который используют клиенты Entourage).

Это само собой разумеется, но вы видите что-нибудь странное в журналах событий?

Редактировать после вашего обновления:

Общее количество чтений/записей — это не совсем то, что вы ищете. На самом деле вы ищете разницу в чтении/записи на основе интервала. Откройте Perfmon, очистите счетчики по умолчанию и добавьте несколько счетчиков для:

  • Объект:Процесс -Прилавок:Операции с данными/сек -Пример:conduit.exe
  • Объект:Процесс -Прилавок:Операции с данными/сек -Пример:магазин.exe

Вы также можете взглянуть наМонитор пользователей Microsoft Exchange(хорошая маленькая статья о его использовании доступна по адресуhttp://www.msexchange.org/tutorials/Microsoft-Exchange-Server-User-Monitor.html). Это не покажет сеансы WebDAV, но может дать вам некоторое представление о том, что делают ваши традиционные пользователи на основе MAPI.

решение2

Ого! Это очень много. Средняя длина очереди должна быть равна или меньше числа физических дисковых шпинделей, так что ваша машина работает на порядок выше, чем должна.Эта ссылкасодержит список всех операций Exchange, которые вызывают дисковый ввод-вывод, поэтому, следуя рекомендациям Сэма и Эвана, вам следует убедиться, что у вас нет необычного количества таких действий (например, почтового цикла).

решение3

Это довольно много, у вас есть какое-либо антивирусное ПО? Также посмотрите на \process*\io data operations/sec. Это должно сказать вам, является ли это store.exe или что-то еще причиной IO. Если это store.exe, я бы предположил, что что-то сканирует ваши почтовые ящики.

решение4

Вы также можете посмотретьМонитор процесса, который регистрирует каждый доступ к диску индивидуально. Если что-то, кроме Exchange, использует ваши диски, вы увидите, что это очень быстро заполнит список доступов к диску в ProcMon.

Вы не указали, сколько у вас оперативной памяти, хотя спецификации, которые вы упомянули, указывают, что у вас, вероятно, разумный объем. Если у вас менее 2 ГБ, вы можете увидеть такое поведение машины, обращающейся к файлу подкачки. Убедитесь, что объем используемой оперативной памяти в диспетчере задач меньше объема физической памяти, установленной на сервере.

Связанный контент