Операционная система Linux использует процессы для выполнения всех системных и пользовательских задач. Эти процессы могут быть заблокированы, остановлены, запущены или ожидают запуска. Количество процессов в последних двух состояниях определяет длину очереди запуска процессора.
Существует несколько возможных состояний процесса, таких как:
- Работоспособный или запущенный
- Прерываемый режим ожидания
- Непрерывный режим ожидания
- Остановлено
- Зомби
Процессы, ожидающие ресурсов или сигналов от других функций, будут находиться либо в состоянии прерываемого, либо бесперебойного ожидания: процесс переводится в спящий режим до тех пор, пока не станут доступны необходимые ему ресурсы. Затем, в зависимости от типа режима ожидания, процесс может либо перейти в состояние, пригодное для выполнения, либо остаться в режиме ожидания.
Даже когда процесс располагает всеми необходимыми ресурсами, он не сразу начинает выполняться. Он переходит в состояние, пригодное для выполнения, где он ставится в очередь вместе с другими процессами в том же состоянии. Центральный процессор может выполнить эти процессы в течение следующих нескольких секунд или миллисекунд. Планировщик выстраивает процессы для центрального процессора и определяет, какой процесс выполнять следующим.
В зависимости от конфигурации аппаратного обеспечения системы длина этой очереди запуска, называемой очередью запуска процессора, может быть короткой или длинной. Короткая длина очереди запуска сигнализирует о том, что процессор используется недостаточно. С другой стороны, если очередь запуска длинная, это означает либо то, что процессор недостаточно мощный для выполнения всех процессов, либо что в процессоре недостаточно ядер. В идеально используемом процессоре длина очереди запуска будет равна количеству ядер в системе.
В операционной системе Linux есть несколько команд, которые помогают определить длину очереди запуска процессора, загрузку процессора и использование ресурсов, чтобы понять, влияет ли это на производительность системы. В этой статье мы рассмотрим некоторые из этих команд и способы их использования.
Команды для мониторинга очереди запуска процессора
Linux поставляется с несколькими командами для мониторинга нагрузки на процессор. Пока мы выполняем эти команды, имейте в виду, что если предоставляемой ими информации недостаточно, инструменты сторонних производителей также являются общедоступными.
Отчет о системной активности (sar)
Команда sar является частью пакета sysstat, который не предустановлен ни в одном дистрибутиве Linux. Его можно установить с помощью следующих команд.
Для систем на базе Debian:
apt install sysstat
Для систем, основанных на RPM:
yum install sysstat
Команда sar помогает собрать всю необходимую статистику активности системы и производительности. Эта команда принимает параметры для отображения показателей о ресурсах, таких как процессор, память, сеть, диски, очереди и многое другое. Параметр q используется для доступа к длине очереди запуска и средней нагрузке на процессор с помощью команды sar. Выходные данные команды предоставляют следующую информацию:
- runq-sz: Длина очереди запуска
- plist-sz: Количество задач в списке задач
- ldavg-1: Средняя загрузка системы за последнюю минуту
- ldavg-5: Средняя загрузка системы за последние пять минут
- ldavg-15: Средняя загрузка системы за последние 15 минут
- blocked: Количество заблокированных в данный момент задач, ожидающих завершения ввода-вывода
Наряду с параметром команде также необходим интервал обновления. Интервал обновления, число, представляет, как часто необходимо обновлять выходные данные. Например, следующая команда будет обновлять выходные данные каждую секунду, добавляя новую строку в таблицу:
sar -q 1
На рисунке 1 ниже показаны выходные данные команды sar, обновляющиеся каждую секунду.
Рис. 1: вывод команды sar
Нагрузка на эту конкретную систему чрезвычайно низкая — очередь запуска на скриншоте равна нулю. Между тем, в списке задач более 768 задач, но внимательное наблюдение показывает, что количество задач уменьшается. Это означает, что нагрузка на эту систему невелика — система перенастроена для задач, которые она выполняет. Средняя загрузка за последние несколько минут также говорит нам о том, что на центральный процессор практически нет нагрузки, хотя это всего лишь одноядерный процессор. Также нет заблокированных процессов.
Команда ps
Команда ps – еще один удобный инструмент для проверки состояния процессов. Список процессов можно фильтровать, используя различные параметры, доступные для команды. Выходные данные ps команды включают в себя STAT столбец, который отображает состояние каждого запущенного процесса. На рисунке 2 показан пример выходных данных.
Рис. 2: вывод команды ps
Первая буква в STAT значении столбца – это состояние процесса, где S означает режим ожидания, а R – возможность выполнения.
Команда top
Команда top может отображать состояние любого процесса. Эти параметры можно использовать для фильтрации результатов и получения списка соответствующих процессов.
Рис. 3: вывод команды top
Столбец S в выходных данных команды top, как показано на рисунке 3, обозначает состояние процесса. На изображении также показана команда top как запущенная (R) и процесс Docker в спящем состоянии.
Команда top также предоставляет три средних значения загрузки процессора в правом верхнем углу. Эти цифры представляют среднюю нагрузку на процессор за последние 1, 5 и 15 минут. На рисунке 3 показано, что средняя загрузка не превышала 0.0 за последние 15 минут.
Файл состояния /proc
Linux хранит всю информацию, связанную с процессом, в виде файлов в каталоге /proc. Каждому процессу присваивается свой собственный каталог, а идентификатор процесса (PID) является именем каталога. Каждый каталог PID содержит файл с именем status, который содержит всю информацию о процессе, включая его состояние. Итак, простое обращение к файлу cat и фильтрация grep State расскажут вам о состоянии процесса. Приведенная ниже команда укажет состояние процесса Docker, запущенного в системе Linux. PID процесса Docker взят с рисунка 3 выше.
cat /proc/126/status | grep State
На рисунке 4 ниже показан вывод этой команды.
Рис. 4: Состояние процесса с использованием файла состояния /proc
Зависимость загрузки процессора от длина очереди запуска: понимание показателей
Три показателя загрузки процессора, предоставляемые такими командами, как команда top, sar, и uptime, представляют нагрузку, которую принимает процессор, и то, сколько свободного места еще доступно. Это число использования включает процессы в запущенном, пригодном для выполнения и прерванном состояниях. Например, число меньше 1.0 на одноядерном процессоре означает, что еще осталось немного места для новых процессов. Нагрузка 1.0 на одноядерный процессор означает, что используется 100% ЦП, в то время как все, что превышает 1.0, означает, что одноядерный процессор перегружен.
Аналогично, для двухъядерного процесса средняя загрузка 2.0 указывает на 100% загрузку процессора, 4.0 для четырехъядерного процессора указывает на 100% загрузку и так далее. Как это использование связано с длиной очереди запуска процессора? Помните, что расчет средней нагрузки включает процессы в запущенных и пригодных для выполнения состояниях, которые также являются состояниями, представляющими очередь запуска процессора. Таким образом, даже если очередь запуска длинная, производительность системы не пострадает, пока средняя нагрузка находится в пределах 1,0 на ядро.
Это связано с тем, что центральный процессор способен эффективно выполнять все процессы вовремя и контролировать среднюю нагрузку даже при большом количестве процессов, ожидающих процессорного времени.
Вам также следует учитывать среднюю нагрузку за последние 5 и 15 минут, поскольку эти цифры указывают на постоянную среднюю нагрузку в течение значительного периода времени. Если процессор перегружен, это приведет к более высокой средней нагрузке.
Как решить проблемы с высокой нагрузкой
Есть два способа решения проблем с высокой нагрузкой: либо добавить больше оборудования в систему, либо оптимизировать код для лучшего использования ресурсов. Например, если кластер серверов регулярно подвергается высокой нагрузке, кластер можно масштабировать, добавив в него больше узлов, или увеличить его объем, добавив больше памяти и более быстрые и мощные процессоры на каждый узел.
Но этот подход может оказаться неустойчивым, если код, выполняемый на этих узлах, не оптимизирован. Например, если код не освобождает память обратно в пул или если код блокирует другие программы, удерживая ресурсы дольше, чем необходимо, добавление дополнительного оборудования не улучшит среднюю нагрузку.
Использование команды iotop откроет список всех процессов, использующих ресурсы ввода-вывода, что упростит понимание того, почему процесс может быть заблокирован (или блокировать другие процессы) или использовать ресурсы в течение длительного времени. Объединение этой информации со средними показателями загрузки процессора должно дать более четкое представление об использовании процессора.
Проблемы с высокой нагрузкой обычно возникают, когда код не оптимизирован, поэтому этому следует уделять основное внимание. Аппаратное масштабирование выполняется только после завершения оптимизации кода.
Вывода
Хотя длина очереди запуска процессора указывает на количество процессов, готовых к планированию в течение процессорного времени, она не всегда дает полную картину. Как показано, большое количество задач в списке задач все еще может привести к низкой нагрузке на процессор.
С другой стороны, даже небольшое количество процессов в очереди запуска может привести к высокой загрузке процессора. В таких случаях важно отслеживать операции ввода-вывода, чтобы выявить узкие места, которые могут быть основной причиной.
Используя команды, перечисленные в этой статье, вы можете легко отслеживать длину очереди, список задач и среднюю нагрузку на процессор. Кроме того, такие меры, как масштабирование кластера и оптимизация кода, могут помочь вам избежать проблем с высокой нагрузкой.