Как найти проблемы с производительностью

Производительность ПК. Проблемы производительности. Анализ журналов событий.

Как повысить производительность компьютера

Казалось бы, вполне шустрый компьютер, который вначале полностью удовлетворял своими возможностями, со временем
начинает тормозить. Что могло послужить причиной такого снижения производительности? Или бывает еще другая
ситуация, когда нужно работать в очень ресурсоемких программах (играх), а компьютер их просто не тянет. В любом
случае, перед пользователем встает проблема производительности ПК, которую нужно решать.

Основными признаками медленной работы компьютера являются:

1. Долгое включение и такое же долгое выключение компьютера.
2. Многие программы очень долго запускают, загрузка игр занимает очень много времени.
3. Реакция курсора может не успевать за движениями мышки, притормаживать, или наблюдается поздняя реакция на
   клик.
4. И другие признаки замедленной работы ПК, из-за которых пользователь начинает нервничать.

Что может быть причиной торможения компьютера?

Если компьютер тормозит, то причина (или сразу несколько причин) могут быть следующие:

1. Плохая совместимость программного обеспечения, операционной системы, игр с конфигурацией
   «железа» самого компьютера.
2. Большая фрагментация файловой системы, на жестком диске скопилось много программного хлама.
3. Проблемы с операционной системой, сбои, неправильная настройка.
4. Большое количество запущенных служб, в которых нет необходимости.
5. Заражение компьютера вредоносным программным обеспечением.
6. Программные конфликты (между драйверами, антивирусами и др.).
7. Плохая терморегуляция, выход из строя кулера, засорение радиаторов.
8. Нарушение основных параметров в BIOS.

Как решить эту проблему и повысить производительность компьютера?

Существует множество способов, позволяющих ускорить работу компьютера. Мы предлагаем десять методов улучшения
работы ПК, показавших свою эффективность на практике.

1. Апгрейдим «железо».
2. Чистка внутренностей, ремонт неисправных элементов системы охлаждения.
3. Очищаем жесткий диск от всего ненужного, выполняем дефрагментацию.
4. Переустанавливаем операционную систему.
5. Оптимизируем работу ОС.
6. Настраиваем BIOS.
7. Отключаем все лишнее, контролируем автозагрузку.
8. Выполняем обновление драйверов.
9. Устанавливаем операционную систему соответствующую нашему ПК.
10. Чистим систему от вирусов.

Далее, для лучшего понимания, мы дадим более подробное описание каждого из этих пунктов. Но для начала, нам
необходимо узнать производительность своего компьютера.

Определяем производительность

В операционной системе Windows 7 уже встроена специальная функция для проверки производительности системы и
быстродействия компьютера.

Откройте меню «Пуск» и в специальном поисковом поле (оно находится внизу меню) введите
«произ», как это показано на рисунке.

Среди результатов поиска будет программа «Повышение производительности компьютера». Запустите ее и
откроется следующие окно.

Снизу сделайте клик по кнопке «Повторить оценку». Программа начнет анализировать продуктивность вашей
системы и по завершению выдаст результаты, по которым можно будет сделать вывод о быстродействии компьютера.

После этого можно приступать к повышению производительности компьютера выбранными способами.

Апгрейдим комплектующие компьютера

У многих, кто является «счастливым» обладателем тормозящего компьютера, возникает стойкое желание
заменить его чем-нибудь по мощнее. Но мы не станем двигаться в этом направлении, оно подходит только для
серьезно устаревающих компьютеров. В большинстве случаев достаточно заменить только один или несколько слабых
элементов, чтобы вся система снова начала летать — этот способ будет намного дешевле, чем покупка нового
ПК.

• Центральный процессор. Смысл замены «камня» будет действительно оправдан,
  только если новый намного превзойдет старого по мощности, не менее чем на 30%. Иначе вы не почувствуете
  серьезной разницы, но зато потратите много денег.

Любители риска могут попытаться разогнать центральный процессор. Этот способ подойдет не многим, ведь далеко не
каждый ЦП может разгоняться. Зато в случае успеха, покупку нового «камня» можно отложить еще на год
другой. Суть этой операции заключается в повышении напряжения на центральном процессоре, и тем самым увеличение
его тактовой частоты. Сама операция достаточно рискованная и далеко не для всех процессоров, в некоторых случаях
можно просто вывести из строя ЦП, или значительно сократить срок его службы.

• Оперативная память. Ее никогда не бывает много, можете смело увеличивать оперативную
  память. Тем более она стоит достаточно дешево. Когда компьютер сильно загружен, откройте диспетчер задач на
  вкладке быстродействия и посмотрите уровень используемой памяти. Если он превышает 80%, то можете
  увеличивать память в полтора два раза.

• 

• Винчестер. И суть тут вовсе не в его объеме и количестве свободного места. Основная фишка
  быстродействия жесткого диска заключается в скорости вращения его мотора. К примеру, мы имеем диск со
  скоростью 5400 оборотов и заменяем него на диск со скоростью 7200 оборотов. Это намного более ощутимо
  добавит скорости для систем, особенно скорости записи/чтения.
• Видеокарта. Большинству понятно, что для более реалистичной графики в играх необходимо
  иметь мощный видеоадаптер. Так что, если ваша видеокарта не может похвастаться хорошей производительностью,
  меняйте на новую, которая гораздо превосходит ее по мощности. Главное – нужно учитывать, что для
  мощной видеокарты нужен и мощный процессор.

Чтобы приблизительно определить слабые места системы, воспользуйтесь встроенной функцией оценки
производительности компьютера, о которой мы уже рассказывали выше. Определить «слабое звено» можно
по оценкам, которые выводятся после проверки производительности. Там, где самая низкая оценка, в том направлении
и необходимо увеличивать мощность ПК. К примеру, если возле скорости обмена данными на диске стоит самая низкая
оценка, то стоит задуматься о покупке более шустрого жесткого диска.

Чистка внутренностей, ремонт неисправных элементов системы охлаждения

Различные неисправности в системе охлаждения также способны существенно замедлить работу всей системы. Если
ломается кулер на центральном процессоре, то это привод к его перегреву и снижению тактовой частоты.

Перегрев вообще опасная штука и возникать может даже при исправной системе охлаждения. Возьмите, снимите крышку
со своего системного блока, посмотрите сколько там пыли. Она не просто покрывает все поверхности, но и плотно
забивается во все радиаторы и оседает на лопастях кулеров. Пыль выступает таким себе теплоизолятором, который
приводит к перегреву. Очень аккуратно почистите системный блок и вам удастся увеличить скорость работы
компьютера, а также продлить срок службы его компонентов и избавиться от главного рассадника различных
аллергенов и бактерий — пыли.

Очищаем жесткий диск от всего ненужного, выполняем дефрагментацию

Те, кто впервые слышит термин «дефрагментация», должны понять, что это самое первое что нужно делать
для повышения производительности системы. Дефрагментация позволяет собирать различные фрагменты программ,
которые находятся в разных частях жесткого диска, в одну кучу. Благодаря этому, считывающему устройству
винчестера не нужно выполнять много лишних перемещений по дискам, ведь все находится в одном месте. Таким
образом и повышается производительность.

Кроме того, нужно избавиться от лишней информации и всякого программного хлама, который накапливается на диске со
временем работы. Особенно это важно, когда в разделе операционной системы практически нет свободного места. Если
места менее 2 Гб, система теряет свою производительность. Так что не перегружайте диск и старайтесь, чтобы на
нем было процентов тридцать свободного места, если это конечно возможно.

Переустанавливаем операционную систему

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

Если тщательно следить за чистотой системы и ничего туда не устанавливать, то можно годами пользоваться одной и
той же Windows. Но чаще всего, на компьютере постоянно происходит движение: устанавливаются и удаляются
программы, обновляются драйвера, загружаются большие объемы различной информации — в таких условиях
система постепенно начинает «тупить». Лучше всего, для профилактики, где-то раз в год форматировать
диск и с чистого листа устанавливать новую операционную систему.

Оптимизируем работу ОС

Хорошо себя показала программа PCMedic. Главная фишка этой утилиты, это полная автоматизация всех операций. Нужно
только выбрать подходящие параметры и запустить процесс настройки.

Программа состоит только из одного главного окна. Тут мы выбираем свою операционную систему, тип центрального
процессора (например, Intel или AMD), дальше нужно выбрать один из двух способов оптимизации — Heal
(очистка системы), либо Heal & Boost (кроме очистки выполняется еще и ускорение). После того, как выберите
все параметры нажмите на кнопочку «Go» – программа выполнит все необходимые изменения.

Есть еще одна программа, которая может похвастаться воистину мощным функционалом — Ausloqics BoostSpeed, к
сожалению, платная. Она состоит из нескольких утилит, позволяющих выполнять оптимизацию системы практически во
всех направлениях. Используя это приложение можно провести дефрагментацию, почистить файловую систему, очистить
реестр, увеличить скорость работы интернета и еще много другого. Программа обладает встроенным советчиком,
который помогает определить приоритетные направления в оптимизации системы. Хотя рекомендую слепо не доверяться
советчику и смотреть, действительно ли эти все действия вам необходимы.

Для того, чтобы чистить систему от всякого хлама, существует множество специальных приложений для очистки.
Например, хорошим помощником может оказаться Ccleaner. Он способен почистить диск от ненужных, временных фалов и
выполнить очистку реестра. Благодаря удалению ненужных файлов, можно увеличить количество свободного места на
жестком диске. А вот при чистке реестра, особого повышения производительности не наблюдается. Зато если будет
случайно удален какой-нибудь важный параметр, система начнет выдавать ошибки и это может привести к серьезным
сбоям.

ВСЕГДА смотрите файлы, которые удаляют утилиты для очистки системы. Бывают случаи безвозвратного удаления нужных
и даже важных файлов, которые программы ложно приняли за ненужные, или временные файлы.

Пользователи Windows 7 могут немного улучшить скорость работы компьютера при помощи упрощения графического
интерфейса. Что бы это сделать откройте Панель управления и зайдите в раздел «Система» откройте
пункт «Дополнительно» и выберите «Параметры». Здесь снимаем часть ненужных флажков, либо
устанавливаем переключатель в положение для обеспечения наилучшего быстродействия.

Настраиваем BIOS

В БИОСе хранятся параметры компьютера, отвечающие за оборудование, загрузку ОС, время и других ключевые элементы.
Чтобы попасть в параметры BIOS, в процессе включения ПК, перед загрузкой самой операционной системы, нажмите
клавишу Del, F2 или другую (это зависит от производителя материнской платы, обычно название клавиши отображается
на экране). Чаще всего настройки БИОСа не вызывают никакого снижения производительности и туда даже не стоит
лазить. Но в редких случаях, при неправильных критических параметрах, ваш компьютер может начать тормозить.

Если сомневаетесь в правильности настроек, но не знаете какие нужно указать, то можете воспользоваться опцией
автоматической настройки оптимальных параметров «Load Optimal Settings» (название функции может быть
иным, в зависимости от производителя). После этого сохраните все настройки и выполните перезагрузку компьютера.

Отключаем все лишнее, контролируем автозагрузку

В наше время практически каждая программа пытается прописать себя в автозагрузку. И это не слишком весело для
вашей системы. Постепенно, программы в автозагрузке накапливаются и их всех надо запускать, при каждом старте
системы. Из-за этого компьютер очень долго включается и выключается. Дополнительно, после автозагрузки, все эти
приложения остаются в рабочем состоянии, пожирая ресурсы. Вы только взгляните сколько на панели задач (возле
часов) ненужных значков, разве вы их используете? Поэтому, лучше всего удалять ненужные приложения, или хотя бы
отключать для них автозагрузку.

Что бы посмотреть все приложения, которые стартуют вместе с Windows, и отключить лишние, одновременно зажмите две
клавиши Win+R и в следующем окошке напишите msconfig, затем нажмите Enter. Появится окошко конфигурацией
системы, теперь перейдите в раздел автозагрузки. Здесь будет находиться список приложений, стоящих в
автозагрузке. Просто снимаете галочки со всех, которыми не пользуетесь. В случае чего, программу всегда можно
вернуть в автозагрузку, установив нужную галочку. Главное иметь представление, что это за программы и какое их
назначение.

В самых крайних случаях, можно отключить антивирус, и система немного разгрузится. За счет этого повысится
производительность. Но этого не стоит делать, когда вы находитесь в интернете, или устанавливаете новые
программы, потому что есть риск заражение вирусами.

Выполняем обновление драйверов

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

Надежнее всего вручную выполнять обновление драйверов. Но самые ленивые могут воспользоваться специальными
утилитами, которые способны сами определять необходимые драйвера, находить их в интернете и устанавливать.
Например, можно воспользоваться Drover Checker.

Устанавливаем операционную систему соответствующую нашему ПК

Если у вас компьютер, с 2 Гб оперативной памяти и вы используете Windows XP, то стоит задуматься о переходе на
«семерку», после этого сразу почувствуете положительную разницу. А если на компьютере двухъядерный
процессор и 4 Гб памяти (а может даже больше), то необходимо использовать 64х разрядную Windows 7. 

И да, избегайте кустарных сборок Windows, таких как Zver и тому подобных. Используйте исключительно чистые,
оригинальные дистрибутивы.

Чистим систему от вирусов

Не обращайте внимание на то, что этот пункт стоит под номером десять. На самом деле это одна из самых
распространенных причин медленной работы компьютера. Если заметили, что компьютер внезапно начал долго
«думать», срочно выполните сканирование на наличие вредоносного ПО. Лучше всего выполнить
сканирование системы штатным антивирусом (например, Антивирусом Касперского), а затем просканировать
дополнительными антивирусными утилитами, типа Dr. Web CureIt, AVZ и др. 

Вот и все основные способы, позволяющие увеличить быстродействие компьютера. В многих следующих статьях, мы будем
еще неоднократно затрагивать проблему производительности системы и все эти рекомендации будут рассмотрены еще
более подробно, со всеми тонкостями. Ну а на сегодня все, если возникнут вопросы – можете смело задавать
их в комментариях к статье.

Как определить и устранить проблемы с производительностью компьютера

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

Определение проблемы

Для начала нужно оценить состояние компьютера и определить, что именно является причиной низкой производительности. Вот несколько начальных шагов:

1. Проверьте используемые ресурсы

Нажмите клавишу “Ctrl+Shift+Esc”, чтобы открыть диспетчер задач Windows. В верхней части диспетчера вы можете увидеть загрузку центрального процессора (CPU), использование оперативной памяти (RAM) и другие параметры производительности. Если какой-то параметр находится близко к максимальному значению, это может быть причиной плохой производительности.

2. Закройте неиспользуемые приложения

Закройте все ненужные приложения и окна. Они могут занимать много ресурсов и тормозить работу компьютера.

3. Измените настройки энергосбережения

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

4. Перезапустите компьютер

Перезагрузка компьютера может помочь решить многие проблемы с производительностью.

Устранение проблемы

Если проблема с производительностью сохраняется, то нужно искать глубинные причины и проводить дополнительные действия:

1. Отключите ненужные программы

Запустите диспетчер задач и найдите программы, которые не используются сейчас, но всё ещё работают в фоновом режиме. Остановите или удалите их, чтобы освободить ресурсы компьютера.

2. Очистите жесткий диск

Если на жестком диске мало свободного места, это может снизить производительность компьютера. Удалите ненужные файлы, программы и документы.

3. Удалите вредоносные программы

Вирусы и другие вредоносные программы могут сильно замедлить работу компьютера. Установите антивирусное ПО и проведите полное сканирование системы.

4. Добавьте оперативную память

Недостаток оперативной памяти может быть причиной плохой производительности. Установите дополнительные планки оперативной памяти, чтобы улучшить работу компьютера.

Заключение

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

Время на прочтение
14 мин

Количество просмотров 2.5K

В этой статье я расскажу, как искать иголку в стоге сена причину проблем с производительностью ВМ на ESXi. Главным способом будет то, что так не любят многие администраторы: планомерная проверка всех ресурсов на утилизацию, сатурацию и ошибки. Я приведу ключевые метрики, на которые следует обратить внимание, их краткое описание и значения, на которые можно ориентироваться, как на норму. При этом важно понимать, что разные системы имеют разные требования к производительности. Следовательно, то, что приемлемо для одной системы, для другой может являться признаком аварийного состояния.

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

Нашим первым шагом должна быть быстрая базовая проверка основных параметров – ее сценарий я опишу в начале статьи. Если базовая проверка не нашла причины проблем, то, скорее всего, укажет направление, в котором мы запустим расширенную проверку. В любом случае, более глубокая расширенная проверка всех доступных параметров поможет в итоге найти корень проблем. С этим обнадеживающим фактом давайте приступим. Напомню, что проверяемые параметры стоит фиксировать скриншотами.

Выясняем симптомы проблемы

Вот краткий список ключевых вопросов, на которые нужно ответить:

1. Как проявляются проблемы производительности? Описываем словами, снимками, прикладываем графики.

2. Когда работало хорошо и когда начало работать плохо? Вспоминаем даты и время.

3. Были ли какие-то аппаратные, программные или нагрузочные изменения?

4. Охватывает ли проблема другие системы или только одну, например: ВМ, vApp, группу ВМ, кластер, группу кластеров и т. д.

Часть 1. Базовая проверка

Цель базовой проверки – быстро выяснить направление, в котором находится источник проблем производительности. Учитывайте, что графики в vSphere Client усредняют значения со временем, и лучше собирать максимум информации в любую стороннюю систему мониторинга (Prometeus, Zabbix, VMware vRealize Operation Manager и т. д.). Если такой системы нет, то воспроизводим проблему в реальном времени и наблюдаем за ней со стороны гипервизора. По результатам базовой проверки решаем, нужно ли дальнейшее расследование.

Проверяем ВМ из vSphere Client

1. Triggered Alarms, Tasks и Events не должны содержать событий, коррелирующих с проблемой.

2. CPU

   1. Usage не должен превышать 90%.

      Usage – процент активно задействованных мощностей виртуальных CPU. Это среднее значение загруженности CPU в виртуальной машине. Например, если виртуальная машина с одним виртуальным CPU работает на хосте, имеющем четыре физических CPU, и Usage виртуального CPU составляет 100%, то виртуальная машина полностью использует один физический CPU.

      Usage виртуального CPU = usagemhz / кол-во виртуальных CPU x частота ядра.

   2. Ready не должен превышать 10% на ядро.

      Ready показывает время, в течение которого виртуальная машина была готова к использованию, но не могла быть запущена на физическом CPU из-за нехватки ресурсов. Ready % зависит от количества виртуальных машин на хосте и загруженности их CPU.

3. Memory

   1. Ballooned должен быть равен 0.

      Этот параметр указывает на объем памяти, захваченной драйвером управления памятью ВМ (vmmemctl), который установлен в гостевую ОС вместе с VMware Tools. Данный объем перераспределяется от ВМ к гипервизору в условиях её нехватки. То же самое происходит, когда неверно выставлен Memory Limit на ВМ или ресурсный пул – это тоже ухудшает производительность ВМ.

   2. Swapped должен быть равен 0.

      Это текущий объем гостевой физической памяти, которую  VMkernel выгрузил в файл подкачки ВМ. Выгруженная память остается на диске до тех пор, пока она не понадобится ВМ, либо пока не будет запущен принудительный механизм unswap. Подробнее расписано тут: https://www.yellow-bricks.com/2016/06/02/memory-pages-swapped-can-unswap/

4. Virtual Disk

   1. Нормально, если отсутствуют мгновенные снимки старше 24 часов.

   2. Highest latency не должен превышать приемлемых для приложения значений.

      Это наибольшее значение задержки среди всех дисков, используемых ВМ. Измеряет время, необходимое для обработки команды SCSI, которое гостевая ОС предоставила виртуальной машине. Задержка ядра – это время, которое требуется VMkernel для обработки запроса ввода/вывода. Задержка устройства – это время, которое требуется оборудованию для обработки запроса.

      Есть прямая зависимость от размера блока ввода/вывода (Write request size и Read request size) с временем задержки, за которое этот блок будет обработан подсистемой хранения.

   3. Write request size и Read request size не должны коррелировать с Highest latency.

      Важным нюансом этой метрики является то, что vSphere не отображает размеры блока более 512 КБ: вы увидите рост задержек вследствие роста размера блока выше 512 КБ, но при этом не будете видеть рост размера самого блока. Увидеть его можно только через утилиту хоста ESXi vscsiStats.

      Подробнее о vscsiStats здесь: https://communities.vmware.com/t5/Storage-Performance/Using-vscsiStats-for-Storage-Performance-Analysis/ta-p/2796805

      Здесь можно превратить вывод команды в гистограмму: https://www.virten.net/vmware/vscsistats-grapher/

   4. Average commands issued per second не должен превышать IOPS Limit.

   5. Commands aborted и Bus resets должны равняться 0.

5. Network

   1. Usage не должен достигать предела (vmnic хоста, политик коммутирующего оборудования или маршрутизатора).

      Этот параметр отображает объем данных, переданных и полученных всеми виртуальными сетевыми картами, подключенными к виртуальной машине.

   2. Receive packets dropped и Transmit packets dropped должен равняться 0.

   3. Packets received и Packets transmitted не должны содержать скачков, коррелирующих с проблемой в разбивке по типам Broadcast, Unicast и Multicast.

Проверяем хост из vSphere Client

1. Triggered Alarms, Tasks и Events не должны содержать событий, коррелирующих с проблемой.

2. CPU

   1. Usage по всему хосту не должен превышать 80%.

   2. Ready не должен превышать 10% на ядро (как перевести из summation в проценты подробно читайте тут: https://kb.vmware.com/s/article/2002181).

3. Memory

   1. Balloned должен равняться 0.

      Это сумма значений vmmemctl для всех включенных ВМ и служб vSphere на хосте. Если целевой размер balloon (дословно переводится как «шар») больше, чем текущий, VMkernel «раздувает» balloon внутри ВМ, в результате чего освобождается больше памяти хоста. Если целевой размер balloon меньше, чем текущий,  VMkernel «сдувает» balloon, что позволяет процессам внутри ВМ при необходимости использовать больше памяти. Подробнее про ballooning тут: https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-resource-management/GUID-2B1086F3-B3F5-426C-9162-3C3CDD23A5DF.html

   2. Swap consumed должен быть равен 0.

      Это объем памяти, которая используется для подкачки всех включенных ВМ и служб vSphere на хосте.

   3. Page-fault latency должно равняться 0.

      Это время ожидания виртуальной машиной доступа к сжатой памяти или файлу подкачки.

   4. Storage adapter

   1. Write rate и Read rate не должны превышать пропускную способность vmhba, коммутирующего оборудования до хранилища или пропускной способности хранилища.

   2. Write latency и Read latency должны примерно равняться по всем активным vmhba.

      Если какая-то из vmhba сильно выбивается по задержкам или нагрузке, то следует удостовериться, что политика мультипасинга выставлена корректно. Подробнее о политиках тут: https://kb.vmware.com/s/article/1011340. Большинство современных хранилищ позволяют применять политику Round Robin. После проверки политики стоит обратить внимание на качество соединения.

   5. Network:

   1. Usage не должен превышать пределов vmnic.

      Это суммарный объем данных, которые передают и получают все физические сетевые карты, подключенные к хосту.

   2. Receive packets dropped и Transmit packets dropped должны равняться 0.

   3. Packets received и Packets transmitted не должны содержать скачков, коррелирующих с проблемой в разбивке по типам Broadcast, Unicast и Multicast.

Часть 2. Расширенная проверка

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

Проверяем ВМ и хост

Здесь большая часть метрик берется из утилиты хоста ESXi esxtop. Очень кстати вывод esxtop можно записывать в csv-файл. Формат csv позволяет открыть его, к примеру, в PerfMon на Windows и проанализировать не только мгновенные значения, но и их изменение во времени.

Запись одной тысячи точек с шагом раз в две секунды можно выполнить так:

esxtop -a -b -d 2 -n 1000 > esxtop-output.csv

1. Должны отсутствовать ошибки в vmware.log ВМ, vmkernel.log хоста, в журнале IPMI хоста и во внешних системах журналирования по объектам, релевантным проблеме.

2. CPU в esxtop (клавиша ‘c’)

   1. CPU load average не должен превышать 1.

      Это среднее арифметическое значение загрузки CPU за 1 минуту, 5 минут и 15 минут, основанное на 6-секундных выборках.

   2. %USED не должен превышать 90 на ядро.

      Это процент физического процессорного времени, приходящийся на world. В эту величину входит метрика %RUN, обозначающая процент времени, когда world вычислялся на физическом CPU. Дополнительно сюда засчитывается %SYS, обозначающая процент времени, при котором VMkernel обрабатывал прерывания и выполнял иные системные действия для данного world. Метрика же %OVRLP вычитается из данной и отражает процент времени, которое world провел в очереди на выполнение, ожидая завершения системных действий в отношении других world.

      %USED = %RUN + %SYS – %OVRLP.

   3. %RDY не должен превышать 10.

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

      Поясню: world, который стоит в очереди, ожидает, пока планировщик разрешит ему запуск на физическом CPU. %RDY – процент от этого времени, поэтому он всегда меньше 100%.

      Если в настройках ресурсов ВМ установлен CPU Limit, то планировщик не станет размещать ВМ на физическом CPU, когда она израсходует выделенный ей ресурс CPU. Это может произойти даже при наличии большого количества свободных тактов CPU. Время, в течение которого планировщик намеренно удерживает ВМ, отображается в параметре %MLMTD, который мы опишем дальше. Обратите внимание, что параметр %RDY включает в себя %MLMTD. Для определения задержки процессора мы будем использовать формулу: %RDY – %MLMTD. Поэтому, если показатель %RDY – %MLMTD высокий, например больше 10%, вы можете столкнуться с проблемой нехватки мощностей CPU.

      Рекомендуемый порог зависит от обстоятельств. Для пробы можно начать с 10%. Если скорость работы приложения в ВМ в порядке, то оставьте порог как есть. В противном случае – снизьте порог.

      Закономерный вопрос: а что составляет 100% времени?

      World может находиться в разных состояниях: он запланирован к запуску, готов к запуску, но не запланирован, или не готов к запуску, то есть ожидает какое-либо событие.

      100% = %RUN + %RDY + %CSTP + %WAIT.

   4. %CSTP не должен превышать 3.

      Это процент времени, в течение которого world находится в состоянии co-schedule. Состояние co-schedule применимо только для многопроцессорных виртуальных машин. Планировщик CPU ESXi намеренно переводит виртуальный CPU в это состояние, если этот виртуальный CPU опережает в вычислениях другие виртуальные CPU данной ВМ.

      Высокий показатель %CSTP означает, что ВМ неравномерно использует виртуальные CPU. Приложение использует CPU с высоким %CSTP внутри ВМ гораздо чаще, чем остальные её CPU.

   5. %MLMTD должен равняться 0.

      Это процент времени, в течение которого world был готов к запуску, но не запущен планировщиком из-за настроек CPU Limit.

      Обратите внимание, что параметр %MLMTD уже учтен в расчете %RDY. Показатель %MLMTD высок, когда ВМ не может быть запущена из-за настройки CPU Limit. Если вы хотите повысить производительность этой ВМ, то увеличьте этот лимит. В целом, использование CPU Limit не рекомендуется.

   6. %SWPWT должен равняться 0.

      Это процент времени, в течение которого world ожидает, пока VMkernel завершит подкачку памяти. Время %SWPWT (ожидание подкачки) включено в %WAIT.

3. Memory в esxtop (клавиша ‘m’)

   1. Memory хоста в состоянии High. Про memory state подробно написано здесь: https://www.yellow-bricks.com/2015/03/02/what-happens-at-which-vsphere-memory-state/

   2. MCTLSZ должен равняться 0.

      Это объем гостевой физической памяти, перераспределенной balloon-драйвером.

      Высокий показатель MCTLSZ означает, что много гостевой физической памяти этой виртуальной машины «украдено», чтобы уменьшить нагрузку на память хоста.

      Как тогда узнать, что виртуальная машина работает в режиме ballooning? Если показатель MCTLSZ изменяется, balloon-драйвер активно освобождает память хоста, раздувая «шар памяти» в ВМ. Скорость ballooning в краткосрочной перспективе можно оценить по изменению MCTLSZ в какую-либо сторону.

   3. SWCUR должен равняться 0.

      Это общее количество мегабайт подкачки, которые используются в файле vswp ВМ или в системном файле подкачки, а также миграционном файле подкачки. ВМ в состоянии vMotion использует миграционный файл подкачки для удержания выгруженной памяти на целевом узле, если целевому узлу не хватает памяти.

      Для ВМ это текущий объем гостевой физической памяти, выгруженной в зарезервированное хранилище. Обратите внимание, что эта статистика относится к своппингу VMkernel, а не к своппингу гостевой ОС внутри ВМ.

      Высокий показатель SWCUR у ВМ означает, что гостевая физическая память ВМ находится не в оперативной памяти, а на диске.

   4. N%L должен быть больше 80.

      Это процент объема виртуальной памяти ВМ, который находится в локальной для её виртуальных CPU NUMA Node. Низкий процент N%L означает, что, с высокой вероятностью, какие-то запросы виртуальных процессоров ВМ используют данные оперативной памяти ВМ через межпроцессорное соединение.

      Подробнее об этом можно почитать в цикле статей от Frank Denneman: https://frankdenneman.nl/2016/07/06/introduction-2016-numa-deep-dive-series/.

4. Disk ВМ в esxtop (клавиша ‘v’)

   1. LAT/rd и LAT/wr не должны превышать приемлемых для приложения значений.

   2. CMDS/s не должен достигать IOPS Limit.

   3. MBREAD/s + MBWRTN/s не должен достигать пределов vmhba.

5. Disk Adapter в esxtop (клавиша ‘d’)

   1. QAVG/cmd должно быть около 0 и не превышать KAVG/cmd.

      Это среднее время ожидания в очереди.

      QAVG должен входить в KAVG. Но при проблемах с физическим устройством или соединительными линиями QAVG может превышать KAVG. Если показатель QAVG высокий, то следует обратить внимание на глубину очередей на каждом уровне стека хранения.

   2. GAVG/cmd, KAVG/cmd и DAVG/cmd не должны превышать приемлемые значения для данного хранилища данных.

      GAVG – это круговая задержка для всех запросов ввода/вывода, которые гостевая система отправляет на виртуальное устройство хранения. Параметр GAVG = KAVG + DAVG.

      KAVG – этот параметр отслеживает задержки, связанные с работой VMkernel.

      Значение KAVG должно быть намного меньше значения DAVG и близко к нулю. Когда в ESXi много очередей, KAVG может быть таким же высоким или даже выше, чем DAVG. Если это произошло, проверьте статистику очередей и лимиты политики хранения или виртуального диска.

      DAVG – это задержка, наблюдаемая на уровне драйвера устройства. Она включает в себя время приема-передачи между HBA и хранилищем.

      DAVG – хороший индикатор производительности хранилища. Если есть подозрения, что задержки ввода/вывода являются причиной проблем с производительностью, то следует проверить DAVG. Сравните задержки ввода/вывода с соответствующими данными из массива. Если они сходятся, проверьте массив на предмет неправильной конфигурации или неисправностей. Если нет, то сравните DAVG с соответствующими данными из точек между массивом и сервером ESXi, например, FC-коммутаторов. Если эти промежуточные данные также совпадают со значениями DAVG, вероятно, приложению не хватает ресурсов для корректной работы в этом хранилище. В таких случаях может помочь добавление накопителей или изменение уровня RAID.

   3. MBREAD/s + MBWRTN/s не должна достигать пределов vmhba.

   4. FCMDS/s, ABRTS/s, RESETS/s должны равняться 0.

      FCMDS/s – это количество команд в секунду, завершившихся ошибкой. Может указывать на проблемы с контроллером хранения, состоянием соединения до хранилища или непосредственно с хранилищем.

      ABRTS/s – это количество прерванных команд в секунду. Параметр может указывать на то, что система хранения данных не удовлетворяет требованиям гостевой ОС. Гостевая система прерывает обработку команды, если хранилище не отвечает в течение приемлемого времени (может быть настроено в гостевой ОС, в том числе и в результате установки VMware Tools). Кроме того, гостевая ОС может прервать все команды, выполняемые на ее виртуальном SCSI-адаптере.

      RESETS/s – это количество сброшенных команд в секунду. Указывает на число отброшенных команд в результате сброса состояния адаптера. Сброс может быть вызван драйвером как реакция на какие-либо события в сети хранения данных.

6. FC

   1. Вывод команды esxcli storage san fc stats get не должен содержать ошибок.

   2. Мониторинг портов сети хранения данных не должен содержать ошибок.

7. Disk device в esxtop (клавиша ‘u’)

   1. QAVG/cmd должно быть около 0 и не превышать KAVG/cmd.

   2. KAVG/cmd должно быть около 0.

   3. DAVG/cmd, GAVG/cmd не должны превышать приемлемых для приложения значений.

   4. DQLEN должно быть более 32 (кроме устройств USB и CDROM).

      Глубина очереди (queue depth) – одна из ключевых характеристик подсистемы ввода/вывода, особенно в виртуализации, где требуется высокий параллелизм операций. Глубина очереди определяет число команд ввода/вывода, которые подсистема может осуществлять одновременно. На глубину очереди влияют протоколы, аппаратные возможности устройств, прошивки и драйверы.

      Регулируется, как минимум, в следующих местах:

      • в драйвере HBA глобально на хост: https://kb.vmware.com/s/article/1267

      • на каждом LUN есть два параметра: https://kb.vmware.com/s/article/1268

        1. Device Max Queue Depth наследуется от Queue Depth драйвера HBA (предыдущий шаг). Однако может быть занижено такими технологиями, как SIOCv1 (включается в vSphere Client на Datastore) и Adaptive Queue Depth (подробнее тут: https://kb.vmware.com/s/article/1008113), которая включается расширенными настройками QFullSampleSize и QFullThreshold.

        2. No of outstanding IOs with competing worlds (DSNRO) по умолчанию равняется 32. Это глубина очереди к LUN, если с ним одновременно работают более одной ВМ.

      • на контроллере и диске ВМ: https://kb.vmware.com/s/article/2053145.

   Важно: если параллелизм операций с хостов ESXi превысит допустимый параллелизм нижележащих HBA, SAN или СХД, то есть совокупная глубина очереди выполняемых в настоящий момент операций ВМ превысит глубину очереди инфраструктуры, то хост будет получать SCSI-примитивы QFULL или BUSY, и в журнале vmkernel.log будут регистрироваться такие события:

   • H:0x0 D:0x28 P:0x0 Valid sense data: 0x## 0x## 0x##

   • H:0x0 D:0x08 P:0x0 Valid sense data: 0x## 0x## 0x##

   • H:0x0 D:0x8 P:0x0 Valid sense data: 0x## 0x## 0x## 

   1. QUED должно равняться 0.

      Это количество команд VMkernel, которые находятся в очереди. Статистика применима только к world и LUN.

      Большое количество команд в очереди может быть признаком того, что система хранения перегружена. Постоянно высокое значение счетчика QUED сигнализирует об узком месте (bottleneck, дословно – «бутылочное горлышко») в системе хранения, которое в некоторых случаях можно устранить, увеличив глубину очереди. После увеличения глубины очереди проверьте, что LOAD меньше 1. Это должно увеличить количество обработанных команд в секунду и повысить производительность.

   2. %USD не должно превышать 60.

      Это процент глубины очереди, используемой активными командами VMkernel. Эта статистика применима только к world и LUN.

      %USD = ACTV / QLEN * 100%.

      Чтобы рассчитать статистику по world, в качестве знаменателя используйте WQLEN. Для статистики LUN (устройства) в качестве знаменателя используйте LQLEN.

      %USD показывает, сколько доступных слотов очереди команд задействованы. Высокие значения говорят о возможности образования очередей. Тогда вам потребуется настроить глубину очередей для HBA, если QUED также постоянно больше 1. Размеры очередей можно настроить в нескольких местах на пути ввода/вывода. Это помогает смягчить проблемы с производительностью, вызванные большими задержками.

   3. FCMDS/s, ABRTS/s, RESETS/s должны равняться 0.

   4. ATSF должен быть значительно меньше ATS.

      Примитив VAAI Atomic Test and Set позволяет ускорить ряд операций с подсистемой хранения. Ниже приведены две статьи, подробно объясняющие каждую операцию. Множество неудавшихся операций ATS могут стать причиной проблем в работе подсистемы хранения.

      Про ATS heartbeat: https://kb.vmware.com/s/article/2113956.

      Про ATS lock: https://kb.vmware.com/s/article/2146451.

   5. Политика мультипасинга должна быть рекомендована вендором СХД.

   6. No of outstanding IOs with competing worlds (DSNRO) должно равняться Queue Depth.

8. Network в esxtop (клавиша ‘n’)

   1. MbTX/s, MbRX/s не должны превышать vmnic.

      Это мегабиты, передаваемые (MbTX) или принимаемые (MbRX) в секунду.

      В зависимости от рабочей нагрузки MbRX/s может не совпадать с PKTRX/s, потому что размер пакетов может быть разным. Средний размер пакета можно рассчитать по формуле: средний размер пакета = MbRX/s / PKTRX/s. Увеличение размера пакетов может повысить эффективность обработки пакетов процессором. Однако потенциально это также может увеличить задержку.

   2. %DRPTX, %DRPRX должны равняться 0.

      %DRPTX – это процент потерянных исходящих пакетов.

      %DRPTX = потерянные исходящие пакеты / (успешно отправленные исходящие пакеты + потерянные исходящие пакеты).

      Высокое значение %DRPTX обычно указывает на проблемы с отправкой данных. Проверьте, полностью ли используются возможности физических сетевых карт. Возможно, нужно заменить сетевые карты на карты с лучшей производительностью. Или вы можете подключить еще несколько сетевых карт и настроить политику балансировки нагрузки, чтобы равномерно распределить нагрузку по всем картам.

      %DRPRX – это процент потерянных входящих пакетов. Вычисляется по формуле: %DRPRX = потерянные входящие пакеты / (успешные принятые входящие пакеты + потерянные входящие пакеты).

      Высокое значение %DRPRX обычно указывает на проблемы с приемом входящего трафика. Стоит выделить больше ресурсов CPU для затронутой ВМ или увеличить размер ring buffer.

9. Network:

   1. Вывод команды esxcli network nic stats get -n vmnicX не должен содержать ошибок.

   2. Статистика релевантных портов vsish не должна содержать ошибок и дропов.

      Бывает так, что ВМ испытывает резкие скачки входящего трафика, способные переполнить Rx Ring Buffers. Расследовать такие ситуации можно, выяснив PORT-ID сетевой карточки ВМ через раздел network утилиты esxtop или командой esxcli network vm list -> посмотреть World ID нужной ВМ -> esxcli network vm port list -w <World ID>.

      Затем в vsish:

      cd/net/portsets/<vSwitch-NAME>/ports/<PORT-ID>/

      cat stats

      packet stats {

         pktsTx:823080899

         pktsTxMulticast:18571

         pktsTxBroadcast:1908

         pktsRx:961804917

         pktsRxMulticast:48602

         pktsRxBroadcast:1947286

         droppedTx:0

         droppedRx:27314

      }

      Ненулевое значение droppedRx может означать превышение Rx Ring Buffers. Расследуем дальше:

      cd /net/portsets/vSwitch0/ports/<PORT-ID>/vmxnet3

      cat rxSummary

      stats of a vmxnet3 vNICrx queue {

         ...

         1st ring size:1024

         2nd ring size:64

         # of times the 1st ring is full:349

         # of times the 2nd ring is full:0

      ...

      }

      Здесь мы видим размеры ring buffers и сколько раз они были переполнены. Ненулевое значение – хороший повод увеличить ring size. Там же есть директория rxqueues, в которой может быть одна или более поддиректорий. Если включена NetQueue или RSS, то в данных директориях можно посмотреть статистику каждой очереди по отдельности.

   3. Вывод команды arp-scan подсети не должен содержать дубликатов IP и MAC-адресов.

   4. Запись трафика в момент воспроизведения проблемы не должна содержать аномалий. Об этом подробнее тут: https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-networking/GUID-C1CEBDDF-1E6E-42A8-A026-0C067DD16AE7.html.

      ***

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

      Часть 1. CPU.

      Часть 2. Memory

      Часть 3. Storage

      На этом я завершаю описание сценария поиска проблем с производительностью ВМ на ESXi. Буду рад обсудить нюансы и ответить на вопросы.