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

Меня зовут Артём, я инженер-программист в департаменте серверных решений. В статье расскажу про новый инструмент для повышения производительности, который получилось портировать и доработать для ОС 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.

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

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

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

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

Ниже приведен пример конфигурации файла 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 показали, что это приложение имеет большой потенциал в области оптимизации производительности систем.