A-Tune: тонкая настройка системы с использованием машинного обучения

Привет, Хабр!

Меня зовут Артём, я инженер-программист в департаменте серверных решений. В статье расскажу про новый инструмент для повышения производительности, который получилось портировать и доработать для ОС Astra Linux Special Edition.

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

А что если я скажу, что работу серверных приложений можно оптимизировать без изменений в исходном коде и без дополнительных мощностей, необходимых для масштабирования систем?

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

Одним из ярких представителей таких утилит является A-Tune. Она включена в состав дистрибутива openEuler, который на текущий момент поддерживается и развивается независимым открытым сообществом разработчиков.

Я решил проанализировать существующие на рынке решения, поскольку мы столкнулись с тем, что пользователям Astra Linux нужно было повысить производительность на серверных сценариях. Проведенный анализ программ для тюнинга выявил большой потенциал у A-Tune в сфере оптимизации производительности операционной системы Astra Linux Special Edition в варианте лицензирования «Сервер» (ОС СН ALSE Сервер).

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

• A-Tune определяет оптимальные параметры за счет применения алгоритмов оптимизации. Другие приложения подобного класса используют заранее подготовленную информацию о влиянии параметров на производительность ОС.

• A-Tune использует машинное обучение для определения текущей нагрузки. Подобный подход интересен для серверов с динамической и скачкообразной нагрузкой.

• A-Tune может распределенно управлять оптимизацией настроек сервера.

Утилита умеет работать в трех режимах:

• Статический режим. Автоматизирует установку заданных параметров в системе.

• Динамический режим. Автоматизирует поиск оптимальных параметров.

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

Подробнее об этих режимах расскажу ниже.

Статический режим работы A-Tune

В терминах A-Tune, профиль — это набор секций с настройками для компонента системы, где каждая секция, в свою очередь, называется плагином. Утилита в своем составе имеет уже набор готовых профилей и функционал для их применения в операционной системе, который называется статическим режимом работы.

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

Команды для работы с профилями

# включить A-Tune systemctl start atuned  # посмотреть список доступных профилей atune-adm list  вывод: Support profiles: +---------------------------------------------+-----------+ | ProfileName                                 | Active    | +=============================================+===========+ | arm-native-android-container-robox          | false     | +---------------------------------------------+-----------+ | basic-test-suite-baseline-fio               | false     | +---------------------------------------------+-----------+ | basic-test-suite-baseline-lmbench           | false     | +---------------------------------------------+-----------+ | basic-test-suite-baseline-netperf           | false     | +---------------------------------------------+-----------+ | default-default                             | false     | +---------------------------------------------+-----------+  # применить профиль из списка atune-adm profile [профиль]  # пример применения профиля  atune-adm profile default-default    вывод:  [ SUGGEST] Bios                                     please change the BIOS configuration NUMA to Enable   [ SUGGEST] Bootloader                               Need reboot to make the config change of grub effect.   [ SUCCESS] memory                                   memory num is 0, memory interpolation is correct     [ SUGGEST] Kernel                                   please change the kernel configuration CONFIG_NUMA_AWARE_SPINLOCKS to y   # посмотреть информацию о профиле  atune-adm info [профиль]  # задать пользовательский профиль  atune-adm define [тип сервиса] [название приложения] [название пользовательского сценария] [путь к файлу с профилем]  # удалить профиль (только для профилей, заданных пользователем) atune-adm undefine [профиль]

Чтобы применить оптимальный профиль, нужно знать, какой из них лучше всего подходит под желаемый сценарий использования системы. Решить данную задачу призвана одна из главных особенностей утилиты — определение оптимального профиля с помощью классификаторов из sklearn и xgboost. Для определения профиля A-Tune запускает анализ рабочей нагрузки, в ходе которого собираются данные о состоянии системы через A-Tune-Collector. Данный модуль вызывает консольные команды мониторинга:

• sar — выводит статистику скорости ввода/вывода, активности подкачки, активности процессов, прерываний, сетевой активности, использования оперативной памяти и подкачки, использования ЦП, активности ядра и TTY, а также многое другое.

• mpstat — возвращает статистику использования процессоров в системе. Команда показывает развёрнутую статистику или всех процессов системы (mpstat -P ALL), или каждого по отдельности (mpstat -P 0), где 0 (ноль) отмечается как первый процессор.

• iostat — отображает основные параметры ввода/вывода данных на диск, скорость записи и чтения данных, а также объем записанных или прочитанных данных, выводит параметры загруженности процессора.

• lshw — Linux Hardware Lister, показывает детальную информацию о компонентах компьютера: процессоре, конфигурации оперативной памяти, материнской плате, BIOS информацию, конфигурацию кэша, шины и т. д. (в комплекте с утилитой также имеется база данных оборудования с USB- и PCI-интерфейсами).

• perf stat — cобирает статистику производительности различных операций в ядре и пользовательском пространстве.

После вызова команд модуль парсит результаты и компонует их в вектор данных, который отправляется на вход классификатора. По результатам сопоставления входных данных с имеющимися определяется типовая нагрузка и ее название, после чего уже происходит сопоставление с наиболее подходящим профилем. В A-Tune используются классификаторы: Random Forest Classifier, Support Vector Machine Classifier и XGBoost classifier. Последний основан на градиентном бустинге деревьев.

Определение профиля с помощью классификатора осуществляется командой atune-adm analysis, использующей подготовленные математические модели.

Определение рабочей нагрузки

# запустить определение профиля с параметрами по умолчанию (20 интервалов измерения состояния системы без применения профиля) atune-adm analysis  # запустить определение профиля и задать число интервалов измерения atune-adm analysis -t 5  # запустить определение профиля, используя заранее сгенерированную модель (например, с именем self_trained.m в текущей директории) atune-adm analysis --model ./self_trained.m  # запустить определение профиля и применить оптимальный профиль atune-adm analysis --apply

Чтобы распознать уникальные типы нагрузки, существует возможность обучения A-Tune средствами утилиты для генерации отдельной математической модели.

Шаги для генерации математической модели:

1. Создание профиля для нагрузки, которую A-Tune будет учиться распознавать. Для этого необходимо воспользоваться командой atune-adm define, которой на вход подается файл с пустым профилем.Общий вид команды создания профиля

   atune-adm define [тип сервиса] [название приложения] [название пользовательского сценария] [путь к файлу с пустым профилем]

   Пример:

   Создать профиль для нагрузки

   # пакет atune устанавливает пустой профиль, который мы можем использовать - generic_profile.conf atune-adm define bench sysbench cpu /usr/lib/atuned/profiles/generic/generic_profile.conf

   Проверить результат работы команды можно выводом списка доступных профилей в утилите A-Tune:

   Новый профиль

   atune-adm list | grep bench-sysbench-cpu  вывод: | bench-sysbench-cpu                          | false     |

2. Подача нагрузки на систему и сбор данных через команду atune-adm collection. Для ее реализации необходимо собрать данные для двух и более классов нагрузки, чтобы обучить классификаторы (при одном классе нагрузки A-Tune сообщит об ошибке работы). Так формируется датасет с лейблом профиля, который подходит под этот тип нагрузки.

   Общий вид команды сбора данных

   atune-adm collection -f [имя файла] -o [путь для сохранения датасета]   -b [диск, на котором находится файловая система, используемая приложением]   -n [имя сетевого адаптера]   -i [количество интервалов сбора данных (по умолчанию 5)]   -d [длительность (в секундах) сбора данных (по умолчанию 1200)]   -t [имя профиля, который мы создали ранее, или тип сервиса для существующего профиля] 

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

   Сбор данных

   # запустим нагрузку, например sysbench sysbench cpu --threads=16 --time=120 --cpu-max-prime=10000 run  # соберем данные под нагрузкой atune-adm collection -f testcpu -o /home/astra/atune/test/ -b sda -n enp0s3 -d 120 -t bench-sysbench-cpu  # соберем данные без нагрузки, т. е. без запуска sysbench atune-adm collection -f testcpu -o /home/astra/atune/test/ -b sda -n enp0s3 -d 120 -t default

   Когда работа команды завершится, в каталоге /home/astra/atune/test будут находиться CSV-файлы с собранной статистикой.

3. Обучение математической модели на полученном датасете. Осуществляется командой atune-adm train.

   Обучение математической модели

   atune-adm train --data_path=/home/astra/atune/test/ --output_file=/home/astra/atune/test/testcpu.m

4. Классификация профиля с использованием модели. Осуществляется с помощью команды: atune-adm analysis --model <путь к сгенерированной модели>.

   Использование модели для классификации профиля

   atune-adm analysis --model /home/astra/atune/test/testcpu.m

   Если мы с использованием созданной модели дадим команду определения профиля под работу нашего приложения, то увидим, что A-Tune автоматически применила созданный нами в самом начале профиль. Он работает согласно той модели, которую мы обучили на собранных данных.

Динамический режим работы A-Tune

Вторым режимом работы A-Tune является динамический режим. В нем утилита дает возможность автоматически искать оптимальную конфигурацию, минимизируя затраты на ручную настройку и оценку производительности. Такой подход существенно повышает эффективность тюнинга (около 10%) и применяется в случае, когда у продвинутых пользователей повышенные требования к производительности.

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

Ключевые особенности этого режима работы:

1. Автоматический выбор значимых параметров для уменьшения пространства поиска и повышения эффективности обучения.

2. Пользовательский выбор оптимального алгоритма в зависимости от сценария применения приложения, типов параметров и требуемой производительности.

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

Одно из условий запуска динамического режима работы — наличие конфигурационных yaml-файлов для сервера и клиента. Файл сервера содержит информацию о векторе управляемых параметров. Для каждого такого параметра задается его вид: дискретный или непрерывный, область допустимых значений и bash-команды для записи и чтения параметров.
Файл клиента содержит информацию о целевых функциях многокритериальной оптимизации: bash-команда для получения значения функции, вес функции, тип функции: positive — оптимум в минимуме, negative — оптимум в максимуме. Кроме того, в файле определяется алгоритм оптимизации, который будет использоваться в рамках тюнинга.

Описание файла конфигурации представлено в таблице 1.

Таблица 1 — Структура данных файла сервера

Имя	Описание	Тип	Диапазон значений
project	Название проекта.	Character string	—
startworkload	Скрипт для запуска оптимизируемого сервиса.	Character string	—
stopworkload	Скрипт для остановки службы, подлежащий оптимизации.	Character string	—
maxiterations	Максимальное количество итераций оптимизации, которое используется для ограничения количества итераций на клиенте. Как правило, чем больше итераций оптимизации, тем лучше эффект оптимизации, но тем больше требуется времени.	Integer	>10
object	Параметры, которые необходимо оптимизировать (вектор управляемых параметров), и связанная с ними информация.	—	—

Детальное описание вектора управляемых параметров представлено в таблице 2.

Таблица 2 — Информация о векторе управляемых параметров файла сервера

Имя	Описание	Тип	Диапазон значений
name	Параметр, требующий оптимизации.	Character string	—
desc	Описание оптимизируемого параметра.	Character string	—
get	Скрипт для запроса значений параметров.	—	—
set	Скрипт для настройки значений параметров.	—	—
needrestart	Флаг перезапуска службы для применения параметра.	Enumeration	true или false
type	Тип параметра. В настоящее время поддерживаются типы discrete и continuous.	Enumeration	дискретный или непрерывный
dtype	Этот параметр доступен только в том случае, если для параметра type установлено значение discrete. В настоящее время поддерживаются только int, float и string.	Enumeration	int, float, string
scope	Диапазон настройки параметров. Этот параметр действителен, только если для type установлено значение discrete, а для dtype — значение int или float, или для type установлено значение continuous.	Integer/Float	Значение определяется пользователем и должно находиться в допустимом диапазоне этого параметра.
step	Шаг значения параметра, который используется, когда для dtype установлено значение int или float.	Integer/Float	Это значение определяется пользователем.
items	Перечисляемое значение, значение параметра которого не входит в область видимости. Используется, когда для dtype установлено значение int или float.	Integer/Float	Значение определяется пользователем и должно находиться в допустимом диапазоне этого параметра.
options	Перечисляемый диапазон значений параметра value, который используется в случае, если для dtype установлено значение string.	Character string	Значение определяется пользователем и должно находиться в допустимом диапазоне этого параметра.

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

Таблица 3 — Описание структуры файла клиента

Имя	Описание	Тип	Диапазон значений
project	Название проекта, которое должно совпадать с именем в файле конфигурации на сервере.	Character string	—
engine	Алгоритм оптимизации. Подробное описание доступных алгоритмов оптимизации приведено в таблице 5.	Character string	«random», «forest», «gbrt», «bayes», «extraTrees»
iterations	Количество итераций оптимизации.	Integer	≥ 10
random_starts	Количество случайных итераций.	Integer	< итерации
feature_filter_engine	Алгоритм поиска параметров, который используется для выбора важных параметров. Этот параметр необязателен.	Character string	«lhs»
feature_filter_cycle	Циклы поиска параметров, которые используются для выбора важных параметров. Этот параметр используется вместе с feature_filter_engine.	Integer	—
feature_filter_iters	Количество итераций для каждого цикла поиска параметров, которое используется для выбора важных параметров. Этот параметр используется вместе с feature_filter_engine.	Integer	—
split_count	Количество равномерно выбранных параметров в диапазоне значений параметров настройки, который используется для выбора важных параметров. Этот параметр используется вместе с feature_filter_engine.	Integer	—
benchmark	Скрипт тестирования производительности.	—	—
evaluations	Описание целевых функций многокритериальной оптимизации.	—	—

Подробное описание целевой функции многокритериальной оптимизации представлено в таблице 4.

Таблица 4 — Целевая функция многокритериальной оптимизации

Имя	Описание	Тип	Диапазон значений
name	Название индекса оценки.	Character string	—
get	Скрипт для получения результатов оценки производительности.	—	—
type	Указывает положительный или отрицательный тип результата оценки. Значение positive указывает на то, что значение производительности минимально, а значение negative указывает на то, что значение производительности максимально.	Enumeration	positive или negative
weight	Вес индекса.	Integer	0-100
threshold	Минимальные требования к производительности индекса.	Integer	Определяется пользователем.

Таблица 5 — Описание доступных алгоритмов оптимизации

Примеры настройки серверных и клиентских файлов:Примеры настройки серверных и клиентских файлов:Обозначение в A-Tune	Расшифровка	Краткое описание	Библиотека	Справочный материал
bayes	Байесовская линейная регрессия (англ. Bayesian linear regression).	Подход в линейной регрессии, в котором предполагается, что шум распределен нормально.	Нормальное распределение из sklearn	https://ru.wikipedia.org/wiki/Байесовская_линейная_регрессия https://neerc.ifmo.ru/wiki/index.php?title=Вариации_регрессии
gbrt	Градиентный бустинг деревьев (англ. Gradient Boosting Regression Trees).	Градиентный бустинг — это техника машинного обучения для задач классификации и регрессии, которая строит модель предсказания в форме ансамбля слабых предсказывающих моделей, обычно деревьев решений.	sklearn	http://neerc.ifmo.ru/wiki/index.php?title=XGBoost&mobileaction=toggle_view_desktop
forest	Случайные леса (англ. Random Forest Regressor).	Множество решающих деревьев. В задаче регрессии их ответы усредняются.	sklearn	https://scikit-learn.ru/1-11-ensemble-methods/ https://ru.wikipedia.org/wiki/Метод_случайного_леса
extraTrees	Крайне рандомизированные деревья (Extra Trees Regressor).	К множеству решающих деревьев добавляется случайность порогового значения для выбора ответа с каждого дерева.	sklearn	https://scikit-learn.ru/1-11-ensemble-methods/
abtest	А/В-тестирование.	Значения параметров разбиваются на несколько групп, тестируется подстановка каждой группы и выбирается лучший результат.	—
tpe	Древовидный парзеновский оценщик (Tree-structured Parzen Estimator (TPE)).	В TPE задаются два различных распределения параметров: первое — при значениях целевой функции меньших, чем пороговое значение. Второе — при значениях целевой функции больших, чем пороговое значение. Далее параметры из каждого распределения образуют пару, и из каждой пары выбирается оптимальное значение.	hyperopt	https://neerc.ifmo.ru/wiki/index.php?title=Настройка_гиперпараметров
gridsearch	Поиск по сетке.	Метод считает результат для каждого возможного сочетания значений параметров и в конце выбирает сочетание, при котором результат оптимальный.	—	https://neerc.ifmo.ru/wiki/index.php?title=Настройка_гиперпараметров
lhs	Выборка латинского гиперкуба (Latin hypercube sampling).	Метод, который можно использовать для выборки случайных чисел, в котором выборки равномерно распределены по пространству выборки.	lhsmdu	https://www.codecamp.ru/blog/latin-hypercube-sampling/

Примеры настройки серверных и клиентских файлов:

Ниже приведен пример конфигурации файла YAML на сервере:

project: "compress" maxiterations: 500 startworkload: "" stopworkload: "" object :   -     name : "compressLevel"     info :         desc : "The compresslevel parameter is an integer from 1 to 9 controlling the level of compression"         get : "cat /root/A-Tune/examples/tuning/compress/compress.py | grep 'compressLevel=' | awk -F '=' '{print $2}'"         set : "sed -i 's/compressLevel=\\s*[0-9]*/compressLevel=$value/g' /root/A-Tune/examples/tuning/compress/compress.py"         needrestart : "false"         type : "continuous"         scope :           - 1           - 9         dtype : "int"   -     name : "compressMethod"     info :         desc : "The compressMethod parameter is a string controlling the compression method"         get : "cat /root/A-Tune/examples/tuning/compress/compress.py | grep 'compressMethod=' | awk -F '=' '{print $2}' | sed 's/\"//g'"         set : "sed -i 's/compressMethod=\\s*[0-9,a-z,\"]*/compressMethod=\"$value\"/g' /root/A-Tune/examples/tuning/compress/compress.py"         needrestart : "false"         type : "discrete"         options :           - "bz2"           - "zlib"           - "gzip"         dtype : "string"

Ниже приведен пример настройки файла YAML на клиенте:

project: "compress" engine : "gbrt" iterations : 20 random_starts : 10  benchmark : "python3 /root/A-Tune/examples/tuning/compress/compress.py" evaluations :   -     name: "time"     info:         get: "echo '$out' | grep 'time' | awk '{print $3}'"         type: "positive"         weight: 20   -     name: "compress_ratio"     info:         get: "echo '$out' | grep 'compress_ratio' | awk '{print $3}'"         type: "negative"         weight: 80

Другие примеры клиентских и серверных файлов находятся в директории /usr/share/doc/atune.

После того как подготовили файлы для поиска оптимальных параметров, нужно скопировать серверный файл в директорию /etc/atuned/tuning. Файл клиента рекомендуется хранить в той папке, откуда запускается команда на поиск оптимальных параметров.

Для запуска оптимизации необходимо воспользоваться командой tuning.

Общий вид команды поиска оптимальных параметров

atune-adm tuning --project [имя проекта, указанное в конфигурационных файлах] <опциональный параметр> имя_файла_клиента

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

Таблица 6 — Описание опциональных параметров для команды tuning

Пример использования динамического режима

Данный функционал был протестирован на различных рабочих нагрузках. Приведем пример, в котором производилась оптимизация параметров для работы сервера приложений Tomcat. За показания целевой функции взяли утилиту ab для оценки производительности (https://httpd.apache.org/docs/current/programs/ab.html).

Команда для бенчмарка

ab -n 8000 http://localhost:8080/

Для данной оптимизационной задачи файл сервера уже сгенерирован и находится в каталоге /etc/atuned/tuning. Файл клиента нужно составить самостоятельно:

Файл клиента «tomcat.yaml»

project: "tomcat" engine : "gbrt" iterations : 30 random_starts : 10  benchmark : "sh tomcat_benchmark.sh" evaluations :   -     name: "rps"     info:         get: "echo '$out' | grep 'taken' | awk '{print $5}'"         type: "negative"         weight: 100

Чтобы запустить поиск оптимальных параметров для tomcat, нужно вызвать команду atune-adm:

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

atune-adm tuning --project tomcat --detail tomcat.yaml

Вывод команды tuning

Start to benchmark baseline...  1.Loading its corresponding tuning project: tomcat  2.Start to tuning the system......  Current Tuning Progress......(1/30)  Used time: 7s, Total Time: 7s, Best Performance: (rps=4.50), Performance Improvement Rate: -0.00%  The 1th recommand parameters is: vm.drop_caches=3,net.ipv4.tcp_tw_reuse=2,net.ipv4.tcp_fin_timeout=16,net.ipv4.tcp_max_tw_buckets=1015808,net.ipv4.ip_local_port_range=32768 60999,net.core.somaxconn=22144,net.ipv4.tcp_max_syn_backlog=251904,net.core.rmem_max=42991616,net.core.wmem_max=52428800,ulimit.nofile=8824,connector.maxThreads=1710,connector.minSpareThreads=55,connector.maxConnections=11700,connector.enableLookups=true,connector.acceptCount=1350,connector.connectionTimeout=23500,connector.maxHttpHeaderSize=71680,connector.tcpNoDelay=true,connector.compression=force,connector.compressionMinSize=23040,connector.disableUploadTimeout=false  The 1th evaluation value: (rps=1.82)(-59.56%)  Current Tuning Progress......(2/30)  Used time: 9s, Total Time: 9s, Best Performance: (rps=4.50), Performance Improvement Rate: -0.00%  The 2th recommand parameters is: vm.drop_caches=3,net.ipv4.tcp_tw_reuse=0,net.ipv4.tcp_fin_timeout=63,net.ipv4.tcp_max_tw_buckets=491520,net.ipv4.ip_local_port_range=8192 65535,net.core.somaxconn=41856,net.ipv4.tcp_max_syn_backlog=53248,net.core.rmem_max=3145728,net.core.wmem_max=42991616,ulimit.nofile=6490,connector.maxThreads=1370,connector.minSpareThreads=45,connector.maxConnections=8600,connector.enableLookups=true,connector.acceptCount=1300,connector.connectionTimeout=48000,connector.maxHttpHeaderSize=37888,connector.tcpNoDelay=true,connector.compression=on,connector.compressionMinSize=18432,connector.disableUploadTimeout=true  The 2th evaluation value: (rps=1.29)(-71.33%)  ... ... итерация, на которой появилось улучшение ...   Current Tuning Progress......(14/30)  Used time: 54s, Total Time: 54s, Best Performance: (rps=4.50), Performance Improvement Rate: -0.00%  The 14th recommand parameters is: vm.drop_caches=3,net.ipv4.tcp_tw_reuse=1,net.ipv4.tcp_fin_timeout=22,net.ipv4.tcp_max_tw_buckets=917504,net.ipv4.ip_local_port_range=1024 65535,net.core.somaxconn=64128,net.ipv4.tcp_max_syn_backlog=37888,net.core.rmem_max=3145728,net.core.wmem_max=13631488,ulimit.nofile=10236,connector.maxThreads=1470,connector.minSpareThreads=140,connector.maxConnections=11500,connector.enableLookups=true,connector.acceptCount=1350,connector.connectionTimeout=56500,connector.maxHttpHeaderSize=60416,connector.tcpNoDelay=false,connector.compression=force,connector.compressionMinSize=24576,connector.disableUploadTimeout=true  The 14th evaluation value: (rps=2.16)(-52.00%)  Current Tuning Progress......(15/30)  Used time: 1m7s, Total Time: 1m7s, Best Performance: (rps=4.87), Performance Improvement Rate: 8.22%  The 15th recommand parameters is: vm.drop_caches=3,net.ipv4.tcp_tw_reuse=0,net.ipv4.tcp_fin_timeout=1,net.ipv4.tcp_max_tw_buckets=655360,net.ipv4.ip_local_port_range=8192 65535,net.core.somaxconn=57600,net.ipv4.tcp_max_syn_backlog=3072,net.core.rmem_max=27262976,net.core.wmem_max=18874368,ulimit.nofile=7119,connector.maxThreads=1710,connector.minSpareThreads=105,connector.maxConnections=11000,connector.enableLookups=false,connector.acceptCount=1350,connector.connectionTimeout=10000,connector.maxHttpHeaderSize=21504,connector.tcpNoDelay=true,connector.compression=on,connector.compressionMinSize=1536,connector.disableUploadTimeout=true  The 15th evaluation value: (rps=4.87)(8.22%)  ... ... итоговый вывод ... Current Tuning Progress......(30/30)  Used time: 3m24s, Total Time: 3m24s, Best Performance: (rps=4.87), Performance Improvement Rate: 8.22%  The 30th recommand parameters is: vm.drop_caches=1,net.ipv4.tcp_tw_reuse=2,net.ipv4.tcp_fin_timeout=92,net.ipv4.tcp_max_tw_buckets=622592,net.ipv4.ip_local_port_range=8192 65535,net.core.somaxconn=42624,net.ipv4.tcp_max_syn_backlog=87040,net.core.rmem_max=22020096,net.core.wmem_max=56623104,ulimit.nofile=3188,connector.maxThreads=1780,connector.minSpareThreads=45,connector.maxConnections=10100,connector.enableLookups=false,connector.acceptCount=650,connector.connectionTimeout=53000,connector.maxHttpHeaderSize=21504,connector.tcpNoDelay=false,connector.compression=force,connector.compressionMinSize=1536,connector.disableUploadTimeout=false  The 30th evaluation value: (rps=2.43)(-46.00%)   The final optimization result is: vm.drop_caches=3,net.ipv4.tcp_tw_reuse=0,net.ipv4.tcp_fin_timeout=1,net.ipv4.tcp_max_tw_buckets=655360,net.ipv4.ip_local_port_range=8192 65535,net.core.somaxconn=57600,net.ipv4.tcp_max_syn_backlog=3072,net.core.rmem_max=27262976,net.core.wmem_max=18874368,ulimit.nofile=7119,connector.maxThreads=1710,connector.minSpareThreads=105,connector.maxConnections=11000,connector.enableLookups=false,connector.acceptCount=1350,connector.connectionTimeout=10000,connector.maxHttpHeaderSize=21504,connector.tcpNoDelay=true,connector.compression=on,connector.compressionMinSize=1536,connector.disableUploadTimeout=true  The final evaluation value is: rps=4.87   Baseline Performance is: (rps=4.50)   Tuning Finished

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

В A-Tune мы с командой доработали возможность сохранения значений оптимальных параметров в профиль для статического режима оптимизации, что позволило повысить удобство работы с утилитой.

Команда для сохранения профиля

atune-adm tuning --project tomcat --save tomcat_profile.conf

После этого можно сохранить профиль в список профилей A-Tune, и он станет доступен для применения.

Сохранить профиль в A-Tune

# в данном примере [тип сервиса] - servlet [название приложения] - tomcat [название пользовательского сценария] - optimized atune-adm define servlet tomcat optimized tomcat_profile.conf

Если понадобится удалить профиль из A-Tune, то используем следующую команду.

Удалить профиль из A-Tune

atune-adm undefine servlet-tomcat-optimized

A-Tune изменяет параметры в системе во время оптимизации, поэтому в утилите предусмотрен механизм для возврата параметров в исходное состояние.

Возврат параметров в исходное состояние

atune-adm tuning --restore --project tomcat

Распределенный режим работы A-Tune

Еще одна возможность A-Tune — это распределенный режим работы, который представляет собой разнесение клиентских и серверных частей. Для взаимодействия между собой они используют TLS-протокол.
Из-за особенностей реализации меняются и команды для запуска: в обычном режиме команды A-Tune (например, analysis) будут запущены командой atune-adm analysis, а в распределенном — atune-adm -a <ipv4 адрес сервера> -p <порт> analysis. Настройка конфигурации происходит именно на сервере, в этом режиме A-Tune никак не влияет на клиентскую машину.

Пример команды для распределенного режима работы

atune-adm -a 10.0.2.6 -p 60001 analysis -t 5

Сравнение A-Tune и TuneD

Прародителем для утилиты A-Tune является популярный у администраторов инструмент TuneD от компании Red Hat, который также позволяет решать задачу тонкого тюнинга системы.

В TuneD используется конфигурационный файл, в котором вручную задаются условия для рекомендации того или иного профиля. Условия учитываются по следующему алгоритму:

1. Если указана опция virt, то вызывается virt-what.

2. Если указана опция system, то поиск по регулярному выражению в файле /etc/os-release.

3. Если строка начинается с «/», то производится поиск файла по заданному пути, проверяется его существование и поиск по регулярному выражению в этом файле.

4. Если указана опция process, то происходит поиск через procfs.pidstats()

5. Если указана опция chassis_type, то выводится строка через /sys/devices/virtual/dmi/id/chassis_type, или если не получается, то через dmidecode -s chassis-type. Потом в выведенной строке происходит поиск по регулярному выражению.

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

В A-Tune и TuneD применение профилей отличается самим составом, набором и синтаксисом плагинов.

Таблица 6 — Сравнение A-Tune и TuneD

Заключение

После проделанной работы по изучению и доработке утилиты в ОС Astra Linux Special Edition 1.8 появился функционал для тюнинга и повышения производительности ОС. Использование в проекте алгоритмов машинного обучения и алгоритмов глобальной и локальной многокритериальной оптимизации призвано повысить эффективность подбора оптимальных параметров. Оно сделает тюнинг более гибким и позволит адаптироваться к изменяющимся нагрузкам. Также функционал, связанный с машинным обучением, расширяет сферу применения A-Tune по сравнению с TuneD, позволяет проводить собственные исследования в сфере тонкой настройки систем и работать с узкопрофильными нагрузками.

Эксперименты с функционалом A-Tune показали, что это приложение имеет большой потенциал в области оптимизации производительности систем.