Повышение эффективности работы системы в зависимости от текущих реалий нагрузки на основе oeAware
Мы уже неоднократно писали о вопросах повышения производительности серверных систем на основе фирменных технологий openEuler/OpenScaler — в частности флагманом в данном направлении всегда была система A-Tune о которой мы ранее неоднократно писали и рассказывали о вариантах ее применения в зависимости от сценария эксплуатации сервера (к примеру, веб-сервер, сервер баз данных и пр.)
Кратко напомним, A-Tune — Представляет собой автоматизированную систему анализа типа нагрузки и оптимизации производительности сервера в зависимости от профилей его нагрузки, используемого программного обеспечения и условий его эксплуатации.
Но кажется у данного решения начал появляться серьезный конкурент в лице решения oeAware, заявленного в числе передовых инновационных проектов сообщества openEuler в конце 2025 года (согласно опубликованному Technical Whitepaper) . И вот он уже с нами, oeAware доступен в наших репозиториях для дистрибутива OpenScaler 24.03 LTS SP3 и вы можете опробовать его уже сейчас.
В отличие от A-tune, куда более тяжелого и сложного решения oeAware использует иной подход к оптимизации производительности системы основываясь на фактических показателях загрузки определенных типов ресурсов системы (вычислительные ядра/потоки, нагрузка на сетевую подсистему и пр.) абстрагируясь от таких более общих и всеобъемлющих сценариев типа “лучшие настройки для СУБД” и ориентируясь в первую очередь на общую оптимизацию производительности системы исходя из текущей ситуации.
Итак, что же такое oeAware. oeAware — это фреймворк, который обеспечивает сбор данных по работе системы, их распознавание и трактовку с последующим применением оптимальных параметров исходя их текущей ситуации в системе
Примечательно что разработку фреймворка oeAware ведет та же SIG группа что ранее представила миру A-Tune. По мнению разработчиков, действительно, разработка оптимизации на уровне “сценариев применения” долгий и тяжелый процесс, почему бы не пойти от обратного и используя фактические данные по работе системы не моделировать изменение настроек поведения ОС на лету, не ориентируясь на “Best practice” а лишь на эмпирические показатели в конкретный момент времени.
Фреймворк делит процесс настройки на три уровня:
сбор данных по работе системе (Collection Instance)
распознавание и трактовка собранных данных с целью формирования списка изменения настроек (Sensing instance)
Фактическое применение новых параметров. (Tuning Instance)
Каждый уровень разрабатывается в виде набора плагинов (файлы *.so) которые могут быть независимо друг от друга отключены/включены, в зависимости от потребностей системного администратора.
Каждый плагин по сути отвечает за один или несколько параметров наблюдения — что позволяет максимально гибко настроить продукт на оперирование только действительно необходимыми с точки зрения администратора параметрами.
Уровни Распознавания и фактического применения параметров — взаимозависимы и соответственно используемые в них плагины должны соответствовать друг другу. Уровень сбора данных независим и может включать большое количество активных плагинов как представлено на рисунке 1.
Рисунок 1 — Взаимозависимость уровней в решении oeAware
Каждый плагин oeAware представляет собой динамическую библиотеку, использующую интерфейсы oeAware. Плагины включают в себя несколько экземпляров — индивидуально наблюдаемых параметров
SDK позволяет внешним приложениям создавать специальные функциональные возможности и задействовать функционал oeAware
Модуль сбора информации о блоке мониторинга производительности (PMU) собирает данные о производительности из системного модуля PMU.
Модуль сбора информации Docker извлекает сведения о конкретных параметрах контейнеров Docker в среде.
Модуль сбора системной информации собирает параметры ядра, сведения о потоках и информацию о ресурсах (процессоры, память, операции ввода-вывода, сеть) из текущей среды.
Модуль распознавания потоков отслеживает ключевую информацию о потоках.
Модуль оценки проверяет системный NUMA и сетевую информацию во время операций обслуживания, предлагая оптимальные методы настройки.
Плагины настройки системы включают stealtask для расширенной настройки процессора, smc_tune (SMC-D) который использует обмен данными с общей памятью в пространстве ядра для повышения пропускной способности сети и уменьшения задержки, xcall_tune (XCALL), который обходит несущественные пути кода для минимизации затрат на обработку системных вызовов, seep_tune, который регулирует частоту ядер процессора в режиме реального времени для снижения энергопотребления, и dynamic_smt_tune, который планирует очереди SMT в периоды низкой нагрузки для уменьшения помех между SMT0 и SMT1
Плагин настройки Docker устраняет проблемы с производительностью процессора во время внезапных скачков нагрузки используя функцию пакетной загрузки процессора.
Плагин настройки NUMA поддерживает автоматическую привязку ядра и миграцию памяти, устраняя узкие места в доступе к памяти NUMA.
Модуль настройки сетевой карты отслеживает соответствие между сетевым трафиком и процессорами в режиме реального времени и связывает прерывания очереди сетевой карты в режиме реального времени для повышения производительности приложений, требующих интенсивного сетевого ввода-вывода.
Настройка Transparent hugegage (THP) применяется к приложениям, которые часто пропускают кэш последнего уровня (LLC).
sysBoost сокращает количество непрямых переходов между командами за счет объединения и оптимизации файлов ELF.
Координация вычислительной мощности позволяет временно распределять незанятые ресурсы центрального процессора с хоста на необходимые экземпляры контейнеров.
Ограничения
smc_tune: Перед установлением соединения сервер-клиент необходимо включить ускорение SMC. Этот плагин наиболее эффективен в сценариях с большим количеством постоянных подключений.
Настройка Docker: Этот плагин несовместим с контейнерами Kubernetes.
xcall_tune: Должна быть активирована опция конфигурации ядра FAST_SYSCALL.
С точки зрения сценариев применения то на текущий момент разработчики решения oeAware выделяют следующее:
stealtask идеально подходит для сценариев, направленных на повышение загрузки ЦП, например, в Doris. Этот экземпляр настройки эффективно увеличивает загрузку ЦП и предотвращает циклы простоя ЦП.
xcall_tune предназначен для приложений с существенной нагрузкой на системные вызовы. Он предлагает пути обхода некритичных процессов, оптимизируя обработку системных вызовов и снижая накладные расходы. Однако такой подход может поставить под угрозу некоторые возможности обслуживания и безопасности.
smc_tune отлично подходит для сред, требующих высокой пропускной способности и низкой задержки, включая высокопроизводительные вычисления (HPC), обработку больших объемов данных и облачные платформы. Используя прямой доступ к памяти (DMA), smc_tune значительно снижает нагрузку на процессор и ускоряет интерактивные рабочие нагрузки.
CPU burst разработан специально для контейнерных сред с высокой нагрузкой, таких как Doris, и устраняет проблемы с производительностью, вызванные ограничениями процессора.
Проведем установку данного решения и посмотрим как это выглядит на живой системе. Установку будем проводить на основе дистрибутива OpenScaler 24.03 LTS SP3. Как ранее было сказано, решение oeAware уже доступно в штатных репозиториях нашего дистрибутива так что для его установки достаточно просто выполнить команду
yum install oeAware-manager
Система установит само решение и весь перечень требуемых зависимостей. По завершению установки, необходимо запустить сам сервис oeAware выполнив команду
systemctl start oeaware
Убедимся что сервис успешно запустился выполнив команду
systemctl status oeaware как представлено на рисунке 2.
Рисунок 2 — запущенный сервис oeaware
Все доступные на текущий момент плагины работы сервиса доступны в следующих каталогах:
Плагины сбора данных (Collection): /usr/lib64/oeAware-plugin/collector
Плагины трактовки данных (Sensing): /usr/lib64/oeAware-plugin/scenario
Плагины применения настроек (Tuning): /usr/lib64/oeAware-plugin/tune
По умолчанию, все доступные системе плагины загружаются и доступны для управления, ознакомиться с полным списком доступных плагинов можно выполнив команду
oeawarectl -q
Как представлено на рисунке 3.
Рисунок 3 — список доступных плагинов oeAware и их текущий статус
При необходимости можно как отключать доступные модули так и подгружать новые самостоятельно используя команды
oeawarectl -r <plugin name> | —remove <plugin name> — Для удаления
oeawarectl -l | —load <plugin name> -t | —type <plugin type> — для добавления.
Причем необходимо отметить что для загрузки собственных модулей необходимо указать не только его имя но и его принадлежность к одной из трех ранее описанных коллекций плагинов (либо Collecting/Sensing/Tunning).
Для включения или отключения какого либо из доступных системе плагинов используются команды
oeawarectl -e | —enable <plugin instance>
oeawarectl -d | —disable <plugin instance>
Выполнив команду oeawarectl -Q система может сгенерировать схему всех задействованных на данный момент плагинов и их взаимосвязь как представлено на рисунке 4.
Рисунок 4 — Взаимосвязь компонентов
В рамках наших дальнейших статей мы постараемся погрузится в изучение данного инструмента а также структуру плагинов и изучим возможность их самостоятельного создания и применения в реальных сценариях эксплуатации. Следите за нашими обновлениями.