Введение
В этой лабораторной работе вы узнаете, как оптимизировать производительность системы RHEL с помощью tuned и управлять приоритетами процессов с использованием nice и renice. Вы начнете с проверки установки tuned и перечисления доступных профилей, а затем понаблюдаете, как изменение профилей tuned влияет на параметры системы.
Лабораторная работа проведет вас через запуск и мониторинг процессов, интенсивно использующих CPU, с последующей настройкой их приоритетов с помощью nice и renice, чтобы понять их влияние на распределение ресурсов. Наконец, вы узнаете, как очищать запущенные процессы, обеспечивая полное понимание настройки производительности в RHEL.
Проверка статуса tuned и перечисление доступных профилей
На этом шаге вы узнаете, как проверить статус демона tuned и перечислить доступные профили настройки в вашей системе RHEL. tuned — это динамический адаптивный демон настройки системы, который настраивает параметры системы для оптимизации производительности для конкретных рабочих нагрузок. Он использует профили настройки для применения набора общесистемных настроек.
Убедитесь, что демон
tunedзапущен. В этой контейнерной среде мы проверим, запущен ли демонtuned, найдя его процесс. Мы также можем проверить его функциональность, проверив, отвечает ли он на команды.Сначала проверьте, запущен ли процесс
tuned:pgrep tunedЕсли
tunedзапущен, эта команда вернет его идентификатор процесса (PID). Если PID не возвращается, вы можете запустить демон вручную:sudo /usr/sbin/tuned &Затем убедитесь, что он запущен:
pgrep tunedВы должны увидеть вывод, похожий на:
739(Примечание: значение PID в вашем выводе будет отличаться.)
Кроме того, вы можете проверить, функционален ли
tuned, проверив, отвечает ли он на запросы статуса:sudo tuned-adm activeЭто должно вернуть текущий активный профиль без ошибок.
Перечислите доступные профили настройки и определите активный профиль. Команда
tuned-adm listотображает все доступные профили настройки и выделяет текущий активный.sudo tuned-adm listВам будет предложено ввести пароль. Обратите внимание на
Current active profileв выводе.Available profiles: - accelerator-performance - Throughput performance based tuning with disabled higher latency STOP states - aws - Optimize for aws ec2 instances - balanced - General non-specialized tuned profile - balanced-battery - Balanced profile biased towards power savings changes for battery - desktop - Optimize for the desktop use-case - hpc-compute - Optimize for HPC compute workloads - intel-sst - Configure for Intel Speed Select Base Frequency - latency-performance - Optimize for deterministic performance at the cost of increased power consumption - network-latency - Optimize for deterministic performance at the cost of increased power consumption, focused on low latency network performance - network-throughput - Optimize for streaming network throughput, generally only necessary on older CPUs or 40G+ networks - optimize-serial-console - Optimize for serial console use. - powersave - Optimize for low power consumption - throughput-performance - Broadly applicable tuning that provides excellent performance across a variety of common server workloads - virtual-guest - Optimize for running inside a virtual guest - virtual-host - Optimize for running KVM guests Current active profile: virtual-guestПросмотрите конфигурацию профиля
virtual-guest. Профильvirtual-guestчасто является настройкой по умолчанию для виртуальных машин. Вы можете проверить его файл конфигурации, чтобы понять, какие настройки он применяет.cat /usr/lib/tuned/virtual-guest/tuned.confЭта команда показывает конфигурацию
tunedдля профиляvirtual-guest, включая параметры, которые он наследует от других профилей.# ## tuned configuration # [main] summary=Optimize for running inside a virtual guest include=throughput-performance [vm] ## If a workload mostly uses anonymous memory and it hits this limit, the entire ## working set is buffered for I/O, and any more write buffering would require ## swapping, so it's time to throttle writes until I/O can catch up. Workloads ## that mostly use file mappings may be able to use even higher values. # ## The generator of dirty data starts writeback at this percentage (system default ## is 20%) dirty_ratio = 30 [sysctl] ## Filesystem I/O is usually much more efficient than swapping, so try to keep ## swapping low. It's usually safe to go even lower than this on systems with ## server-grade storage. vm.swappiness = 30Убедитесь, что параметр
vm.dirty_background_ratioприменен. Профильvirtual-guestвключаетthroughput-performance. Давайте проверим параметр, который обычно устанавливаетthroughput-performance, напримерvm.dirty_background_ratio. Этот параметр контролирует, когда система начинает записывать грязные страницы на диск в фоновом режиме.sysctl vm.dirty_background_ratioВывод покажет текущее значение этого параметра ядра.
vm.dirty_background_ratio = 10
Изменение профиля tuned и наблюдение за изменениями параметров системы
На этом шаге вы узнаете, как изменить активный профиль tuned и наблюдать непосредственные эффекты на параметры системы. Изменение профиля tuned позволяет быстро применить набор оптимизаций производительности, адаптированных для различных рабочих нагрузок, таких как задачи, интенсивно использующие пропускную способность, или энергосбережение.
Измените текущий активный профиль настройки на
throughput-performance. Профильthroughput-performanceпредназначен для систем, которым требуется высокая пропускная способность, часто за счет некоторой задержки. Он обычно оптимизирует ввод-вывод с диска и производительность сети. Используйте командуtuned-adm profileдля переключения профилей.sudo tuned-adm profile throughput-performanceВам будет предложено ввести пароль.
$ sudo tuned-adm profile throughput-performance [sudo] password for user:Подтвердите новый активный профиль. После изменения профиля рекомендуется проверить, что новый профиль действительно активен. Вы можете сделать это с помощью
tuned-adm active.sudo tuned-adm activeВывод теперь должен показывать
throughput-performanceкак активный профиль.Current active profile: throughput-performanceУбедитесь, что параметры
vm.dirty_ratioиvm.swappinessизменились. Профильthroughput-performanceизменяет параметры ядра, связанные с управлением памятью, такие какvm.dirty_ratioиvm.swappiness. Даже если профильvirtual-guestнаследует отthroughput-performance, прямое переключение на профильthroughput-performanceприменяет базовые значения без специфичных для virtual-guest модификаций.vm.dirty_ratio: Этот параметр определяет максимальный процент системной памяти, который может быть заполнен грязными страницами (страницами, которые были изменены, но еще не записаны на диск), прежде чем система начнет записывать их на диск. Более высокое значение может улучшить пропускную способность, позволяя буферизировать больше данных в памяти.vm.swappiness: Этот параметр контролирует, насколько агрессивно ядро выгружает анонимную память (данные приложений) из ОЗУ в пространство подкачки. Более низкое значение означает, что ядро будет пытаться сохранить больше данных приложений в ОЗУ, что, как правило, лучше для производительности.
Давайте проверим их текущие значения с помощью
sysctl.sysctl vm.dirty_ratio sysctl vm.swappinessВы должны заметить, что значения изменились с настроек профиля
virtual-guest(dirty_ratio = 30, vm.swappiness = 30) на базовые значения профиляthroughput-performance:vm.dirty_ratio = 40 vm.swappiness = 10(Примечание: Эти значения отражают базовые оптимизации throughput-performance без специфичных для virtual-guest модификаций.)
Запуск и мониторинг CPU-интенсивных процессов в RHEL
На этом шаге вы узнаете, как запускать CPU-интенсивные процессы и отслеживать использование ими ресурсов. Это крайне важно для понимания того, как процессы потребляют системные ресурсы, и для выявления узких мест. Мы будем использовать команду sha1sum /dev/zero, которая непрерывно вычисляет контрольную сумму SHA1 бесконечного потока нулей, эффективно потребляя циклы ЦП.
Важно: В этом упражнении используются команды, которые выполняют бесконечные контрольные суммы на файле устройства, намеренно потребляя значительные ресурсы ЦП. Вы должны завершить все процессы упражнения, прежде чем покинуть это упражнение или перейти к следующей лабораторной работе.
Определите количество ядер ЦП в вашей системе. Понимание количества ядер ЦП помогает вам решить, сколько CPU-интенсивных процессов запускать, чтобы полностью использовать систему. Вы можете найти эту информацию в
/proc/cpuinfo.grep -c '^processor' /proc/cpuinfoЭта команда подсчитывает количество строк, начинающихся с
processor, что соответствует количеству логических ядер ЦП (или виртуальных процессоров).2(Примечание: Ваш вывод может показывать другое количество ядер в зависимости от конфигурации системы.)
Запустите два экземпляра команды
sha1sum /dev/zero &для каждого ядра ЦП. Чтобы смоделировать сильно загруженную систему, мы запустим несколько экземпляровsha1sum /dev/zero &. Символ&в конце команды запускает процесс в фоновом режиме, позволяя вам продолжать использовать терминал. Например, если у вас 2 ядра ЦП, вы запустите 4 экземпляра (2 экземпляра/ядро * 2 ядра).for i in $(seq 1 $(grep -c '^processor' /proc/cpuinfo | awk '{print $1 * 2}')); do sha1sum /dev/zero & doneЭта команда динамически вычисляет количество процессов для запуска на основе количества ядер вашего ЦП.
[1] 1234 [2] 1235 [3] 1236 [4] 1237(Примечание: значения PID в вашем выводе будут отличаться от примера.)
Убедитесь, что фоновые задания запущены. Команда
jobsперечисляет все процессы, которые в данный момент выполняются в фоновом режиме из вашей сессии оболочки.jobsВы должны увидеть список процессов
sha1sum, которые вы только что запустили.[1] Running sha1sum /dev/zero & [2] Running sha1sum /dev/zero & [3] Running sha1sum /dev/zero & [4]- Running sha1sum /dev/zero &Используйте команды
psиpgrep, чтобы отобразить процент использования ЦП для каждого процессаsha1sum. Командаpsсообщает снимок текущих процессов. Мы объединим ее сpgrep, чтобы отфильтровать процессыsha1sum.ps -o pid,pcpu,nice,comm: Это определяет формат вывода: идентификатор процесса (pid), процент использования ЦП (pcpu), значениеnice(nice) и имя команды (comm).$(pgrep sha1sum): Эта подстановка команды находит PID всех процессов с именемsha1sumи передает их в качестве аргументов дляps.
ps -o pid,pcpu,nice,comm $(pgrep sha1sum)Вы должны увидеть, что каждый процесс
sha1sumпотребляет значительный процент ЦП.PID %CPU NI COMMAND 5248 48.8 0 sha1sum 5249 48.7 0 sha1sum 5250 48.8 0 sha1sum 5251 48.8 0 sha1sum(Примечание: значения
%CPUмогут колебаться, но должны быть высокими, что указывает на интенсивное использование ЦП. СтолбецNIпоказывает значение nice.)Завершите все запущенные процессы
sha1sumи убедитесь, что ни один из них не остался. Крайне важно очистить эти CPU-интенсивные процессы, прежде чем продолжить. Командаpkillзавершает процессы по их имени.pkill sha1sumТеперь убедитесь, что в фоновом режиме не запущено ни одного задания
sha1sum.jobsВывод должен быть пустым или указывать, что все задания завершены.
[1] Terminated sha1sum /dev/zero [2] Terminated sha1sum /dev/zero [3] Terminated sha1sum /dev/zero [4]- Terminated sha1sum /dev/zero(Примечание: Вы можете увидеть сообщения "Terminated", что ожидаемо, поскольку процессы останавливаются.)
Настройка приоритета процессов с помощью nice и renice в RHEL
На этом шаге вы узнаете, как влиять на приоритет планирования процессов с помощью команд nice и renice. Значение nice (также известное как niceness) процесса указывает его приоритет для планировщика Linux. Более низкое значение nice (более отрицательное) означает более высокий приоритет, в то время как более высокое значение nice (более положительное) означает более низкий приоритет. Диапазон значений nice обычно от -20 (самый высокий приоритет) до 19 (самый низкий приоритет), при этом 0 является значением по умолчанию.
Запустите несколько экземпляров
sha1sum /dev/zero &, а затем запустите еще один экземпляр со значениемnice10. Мы запустим несколько процессовsha1sum, чтобы смоделировать занятую систему. Затем мы запустим один с намеренно более низким приоритетом (более высоким значениемnice), чтобы наблюдать эффект.Сначала запустите три обычных экземпляра (настройте в зависимости от количества ядер вашего ЦП, если хотите, но не менее, чем виртуальных процессоров, чтобы создать конкуренцию):
for i in {1..3}; do sha1sum /dev/zero & doneЗатем запустите четвертый экземпляр со значением
nice10. Этот процесс будет иметь более низкий приоритет по сравнению с другими.nice -n 10 sha1sum /dev/zero &Вы увидите вывод, похожий на этот, указывающий PID фоновых процессов:
[1] 5443 [2] 5444 [3] 5445 [4] 5446(Примечание: значения PID в вашем выводе будут отличаться.)
Используйте команды
psиpgrep, чтобы отобразить PID, процент использования ЦП, значениеniceи имя исполняемого файла для каждого процесса. Обратите внимание на столбцы%CPUиNI. Экземпляр со значениемnice10 должен отображать меньший процент использования ЦП, чем другие экземпляры, поскольку планировщик выделяет ему меньше времени ЦП.ps -o pid,pcpu,nice,comm $(pgrep sha1sum)Найдите процесс со значением
NI10. Его%CPUдолжен быть заметно ниже, чем у других.PID %CPU NI COMMAND 5443 56.8 0 sha1sum 5444 58.0 0 sha1sum 5445 56.5 0 sha1sum 5446 6.7 10 sha1sum(Примечание: точные значения
%CPUбудут варьироваться в зависимости от нагрузки на систему и количества ядер, но процесс сnice 10должен иметь меньшую долю.)Используйте команду
sudo renice, чтобы изменить значениеniceодного из обычных процессов на 5. Командаreniceпозволяет изменить значениеniceуже запущенного процесса. Мы продемонстрируем это, изменив один из обычных процессов (значение nice 0) на значение nice 5.Сначала определите PID одного из процессов
sha1sum, имеющего значениеnice0, из вывода предыдущей командыps. Давайте используем первый из приведенного выше примера (PID 5443).sudo renice -n 5 <PID_of_regular_process>Замените
<PID_of_regular_process>фактическим PID, который вы определили. Например:sudo renice -n 5 5443Вы должны увидеть вывод, подтверждающий изменение приоритета:
5443 (process ID) old priority 0, new priority 5Повторите команды
psиpgrep, чтобы отобразить процент использования ЦП и значениеnice. Наблюдайте изменение использования ЦП для процесса, значениеniceкоторого вы изменили. Процесс со значением nice 5 теперь должен иметь немного меньшее использование ЦП по сравнению с процессами со значением nice 0, но больше, чем процесс со значением nice 10.ps -o pid,pcpu,nice,comm $(pgrep sha1sum)Вы должны увидеть, что значение
NIдля измененного процесса теперь равно5, и его использование ЦП отражает его новый уровень приоритета.PID %CPU NI COMMAND 5443 55.4 5 sha1sum 5444 67.2 0 sha1sum 5445 67.1 0 sha1sum 5446 7.5 10 sha1sum(Примечание: точные значения
%CPUбудут варьироваться, но вы должны наблюдать, что процессы с более низкими значениями nice (более высоким приоритетом) получают больше времени ЦП.)
Очистка запущенных процессов
На этом заключительном шаге вы убедитесь, что все фоновые процессы, запущенные во время лабораторной работы, были правильно завершены. Это критический шаг очистки, чтобы предотвратить непреднамеренное потребление ресурсов и убедиться, что лабораторная среда сброшена для дальнейшего использования.
Используйте команду
pkill, чтобы завершить все запущенные процессы с шаблоном имениsha1sum. Командаpkill— это эффективный способ отправки сигнала (по умолчаниюSIGTERM) процессам на основе их имени. Это остановит все процессыsha1sum, которые вы запустили на предыдущих шагах.pkill sha1sumВы можете увидеть сообщения, указывающие на то, что процессы были завершены.
[3]- Terminated sha1sum /dev/zero [2]- Terminated sha1sum /dev/zero [4]+ Terminated nice -n 10 sha1sum /dev/zero [1]+ Terminated sha1sum /dev/zeroУбедитесь, что процессы
sha1sumбольше не запущены. Вы можете использоватьpgrep, чтобы проверить, активны ли еще какие-либо процессыsha1sum. Еслиpgrepне возвращает никаких результатов, это означает, что такие процессы не запущены.pgrep sha1sumЭта команда не должна возвращать никаких результатов, что указывает на то, что все процессы
sha1sumбыли успешно завершены.$ pgrep sha1sum $
Резюме
В этой лабораторной работе мы узнали, как управлять и использовать tuned для оптимизации производительности системы в RHEL. Мы начали с проверки установки и статуса службы tuned и перечисления доступных профилей настройки, понимая, что tuned динамически адаптирует системные настройки для конкретных рабочих нагрузок, используя эти профили. Затем мы попрактиковались в входе в смоделированную среду servera через SSH от имени пользователя labex и подтвердили установку пакета tuned с помощью dnf list tuned.
Лабораторная работа далее провела нас через изменение профилей tuned, чтобы наблюдать их влияние на системные параметры, демонстрируя, как разные профили могут изменять поведение системы. Мы также получили практический опыт запуска и мониторинга процессов, интенсивно использующих ЦП, что имеет решающее значение для выявления узких мест производительности. Наконец, мы научились настраивать приоритеты процессов с помощью команд nice и renice, чтобы эффективно управлять распределением ресурсов, и завершили очисткой запущенных процессов, чтобы вернуть систему в исходное состояние.



