Настройка производительности системы в RHEL

Red Hat Enterprise LinuxBeginner
Практиковаться сейчас

Введение

В этой лабораторной работе вы узнаете, как оптимизировать производительность системы RHEL с помощью tuned и управлять приоритетами процессов с использованием nice и renice. Вы начнете с проверки установки tuned и перечисления доступных профилей, а затем понаблюдаете, как изменение профилей tuned влияет на параметры системы.

Лабораторная работа проведет вас через запуск и мониторинг процессов, интенсивно использующих CPU, с последующей настройкой их приоритетов с помощью nice и renice, чтобы понять их влияние на распределение ресурсов. Наконец, вы узнаете, как очищать запущенные процессы, обеспечивая полное понимание настройки производительности в RHEL.

Проверка статуса tuned и перечисление доступных профилей

На этом шаге вы узнаете, как проверить статус демона tuned и перечислить доступные профили настройки в вашей системе RHEL. tuned — это динамический адаптивный демон настройки системы, который настраивает параметры системы для оптимизации производительности для конкретных рабочих нагрузок. Он использует профили настройки для применения набора общесистемных настроек.

  1. Убедитесь, что демон tuned запущен.
    В этой контейнерной среде мы проверим, запущен ли демон tuned, найдя его процесс. Мы также можем проверить его функциональность, проверив, отвечает ли он на команды.

    Сначала проверьте, запущен ли процесс tuned:

    pgrep tuned

    Если tuned запущен, эта команда вернет его идентификатор процесса (PID). Если PID не возвращается, вы можете запустить демон вручную:

    sudo /usr/sbin/tuned &

    Затем убедитесь, что он запущен:

    pgrep tuned

    Вы должны увидеть вывод, похожий на:

    739

    (Примечание: значение PID в вашем выводе будет отличаться.)

    Кроме того, вы можете проверить, функционален ли tuned, проверив, отвечает ли он на запросы статуса:

    sudo tuned-adm active

    Это должно вернуть текущий активный профиль без ошибок.

  2. Перечислите доступные профили настройки и определите активный профиль.
    Команда 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
  3. Просмотрите конфигурацию профиля 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
  4. Убедитесь, что параметр 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 позволяет быстро применить набор оптимизаций производительности, адаптированных для различных рабочих нагрузок, таких как задачи, интенсивно использующие пропускную способность, или энергосбережение.

  1. Измените текущий активный профиль настройки на throughput-performance.
    Профиль throughput-performance предназначен для систем, которым требуется высокая пропускная способность, часто за счет некоторой задержки. Он обычно оптимизирует ввод-вывод с диска и производительность сети. Используйте команду tuned-adm profile для переключения профилей.

    sudo tuned-adm profile throughput-performance

    Вам будет предложено ввести пароль.

    $ sudo tuned-adm profile throughput-performance
    [sudo] password for user:
  2. Подтвердите новый активный профиль.
    После изменения профиля рекомендуется проверить, что новый профиль действительно активен. Вы можете сделать это с помощью tuned-adm active.

    sudo tuned-adm active

    Вывод теперь должен показывать throughput-performance как активный профиль.

    Current active profile: throughput-performance
  3. Убедитесь, что параметры 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 бесконечного потока нулей, эффективно потребляя циклы ЦП.

Важно: В этом упражнении используются команды, которые выполняют бесконечные контрольные суммы на файле устройства, намеренно потребляя значительные ресурсы ЦП. Вы должны завершить все процессы упражнения, прежде чем покинуть это упражнение или перейти к следующей лабораторной работе.

  1. Определите количество ядер ЦП в вашей системе.
    Понимание количества ядер ЦП помогает вам решить, сколько CPU-интенсивных процессов запускать, чтобы полностью использовать систему. Вы можете найти эту информацию в /proc/cpuinfo.

    grep -c '^processor' /proc/cpuinfo

    Эта команда подсчитывает количество строк, начинающихся с processor, что соответствует количеству логических ядер ЦП (или виртуальных процессоров).

    2

    (Примечание: Ваш вывод может показывать другое количество ядер в зависимости от конфигурации системы.)

  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 в вашем выводе будут отличаться от примера.)

  3. Убедитесь, что фоновые задания запущены.
    Команда jobs перечисляет все процессы, которые в данный момент выполняются в фоновом режиме из вашей сессии оболочки.

    jobs

    Вы должны увидеть список процессов sha1sum, которые вы только что запустили.

    [1]   Running                 sha1sum /dev/zero &
    [2]   Running                 sha1sum /dev/zero &
    [3]   Running                 sha1sum /dev/zero &
    [4]-  Running                 sha1sum /dev/zero &
  4. Используйте команды 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.)

  5. Завершите все запущенные процессы 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 является значением по умолчанию.

  1. Запустите несколько экземпляров sha1sum /dev/zero &, а затем запустите еще один экземпляр со значением nice 10.
    Мы запустим несколько процессов sha1sum, чтобы смоделировать занятую систему. Затем мы запустим один с намеренно более низким приоритетом (более высоким значением nice), чтобы наблюдать эффект.

    Сначала запустите три обычных экземпляра (настройте в зависимости от количества ядер вашего ЦП, если хотите, но не менее, чем виртуальных процессоров, чтобы создать конкуренцию):

    for i in {1..3}; do sha1sum /dev/zero & done

    Затем запустите четвертый экземпляр со значением nice 10. Этот процесс будет иметь более низкий приоритет по сравнению с другими.

    nice -n 10 sha1sum /dev/zero &

    Вы увидите вывод, похожий на этот, указывающий PID фоновых процессов:

    [1] 5443
    [2] 5444
    [3] 5445
    [4] 5446

    (Примечание: значения PID в вашем выводе будут отличаться.)

  2. Используйте команды ps и pgrep, чтобы отобразить PID, процент использования ЦП, значение nice и имя исполняемого файла для каждого процесса.
    Обратите внимание на столбцы %CPU и NI. Экземпляр со значением nice 10 должен отображать меньший процент использования ЦП, чем другие экземпляры, поскольку планировщик выделяет ему меньше времени ЦП.

    ps -o pid,pcpu,nice,comm $(pgrep sha1sum)

    Найдите процесс со значением NI 10. Его %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 должен иметь меньшую долю.)

  3. Используйте команду sudo renice, чтобы изменить значение nice одного из обычных процессов на 5.
    Команда renice позволяет изменить значение nice уже запущенного процесса. Мы продемонстрируем это, изменив один из обычных процессов (значение nice 0) на значение nice 5.

    Сначала определите PID одного из процессов sha1sum, имеющего значение nice 0, из вывода предыдущей команды 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
  4. Повторите команды 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 (более высоким приоритетом) получают больше времени ЦП.)

Очистка запущенных процессов

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

  1. Используйте команду 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
  2. Убедитесь, что процессы sha1sum больше не запущены.
    Вы можете использовать pgrep, чтобы проверить, активны ли еще какие-либо процессы sha1sum. Если pgrep не возвращает никаких результатов, это означает, что такие процессы не запущены.

    pgrep sha1sum

    Эта команда не должна возвращать никаких результатов, что указывает на то, что все процессы sha1sum были успешно завершены.

    $ pgrep sha1sum
    $

Резюме

В этой лабораторной работе мы узнали, как управлять и использовать tuned для оптимизации производительности системы в RHEL. Мы начали с проверки установки и статуса службы tuned и перечисления доступных профилей настройки, понимая, что tuned динамически адаптирует системные настройки для конкретных рабочих нагрузок, используя эти профили. Затем мы попрактиковались в входе в смоделированную среду servera через SSH от имени пользователя labex и подтвердили установку пакета tuned с помощью dnf list tuned.

Лабораторная работа далее провела нас через изменение профилей tuned, чтобы наблюдать их влияние на системные параметры, демонстрируя, как разные профили могут изменять поведение системы. Мы также получили практический опыт запуска и мониторинга процессов, интенсивно использующих ЦП, что имеет решающее значение для выявления узких мест производительности. Наконец, мы научились настраивать приоритеты процессов с помощью команд nice и renice, чтобы эффективно управлять распределением ресурсов, и завершили очисткой запущенных процессов, чтобы вернуть систему в исходное состояние.