Отключение дискового ввода-вывода в Windows Server 2008 R2, запущенном в VMWare
Мы пытаемся решить проблему с нашим сервером около недели. Только за последние несколько дней мы действительно узнали, в чем проблема.
Небольшая информация заранее: мы запускаем виртуальную машину со сторонним веб-хостом. Я знаю, что они используют VMWare, но не знаю какой именно версии. Они только что обновили наши инструменты VMWare до последней версии вчера вечером. Серверная ОС - Windows Server 2008 R2, и на ней должны быть установлены самые последние обновления Windows. Мы используем его как веб-сервер, поэтому он запускает IIS 7.5, а поверх него - Coldfusion 9.0.1. Coldfusion 9 должен использовать последнюю версию JDK 6 (я думаю, что есть / были проблемы совместимости с Java 7).
Мы наблюдаем небольшие промежутки времени, от 30 секунд до 2,5 минут, когда сервер в основном «останавливается». На самом деле он не блокируется, но загрузка ЦП падает почти до 0%, и веб-запросы не обрабатываются.
Используя Windows Performance Monitor, мы обнаружили, что, когда это происходит, дисковый ввод-вывод полностью отключается. Прилагаются изображения графиков, извлеченных из монитора производительности.
Первый график показывает, когда это происходит. Обратите внимание, что% простоя диска (зеленая линия) падает до 0. Я предполагаю, что это означает, что доступ к диску полностью загружен. ЦП падает почти до 0% с периодическими скачками. Фиолетовая линия - это длина очереди диска, которая, как я полагаю, показывает, сколько операций ввода-вывода диска ожидает в системе. Обычно это очень мало, примерно 1 или 2, часто умноженное на 0. Когда происходит это явление, оно резко возрастает (что имеет смысл, если что-то не так с доступом к диску).
Второй график показывает, когда все возвращается в норму. ЦП привязан, так как он начинает обрабатывать очередь веб-запросов и другие вещи, которые были отложены, но статистика диска возвращается к «нормальному».
Не каждый раз, но когда это происходит, и перерыв в работе очень долгий (несколько минут), мы также видим некоторые предупреждения, записанные в журнале системных событий Windows. Источник - «LSI_SCSI», а идентификатор события - «129» с общим сообщением «Выполнен сброс на устройство, \ Device \ RaidPort0».
Когда это впервые началось, мы думали, что это что-то с нашим кодом, но, увидев, что все это происходит, мы чувствуем, что это что-то либо с ОС, либо с виртуальной машиной / VMWare. Я не думаю, что это связано с нагрузкой, потому что если бы это было так, я бы подумал, что мы увидим как высокую загрузку диска, так и высокую загрузку процессора. Тот факт, что процессор невысокий, заставляет меня думать, что процессы просто заблокированы, ожидая возврата запросов ввода-вывода. Мы работаем с нашим хостинг-провайдером, пока я пишу это, чтобы понять это, но я подумал, что попробую здесь для идей. Заранее благодарю за любую помощь!
Первый график 
Второй график 
Ваш провайдер может запускать вашу виртуальную машину на перегруженном хосте. Если чья-то еще виртуальная машина связывает диск, вы просто застрянете, пока его виртуальная машина не освободится. Вы ничего не можете с этим поделать, кроме как наделать много шума.
Я знаю, что это старше, и мы уже давно исправили это, но увидели это в моем профиле и хотели опубликовать ответ.
Оказалось, что наш хостинг-провайдер случайно провалил заказанное нами обновление. Они предлагают два уровня дисков: один медленнее и другой с гораздо большей производительностью. Понятия не имею, в чем заключаются технические отличия.
У нас всегда были продукты с более высокой производительностью, но когда мы в последний раз обновляли дисковое пространство, технология случайно переместила нас на более низкий уровень.
В нашей отрасли конец декабря обычно протекает медленнее с точки зрения трафика, поэтому эти ошибки не начали появляться до января, когда трафик (и, следовательно, дисковый ввод-вывод) возобновился.
В любом случае, после примерно двух недель расследования и бесчисленных часов моего потраченного впустую времени, мы позвонили одному из технических специалистов хоста и обнаружили эту небольшую проблему. В итоге мы получили около двух месяцев бесплатного хостинга из-за головной боли, которую он нам доставил.