Высокое Среднее число Загрузки со скромной загрузкой ЦП и почти никаким IO
Можно попытаться имитировать сессию между полем Symantec и Exchange Server, чтобы видеть, можно ли получить полезное сообщение об ошибке. Возможно, что Ваш Exchange Server заблокирован вниз, чтобы только говорить с полем Symantec, таким образом, Вам, вероятно, придется добавить Ваш IP-адрес к позволенному списку IP.
Откройте командную строку и введите следующее. Замените что-либо, что я вставил <angle brackets> со значениями из сообщения, которое отклоняется. Для каждой новой строки ниже, нажмите Enter и дайте ему секунду для отправки ответа.
HELO symantec-gateway
telnet <Your Exchange Server> 25
MAIL FROM: <Sender Address>
RCPT TO: <Recipient Address>
DATA
Subject: <Message Subject>
Test
.
Новая строка между предметом и тестовым сообщением является намеренной и необходимой, и это - период (.) самостоятельно на последней строке - это важно. Когда Вы делаете это, необходимо получить сообщение из Exchange Server с чем-то как Message 123abc@exchange.acme-widgets.com successfully queued for delivery. Можно затем ввести quit и Вы должны роняться к командной строке.
Обновите свое исходное сообщение для включения любых ошибок, которые Вы получаете.
Править
Вы могли попытаться поднять диагностику, регистрирующуюся, чтобы видеть, получаете ли Вы что-либо полезное.
Откройте менеджера по Системе обмена и спуститесь до Administrative Groups => (Ваша Административная Группа => Серверы => (Ваш Сервер), и щелкните правой кнопкой по нему. Перейдите к Свойствам и перейдите к вкладке Diagnostics Logging.
Под Сервисами слева, выберите MSExchangeTransport и поверните NDR и Протокол SMTP до Носителя.
Надо надеяться, это зарегистрирует (в журнале событий Приложения) все отправленные сообщения NDR, наряду с их кодами состояния. Когда Вы получаете некоторые журналы, обновляете Ваш вопрос с ними. Кроме того, когда Вы получите некоторые полезные журналы, повернете диагностику, входящую вниз снова - Ваш сервер будет любить Вас за нее!
Средняя загрузка основана на процессах, ожидающих в очереди выполнения. Это означает, что если у вас есть процессы, которые часто используют дробные временные интервалы, вы можете увидеть высокую среднюю нагрузку без высокой загрузки ЦП.
Лучшим примером этого является почта. Количество процессорного времени, необходимого для отправки сообщения, очень ограничено, но когда по системе перемещаются тысячи писем (особенно если почтовый демон разветвляет процессы для обработки каждого из них), очередь выполнения становится очень длинной. Часто можно увидеть хорошо функционирующие, отзывчивые почтовые серверы со средней нагрузкой от 25, 50 до более 100.
Для веб-сервера я бы использовал время отклика страницы в качестве основного показателя, не беспокойтесь о средней нагрузке. В современных планировщиках средняя нагрузка менее чем вдвое больше, чем количество ядер, обычно не имеет негативных последствий. Вы можете поэкспериментировать с количеством ядер на виртуальную машину по сравнению с общим количеством виртуальных машин. Некоторые приложения выиграют от использования большого количества ядер на нескольких машинах, другие - от небольшого количества ядер и множества экземпляров.
Это не похоже на особенно высокую среднюю нагрузку. Если вы хотите его отследить, iotop , вероятно, лучший инструмент для этой работы.
Средняя загрузка - это количество выполняемых процессов, ожидающих ЦП. Процесс, ожидающий ввода-вывода, вообще не считается. «Обычное объяснение» совершенно неверно.
Если мы будем использовать следующие команды оболочки для отслеживания реальной средней нагрузки, у нас могут быть разные взгляды на это явление. procs_running could be much higher than we expected.
while true; do cat /proc/loadavg ; cat /proc/stat| grep procs; done
Я имел дело с сценарием, очень похожим на ваш. В моем случае средняя загрузка упала после смены планировщика ввода-вывода блочного устройства проблемной виртуальной машины на планировщик NOOP. Этот планировщик представляет собой просто очередь FIFO, которая хорошо работает, когда гипервизор в любом случае будет применять свои собственные алгоритмы планирования ввода-вывода. Не нужно переупорядочивать дважды.
С учетом сказанного, я все еще имею дело с вялыми событиями клавиатуры на проблемной виртуальной машине, поэтому я думаю, что я удалил только высокую среднюю нагрузку, не решив реальную проблему. Я обязательно обновлю этот ответ, если найду основную причину.
Список доступных планировщиков (и [scheduler] в использовании):
cat /sys/block/sdX/queue/scheduler
noop anticipatory deadline [cfq]
Измените его с помощью:
echo noop > /sys/block/sdX/queue/scheduler
Чтобы сделать его постоянным, вам нужно добавить ] elevator = noop к параметрам загрузки ядра вашей виртуальной машины.
Когда у вас есть проблема с производительностью в виртуальной машине, вам нужно сначала подойти к проблеме как со стороны супервизора, так и со стороны виртуальной машины. Также следует иметь в виду, что хронометраж в виртуальной машине неточен. Это также означает, что статистика, измеренная на виртуальной машине, может быть неверной.
Какова статистика процессора и ввода-вывода для этой виртуальной машины? Обратите внимание на счетчик готовности процессора - он должен быть меньше 5%. На какой версии ESX вы работаете? Какая у вас архитектура оборудования в тестах и продуктах?
На виртуальной машине вы можете профилировать все, от приложения до ядра, с помощью perf и визуализировать результат с помощью графиков пламени