Инструментарий централизованной настройки серверов для новых времен

С зарождения человечества перед людьми в том или ином виде стояла проблема хранения и обработки информации – начиная от Тэртерийских глиняных табличек, датируемых V тыс. до н.э, великой библиотеки в Александрии и заканчивая сегодняшними возможностями ИТ-решений и технологий, от простых бытовых записей (например, учета съестных ресурсов) в древности до сложной бизнес-аналитики и систем принятия решений на производственных предприятиях сегодня. Каждая эпоха привносила свои знания и стимулировала все больший рост объемов информации.   

Очередной “эпохой” осуществившей очередной количественный скачок по объему хранимой информации и формированию новых требований к оперативности ее обработки можно считать начавшуюся, казалось бы, не так давно эру сети Интернет и последовавшие за последние десятилетия скачки темпов роста хранимых данных (во многом благодаря увеличению объемов веб-контента).

Рисунок 1 - Рост производимых, хранимых и обрабатываемых данных в цифровом мире

Рисунок 1 - Рост производимых, хранимых и обрабатываемых данных в цифровом мире

Разнотипность приложений, сервисов и типов обрабатываемых ими данных приводит к необходимости использования диверсифицированных вычислений. Иначе количество разнотипных специализированных операционных систем и программного обеспечения будет таковым, что процесс управления и администрирования типового ИТ ландшафта будет крайне переусложнен и приведет к росту числа ИТ персонала ответственного за эксплуатацию серверных систем компании, необходимости знания дополнительных и/или специализированных решений а также сильно повысит риск человеческой ошибки при настройке систем.

Рисунок 2 - Единая ОС для всех сценариев использования - основа диверсифицированных вычислений.

Рисунок 2 - Единая ОС для всех сценариев использования - основа диверсифицированных вычислений.

Но если вопрос унификации операционной системы в рамках диверсифицированных вычислений и можно решить, то проблема необходимости настройки большого количества типовых серверов, ориентированных на различные типы загрузки в зависимости от предоставляемых ими сервисов и решаемых в ИТ инфраструктуре заказчика задач к сожалению остается. Зачастую именно настройка типовых систем оказывается основным узким местом влияющим на производительность всей экосистемы в целом. Действительно ли все сервера ответственные за исполнение определенных задач, к примеру, сервера СУБД и типы их загрузки настолько идентичны что для них подойдет единый профиль настройки?  Есть ли возможность поручить штатному администратору СУБД анализ каждого типового сервера коих могут быть десятки или даже сотни?

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

Подробнее о нас, сообществе разработчиков OpenScaler, а также о нашем предке – openEuler вы можете прочесть на нашем сайте, ну а мы вернемся к инструменту A-Tune.

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

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

Рисунок 3 - Ключевые сферы применения системы A-Tune

Рисунок 3 - Ключевые сферы применения системы A-Tune

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

  • Уровень интеллектуального принятия решений состоит из подсистемы осведомленности, которая выполняет функции интеллектуального анализа и оповещения о состоянии приложений, и подсистемы принятия решений, которая отвечает за фактическую оптимизацию и внесение изменений в конфигурацию системы.
  • Уровень системного профиля состоит из модуля компоновки функций и двухуровневой модели классификации. Модуль компоновки функций служит для автоматического выбора сервисных функций, а двухуровневая модель классификации используется для обучения и классификации сервисных моделей.
  • Уровень системы взаимодействия отслеживает и конфигурирует различные системные ресурсы и выполняет политики оптимизации.
Рисунок 4 - Архитектура инструмента A-Tune

Рисунок 4 - Архитектура инструмента A-Tune

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

Таблица 1 – Перечень функций и уровень их готовности к использованию в продуктивных системах.

 

Функция

Уровень готовности

Рекомендации к применению

Автоматическая оптимизация 11 наименований программных решений представляющих 7 различных типов нагрузки 

Протестировано

Рекомендовано к применению

Создание пользовательских профилей нагрузки и сервисных моделей

Протестировано

Рекомендовано к применению

Автоматическая оптимизация параметров

Протестировано

Рекомендовано к применению

 

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

 

Таблица 2 – Поддерживаемые типы рабочих нагрузок и приложений для оптимизации

Категория сервиса

Тип

Проблематика

Поддерживаемые приложения

Default

Типо по умолчанию

Низкая загрузка ресурсов процессора, пропускной способности памяти, сети и устройств ввода-вывода.

—-

WebServer

Приложение HTTPS

Высокая загрузка ресурсов процессора.

Nginx

Big_Database

База Данных

– Реляционная база данных

Чтение: высокая загрузка ресурсов процессора, пропускной способности памяти и сети.

Запись: высокая загрузка ресурсов устройств ввода-вывода.

 

– Нереляционная база данных

Высокая загрузка ресурсов процессора и устройств ввода-вывода.

MongoDB, MySQL, PostgreSQL, MariaDB

Big_Data

Большие Данные

Высокая загрузка ресурсов процессора и устройств ввода-вывода.

Hadoop, Spark

In-Memory_Computing

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

Высокая загрузка ресурсов процессора и пропускной способности памяти.

SPECjbb2015

In-Memory_DataBase

Приложение с интенсивным потреблением вычислительных и сетевых ресурсов

Высокая загрузка одноядерного процессора и сетевых ресурсов в многоэкземплярных сценариях.

Redis

Single_Computer_Intensive_Jobs

Приложение с интенсивным потреблением вычислительных ресурсов

Высокая загрузка ресурсов одноядерного процессора и пропускной способности памяти некоторых подэлементов.

SPECCPU2006

Communication

Приложение с интенсивным потреблением сетевых ресурсов

Высокая загрузка ресурсов процессора и сети.

Dubbo

Idle

Система в состоянии ожидания

Система находится в состоянии ожидания, и на ней не запущены никакие приложения.

—-

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

1. Применение готового “профиля” системы или “статический” режим работы – Тот случай когда системный администратор или IT подразделение ответственное за эксплуатацию системы и сервисов полностью уверены в корректности настроек, “эталонные” параметры могут быть растиражированы и применены на всех типовых системах подходящих под данный профиль.

Для этого системный администратор может воспользовавшись одним из 11 заранее предустановленных “профилей” представленных в таблице 2 написать свой собственный, используя максимально простую и понятную структуру файла описания представленного ниже.

профиль web/nginx/https-long-connection.conf (Настройка Nginx)

[main]

include = default-default

[kernel_config]

[bios]

Support SMMU = Disabled

[bootloader.grub2]

[sysfs]

[systemctl]

irqbalance = stop

[sysctl]

net.ipv4.tcp_tw_reuse = 1

net.ipv4.ip_local_port_range = 1024     65500

net.ipv4.tcp_max_tw_buckets = 5000

net.core.somaxconn = 65535

net.core.netdev_max_backlog = 262144

net.ipv4.tcp_max_syn_backlog = 262144

net.ipv4.tcp_fin_timeout = 1

net.ipv4.tcp_keepalive_time = 60

net.core.rmem_max = 16777216

net.core.wmem_max = 16777216

[script]

openssl_hpre = 0

prefetch = off

ethtool =  -X {network} hfunc toeplitz

[ulimit]

{user}.hard.nofile = 102400

{user}.soft.nofile = 102400

[schedule_policy]

[check]

[tip]

SELinux provides extra control and security features to linux kernel. Disabling SELinux will improve the performance but may cause security risks. = kernel

Посмотреть готовые профили настройки под конкретные приложения можно при помощи команды:

# 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     |

+———————————————+———–+

| basic-test-suite-baseline-stream            | false     |

+———————————————+———–+

| basic-test-suite-baseline-unixbench         | false     |

+———————————————+———–+

| basic-test-suite-speccpu-speccpu2006        | false     |

+———————————————+———–+

| basic-test-suite-specjbb-specjbb2015        | false     |

+———————————————+———–+

| big-data-hadoop-hdfs-dfsio-hdd              | false     |

+———————————————+———–+

| big-data-hadoop-hdfs-dfsio-ssd              | false     |

+———————————————+———–+

| big-data-hadoop-spark-bayesian              | false     |

+———————————————+———–+

| big-data-hadoop-spark-kmeans                | false     |

+———————————————+———–+

| big-data-hadoop-spark-sql1                  | false     |

+———————————————+———–+

| big-data-hadoop-spark-sql10                 | false     |

+———————————————+———–+

| big-data-hadoop-spark-sql2                  | false     |

+———————————————+———–+

| big-data-hadoop-spark-sql3                  | false     |

+———————————————+———–+

| big-data-hadoop-spark-sql4                  | false     |

+———————————————+———–+

| big-data-hadoop-spark-sql5                  | false     |

+———————————————+———–+

| big-data-hadoop-spark-sql6                  | false     |

+———————————————+———–+

| big-data-hadoop-spark-sql7                  | false     |

+———————————————+———–+

| big-data-hadoop-spark-sql8                  | false     |

+———————————————+———–+

| big-data-hadoop-spark-sql9                  | false     |

+———————————————+———–+

| big-data-hadoop-spark-tersort               | false     |

+———————————————+———–+

| big-data-hadoop-spark-wordcount             | false     |

+———————————————+———–+

| cloud-compute-kvm-host                      | false     |

+———————————————+———–+

| database-mariadb-2p-tpcc-c3                 | false     |

+———————————————+———–+

| database-mariadb-4p-tpcc-c3                 | false     |

+———————————————+———–+

| database-mongodb-2p-sysbench                | false     |

+———————————————+———–+

| database-mysql-2p-sysbench-hdd              | false     |

+———————————————+———–+

| database-mysql-2p-sysbench-ssd              | false     |

+———————————————+———–+

| database-postgresql-2p-sysbench-hdd         | false     |

+———————————————+———–+

| database-postgresql-2p-sysbench-ssd         | false     |

+———————————————+———–+

| default-default                             | true      |

+———————————————+———–+

| docker-mariadb-2p-tpcc-c3                   | false     |

+———————————————+———–+

| docker-mariadb-4p-tpcc-c3                   | false     |

+———————————————+———–+

| encryption-AES-chauffeur                    | false     |

+———————————————+———–+

| encryption-MD5-chauffeur                    | false     |

+———————————————+———–+

| encryption-RSAPublic-chauffeur              | false     |

+———————————————+———–+

| hpc-gatk4-human-genome                      | false     |

+———————————————+———–+

| in-memory-database-redis-redis-benchmark    | false     |

+———————————————+———–+

| middleware-dubbo-dubbo-benchmark            | false     |

+———————————————+———–+

| storage-ceph-vdbench-hdd                    | false     |

+———————————————+———–+

| storage-ceph-vdbench-ssd                    | false     |

+———————————————+———–+

| virtualization-consumer-cloud-olc           | false     |

+———————————————+———–+

| virtualization-mariadb-2p-tpcc-c3           | false     |

+———————————————+———–+

| virtualization-mariadb-4p-tpcc-c3           | false     |

+———————————————+———–+

| web-apache-traffic-server-spirent-pingpo    | false     |

+———————————————+———–+

| web-nginx-http-long-connection              | false     |

+———————————————+———–+

| web-nginx-http-short-connection             | false     |

+———————————————+———–+

| web-nginx-https-long-connection             | false     |

+———————————————+———–+

| web-nginx-https-short-connection            | false     |

+———————————————+———–+

| web-tomcat-http-connection                  | false     |

+———————————————+———–+

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

Применение профиля

К примеру, у нас работает сервер приложений tomcat и мы хотим использовать профиль для настройки параметров ОС применительно к этому приложению. Для этого мы даём команду:

# atune-adm profile web-tomcat-http-connection 

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

# atune-adm list | grep web-tomcat-http-connection

| web-tomcat-http-connection                  | true     |

мы убедимся, что этот профиль является активным на данном сервере.

Тиражирование готового профиля может быть осуществлено либо посредством командной строки и команды вида:

# atune-adm profile web-nginx-https-long-connection

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

Рисунок 6 - внешний вид веб-интерфейса A-Tune

Рисунок 6 - внешний вид веб-интерфейса A-Tune

2. Изучение готового “профиля” и автоматизированная корректировка неоптимальных параметров настройки или “динамический” режим работы – А этот случай вполне можно обозвать “доверяй но проверяй”, системным администратором подготовлены как ему кажется оптимальные параметры работы системы и конкретного сервиса на его борту (будь то СУБД, стек решений Hadoop или веб-сервер) но действительно ли они оптимальны? Можно попросить A-Tune это проверить путём перебора значимых параметров в конфигурационном файле этого приложения

A-Tune обеспечивает возможность автоматического поиска оптимальной конфигурации приложения и ОС, избавляя от необходимости ручной настройки его параметров и оценки их производительности. Это значительно повышает эффективность поиска оптимальных конфигураций приложения. Для того, чтобы воспользоваться этой возможностью, надо подготовить так называемый проектный файл (в формате yaml) для требуемого приложения, производительность которого планируется оптимизировать (этот файл впоследствии размещается в каталоге  /etc/atuned/tuning/), а также файл конфигурации клиента (также в yaml формате). Файл конфигурации клиента будет применяться для создания повторяемой нагрузки на приложение и количественной оценки работы приложения на каждом прогоне при изменении параметров конфигурации.

В качестве примера, рассмотрим автоматический подбор параметров для такого распространенного сервера СУБД как MySQL 

Примечание:

1. Все конфигурационные файлы используемые в рамках данного примера можно получить по адресу https://gitee.com/openeuler/A-Tune/tree/master/examples/tuning/mysql_sysbench 2. В качестве тестового сервера используется система с 4 ядрами CPU, 4 Гб оперативной памяти и установленной операционной системой openScaler 22.03 SP1. 3. Количество ядер для работы данного примера должно быть не меньше 4, так как при настройке параметров используется команда taskset, которая прикрепляет исполнение процессов к конкретным ядрам CPU и здесь используются все 4 ядра.

Для подготовки тестовой системы и конфигурационных файлов можно воспользоваться готовым скриптом (который поставляется в gitee репозитории, ссылка на который дана в примечании выше) prepare.sh

Если рассмотреть этот скрипт, то можно заметить, что в нём происходит установка пакетов mysql сервера (при этом конфигурационный файл для mysql берётся тоже из этого репозитория), запуск mysqld сервера (на двух первых ядрах CPU), установка утилиты sysbench и подготовка проектных файлов для a-tune (как для сервера, так и для клиента), которые будут использоваться при поиске оптимальных параметров запуска mysqld.

Рассмотрим данные конфигурационные файлы:

Файл конфигурации сервера

# cat /etc/atuned/tuning/mysql_sysbench_server.yaml 

project: “mysql_sysbench”

maxiterations: 2048

startworkload: “`mysqld & ` & sleep 10” 

stopworkload: “mysqladmin -S/var/lib/mysql/mysql.sock shutdown -uroot -p123456” 

object : 

  –

    name : “kernel.numa_balancing”

    info :

        desc : “Specifies whether to enable NUMA automatic balancing.”

        get : “sysctl -n kernel.numa_balancing”

        set : “sysctl -w kernel.numa_balancing=$value”

        needrestart : “false”

        type : “discrete”

        options :

          – “0”

          – “1”

        dtype : “string”

  –

    name : “kernel.sched_autogroup_enabled”

    info :

        desc : “When enabled, the kernel creates task groups to optimize desktop program scheduling.

0: disabled

1: enabled”

        get : “sysctl -n kernel.sched_autogroup_enabled”

        set : “sysctl -w kernel.sched_autogroup_enabled=$value”

        needrestart : “false”

        type : “discrete”

        options :

          – “0”

          – “1”

        dtype : “string”

  –

    name : “kernel.sched_wakeup_granularity_ns”

    info :

        desc : “This variable indicates the base of the minimum time that a process should run after it is woken up. The smaller the base, the higher the probability of preemption.”

        get : “sysctl -n kernel.sched_wakeup_granularity_ns”

        set : “sysctl -w kernel.sched_wakeup_granularity_ns=$value”

        needrestart : “false”

        type : “discrete”

        scope :

          – 1000000

          – 100000000

        step : 1000000

        items : 

        dtype : “int”

  –

    name : “kernel.sched_min_granularity_ns”

    info :

        desc : “Minimum running time of a process on the CPU. During this time, the kernel does not proactively select other processes for scheduling (in nanoseconds).”

        get : “sysctl -n kernel.sched_min_granularity_ns”

        set : “sysctl -w kernel.sched_min_granularity_ns=$value”

        needrestart : “false”

        type : “discrete”

        scope :

          – 1000000

          – 100000000

        step : 1000000

        items : 

        dtype : “int”

  –

    name : “innodb_io_capacity”

    info :

        desc : “MySQL [mysqld] parameters ‘innodb_io_capacity’.”

        get : “cat /etc/my.cnf | grep ‘innodb_io_capacity’ | awk -F ‘=’ ‘{print $2}'”

        set : “sed -i ‘s/^innodb_io_capacity.*$/innodb_io_capacity=$value/g’ /etc/my.cnf”

        needrestart : “true”

        type : “continuous”

        scope :

          – 100

          – 10000

        dtype : “int”

  –

    name : “innodb_write_io_threads”

    info :

        desc : “MySQL [mysqld] parameters ‘innodb_write_io_threads’.”

        get : “cat /etc/my.cnf | grep ‘innodb_write_io_threads’ | awk -F ‘=’ ‘{print $2}'”

        set : “sed -i ‘s/^innodb_write_io_threads.*$/innodb_write_io_threads=$value/g’ /etc/my.cnf”

        needrestart : “true”

        type : “continuous”

        scope :

          – 2

          – 200

        dtype : “int”

  –

    name : “innodb_read_io_threads”

    info :

        desc : “MySQL [mysqld] parameters ‘innodb_read_io_threads’.”

        get : “cat /etc/my.cnf | grep ‘innodb_read_io_threads’ | awk -F ‘=’ ‘{print $2}'”

        set : “sed -i ‘s/^innodb_read_io_threads.*$/innodb_read_io_threads=$value/g’ /etc/my.cnf”

        needrestart : “true”

        type : “continuous”

        scope :

          – 2

          – 30

        dtype : “int”

  –

    name : “innodb_spin_wait_delay”

    info :

        desc : “MySQL [mysqld] parameters ‘innodb_spin_wait_delay’.”

        get : “cat /etc/my.cnf | grep ‘innodb_spin_wait_delay’ | awk -F ‘=’ ‘{print $2}'”

        set : “sed -i ‘s/^innodb_spin_wait_delay.*$/innodb_spin_wait_delay=$value/g’ /etc/my.cnf”

        needrestart : “true”

        type : “continuous”

        scope :

          – 2

          – 30

        dtype : “int”

  –

    name : “innodb_sync_spin_loops”

    info :

        desc : “MySQL [mysqld] parameters ‘innodb_sync_spin_loops’.”

        get : “cat /etc/my.cnf | grep ‘innodb_sync_spin_loops’ | awk -F ‘=’ ‘{print $2}'”

        set : “sed -i ‘s/^innodb_sync_spin_loops.*$/innodb_sync_spin_loops=$value/g’ /etc/my.cnf”

        needrestart : “true”

        type : “continuous”

        scope :

          – 10

          – 500

        dtype : “int”

  –

    name : “innodb_log_file_size”

    info :

        desc : “MySQL [mysqld] parameters ‘innodb_log_file_size’.”

        get : “cat /etc/my.cnf | grep ‘innodb_log_file_size’ | awk -F ‘=’ ‘{print $2}’ | awk -F ‘M’ ‘{print $1}'”

        set : “sed -i ‘s/^innodb_log_file_size.*$/innodb_log_file_size=$valueM/g’ /etc/my.cnf”

        needrestart : “true”

        type : “continuous”

        scope :

          – 10

          – 1024

        dtype : “int”

  –

    name : “innodb_log_files_in_group”

    info :

        desc : “MySQL [mysqld] parameters ‘innodb_log_files_in_group’.”

        get : “cat /etc/my.cnf | grep ‘innodb_log_files_in_group’ | awk -F ‘=’ ‘{print $2}'”

        set : “sed -i ‘s/^innodb_log_files_in_group.*$/innodb_log_files_in_group=$value/g’ /etc/my.cnf”

        needrestart : “true”

        type : “continuous”

        scope :

          – 1

          – 20

        dtype : “int”

  –

    name : “innodb_buffer_pool_instances”

    info :

        desc : “MySQL [mysqld] parameters ‘innodb_buffer_pool_instances’.”

        get : “cat /etc/my.cnf | grep ‘innodb_buffer_pool_instances’ | awk -F ‘=’ ‘{print $2}'”

        set : “sed -i ‘s/^innodb_buffer_pool_instances.*$/innodb_buffer_pool_instances=$value/g’ /etc/my.cnf”

        needrestart : “true”

        type : “continuous”

        scope :

          – 1

          – 20

        dtype : “int”

  –

    name : “innodb_log_buffer_size”

    info :

        desc : “MySQL [mysqld] parameters ‘innodb_log_buffer_size’.”

        get : “cat /etc/my.cnf | grep ‘innodb_log_buffer_size’ | awk -F ‘=’ ‘{print $2}’ | awk -F ‘M’ ‘{print $1}'”

        set : “sed -i ‘s/^innodb_log_buffer_size.*$/innodb_log_buffer_size=$valueM/g’ /etc/my.cnf”

        needrestart : “true”

        type : “continuous”

        scope :

          – 8

          – 1024

        dtype : “int”

  –

    name : “innodb_page_cleaners”

    info :

        desc : “MySQL [mysqld] parameters ‘innodb_page_cleaners’.”

        get : “cat /etc/my.cnf | grep ‘innodb_page_cleaners’ | awk -F ‘=’ ‘{print $2}'”

        set : “sed -i ‘s/^innodb_page_cleaners.*$/innodb_page_cleaners=$value/g’ /etc/my.cnf”

        needrestart : “true”

        type : “continuous”

        scope :

          – 1

          – 20

        dtype : “int”

  –

    name : “innodb_lru_scan_depth”

    info :

        desc : “MySQL [mysqld] parameters ‘innodb_lru_scan_depth’.”

        get : “cat /etc/my.cnf | grep ‘innodb_lru_scan_depth’ | awk -F ‘=’ ‘{print $2}'”

        set : “sed -i ‘s/^innodb_lru_scan_depth.*$/innodb_lru_scan_depth=$value/g’ /etc/my.cnf”

        needrestart : “true”

        type : “continuous”

        scope :

          – 20

          – 2000

        dtype : “int”

  –

    name : “innodb_thread_concurrency”

    info :

        desc : “MySQL [mysqld] parameters ‘innodb_thread_concurrency’.”

        get : “cat /etc/my.cnf | grep ‘innodb_thread_concurrency’ | awk -F ‘=’ ‘{print $2}'”

        set : “sed -i ‘s/^innodb_thread_concurrency.*$/innodb_thread_concurrency=$value/g’ /etc/my.cnf”

        needrestart : “true”

        type : “continuous”

        scope :

          – 0

          – 300

        dtype : “int”

  –

    name : “innodb_flush_log_at_trx_commit”

    info :

        desc : “MySQL [mysqld] parameters ‘innodb_flush_log_at_trx_commit’.”

        get : “cat /etc/my.cnf | grep ‘innodb_flush_log_at_trx_commit’ | awk -F ‘=’ ‘{print $2}'”

        set : “sed -i ‘s/^innodb_flush_log_at_trx_commit.*$/innodb_flush_log_at_trx_commit=$value/g’ /etc/my.cnf”

        needrestart : “true”

        type : “continuous”

        scope :

          – 0

          – 2

        dtype : “int”

  –

    name : “sync_binlog”

    info :

        desc : “MySQL [mysqld] parameters ‘sync_binlog’.”

        get : “cat /etc/my.cnf | grep ‘sync_binlog’ | awk -F ‘=’ ‘{print $2}'”

        set : “sed -i ‘s/^sync_binlog.*$/sync_binlog=$value/g’ /etc/my.cnf”

        needrestart : “true”

        type : “continuous”

        scope :

          – 0

          – 2

        dtype : “int”

В конфигурационном файле /etc/atuned/tuning/mysql_sysbench_server.yaml  представлены команды запуска и остановки mysqld сервера, а также выбранные для тюнинга параметры конфигурации, у которых указаны верхние и нижние пределы значений (диапазон значений), которые A-Tune будет использовать для выбора при переборе параметров для запуска mysqld.

Файл конфигурации клиента:

# cat mysql_sysbench_client.yaml

project: “mysql_sysbench”

engine : “gbrt”

iterations : 30

random_starts : 10

 

benchmark : “sh /root/A-Tune/examples/tuning/mysql_sysbench/mysql_sysbench_benchmark.sh”

evaluations :

  –

    name: “QPS”

    info:

        get: “cat /root/A-Tune/examples/tuning/mysql_sysbench/sysbench_oltp_read_write.log  | grep ‘queries:’ | awk -F ‘(‘ ‘{print $2}’ | awk -F ‘ ‘ ‘{print $1}'”

        type: “negative”

        weight: 100

Из представленного выше конфигурационного файла клиента видно, что оценка производительности идёт по параметру QPS, значение которого берётся из журнала работы sysbench.

Для запуска процесса оптимизации параметров настройки используем команду:

# atune-adm tuning –project mysql_sysbench –detail mysql_sysbench_client.yaml

Эта команда будет работать продолжительное время и поэтому её лучше всего запустить в screen (или tmux, смотря кто что предпочитает).

По окончанию работы atune-adm напечатает в своем журнале работы те параметры настройки mysqld, при которых удалось достичь максимума QPS.

Пример вывода по результатам работы процесса оптимизации параметров:

 The final optimization result is: kernel.numa_balancing=0,kernel.sched_autogroup_enabled=1,kernel.sched_wakeup_granularity_ns=75000000,kernel.sched_min_granularity_ns=36000000,innodb_io_capacity=3184,innodb_write_io_threads=136,innodb_read_io_threads=11,innodb_spin_wait_delay=7,innodb_sync_spin_loops=174,innodb_log_file_size=781,innodb_log_files_in_group=6,innodb_buffer_pool_instances=5,innodb_log_buffer_size=500,innodb_page_cleaners=8,innodb_lru_scan_depth=706,innodb_thread_concurrency=249,innodb_flush_log_at_trx_commit=2,sync_binlog=0

 The final evaluation value is: QPS=15031.05

 Baseline Performance is: (QPS=12257.15)

 Tuning Finished

3. Применение AI модели для поиска оптимальных параметров настройки приложения  – Как мы говорили в начале статьи, в лабораторных условиях невозможно просчитать всех сценариев использования серверной системы и учесть все нюансы ее эксплуатации таким образом чтобы заранее подготовить и снабдить A-Tune профилями “на все возможные случаи жизни”. Как быть, если мы используем некое собственноручно написанное приложение или даже просто стороннее программное решение для которого нет написанного профиля? На помощь придет AI модуль A-Tune который позволит создать свой собственный уникальный профиль для использования в каждой конкретной ситуации и используемого приложения.

Допустим, наше приложение (под работу которого надо оптимизировать параметры ОС) называется testapp1 и оно установлено на сервер, где уже есть установленный A-Tune.

Для получения результата, нам следует выполнить следующий ряд действий:

  1. Выполнить команду a-tune, которая создаёт новый профиль. При этом, для создания мы используем шаблонный файл профиля с пустыми значениями, как представлено на примере файла testapp1.conf ниже.

# cat testapp1.conf

 [main]

 # list its parent profile

 [kernel_config]

 # to change the kernel config

 [bios]

 # to change the bios config

 [bootloader.grub2]

 # to change the grub2 config

 [sysfs]

 # to change the /sys/* config

 [systemctl]

 # to change the system service status

 [sysctl]

 # to change the /proc/sys/* config

 [script]

 # the script extension of cpi

 [ulimit]

 # to change the resources limit of user

 [schedule_policy]

 # to change the schedule policy

 [check]

 # check the environment

 [tip]

 # the recommended optimization, which should be performed manually

Общий вид команды создания профиля:

atune-adm define [service_type] [application_name] [scenario_name] [profile_path]

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

# atune-adm define testapp1_service testapp1 testapp1_scenario ./testapp1.conf 

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

# atune-adm list | grep testapp1

| testapp1_service-testapp1-testapp1_scenario    | false     |

Заметим, что в данный момент профиль не является активным.

2. Следующим этапом будет сбор данных (то что в AI терминологии именуется Dataset) для обучения новой AI модели. Для этого, мы должны запустить наше приложение testapp1 и дать команду для сбора данных:

atune-adm collection –filename name –interval 5 –duration 120 –output_path /root/data –disk sda –network enp1s0 -t testapp1_service-testapp1-testapp1_scenario

Где: 

  • duration – длительность (в секундах) сбора данных, 
  • sda – диск, на котором находится файловая система, которая используется приложением testapp1, 
  • enp1s0 – имя сетевого адаптера, 
  • testapp1_service-testapp1-testapp1_scenario – имя профиля, который мы создали ранее.

После окончания работы этой команды, в каталоге /root/data будут находится csv файлы c собранной статистикой.

3. Собранную статистику будем использовать для обучения новой модели 

atune-adm   train –data_path /root/data/ –output_file /usr/libexec/atuned/analysis/models/new-model.m

4. И теперь, если мы дадим команду автоопределения профиля (с использованием созданной модели) под работу нашего приложения:

# atune-adm analysis –model /usr/libexec/atuned/analysis/models/new-model.m

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

И в списке профилей, наш профиль уже является активным:

# atune-adm list | grep testapp1

| testapp1_service-testapp1-testapp1_scenario    | true     |

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