Представляем bpftune - легковесный инструмент для автоматической настройки поведения системы.

Ядро Linux содержит более 1500 настраиваемых параметров, и правильная настройка этих параметров может значительно улучшить производительность и использование системы! Мы уже несколько лет пытаемся предоставить правильные рекомендации для этих настраиваемых параметров через релизные заметки программного обеспечения и улучшенные значения по умолчанию, но многие нагрузки системы будут получать выгоду от динамической настройки этих значений.

Представляем bpftune, автоматический конфигуратор, который отслеживает ваши рабочие нагрузки и устанавливает правильные значения параметров ядра! bpftune — это проект с открытым исходным кодом, доступный через dnf install в репозиториях Oracle Linux ol_developer, а также на https://github.com/oracle-samples/bpftune.

Цель bpftune — предоставить легковесную, всегда активную автоматическую настройку поведения системы. Основные преимущества, которые он предоставляет:

Непрерывное отслеживание и корректировка поведения системы с использованием функций наблюдаемости BPF (Berkeley Packet Filter).

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

В настоящее время он сосредоточен на некоторых из наиболее распространенных проблем с настраиваемыми параметрами, с которыми мы сталкивались в Oracle, но с открытой архитектурой, которая открыта для вклада. Мы надеемся, что вы тоже найдете его полезным!

Что может настроить bpftune?

Настроить контроль перегрузки: автоматически выбирать алгоритм контроля перегрузки. См. bpftune-tcp-cong (8).

Настроить таблицу соседей: автоматически настраивать размеры таблиц соседей, увеличивая их при приближении к заполнению. См. bpftune-neigh (8).

Настроить таблицу маршрутов: автоматически настраивать размер таблицы маршрутов, увеличивая ее при приближении к заполнению. См. bpftune-route (8).

Настроить sysctl: отслеживать установки sysctl и если они конфликтуют с автоматически настроенным значением sysctl, отключить соответствующий настраиваемый параметр. См. bpftune-sysctl (8).

Настроить буфер TCP: автоматически настраивать максимальные и начальные размеры буфера. См. bpftune-tcp-buffer (8).

Настроить буфер сети: автоматически настраивать параметры, связанные с основной сетью. См. bpftune-net-buffer (8).

Настроить пространства имен сети: обнаруживать добавление и удаление пространств имен сети, что помогает обеспечить осведомленность о пространствах имен для всего bpftune. Осведомленность о пространствах имен важна, так как мы хотим иметь возможность автоматически настраивать контейнеры. См. bpftune-netns (8).

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

Даже при росте количества настраиваемых параметров ядра, индивидуальные системы получают гораздо меньше внимания и управления со стороны администраторов, чем раньше; фразы вроде «скот, а не домашние животные» отражают это. Учитывая современные облачные архитектуры, используемые для большинства развертываний, большинство систем больше никогда не имеют взаимодействия с человеком после начальной настройки; на самом деле, учитывая требования масштабирования, это часто является явной целью дизайна — «не входить по ssh!».

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

Эти тенденции — сложность системы в сочетании с минимальным взаимодействием администраторов — предполагают пересмотр в плане управления настраиваемыми параметрами.

Вокруг этих настраиваемых параметров накапливается много легенд, и чтобы помочь прояснить, почему мы разработали bpftune, мы будем использовать условную версию подхода, принятого при работе с настраиваемыми параметрами:

«найти набор магических чисел, которые будут работать для системы навсегда»

Очевидно, что это карикатура того, как администраторы подходят к проблеме, но она подчеркивает критическое неявное предположение — что системы статичны.

И вот «BPF» в bpftune; BPF предоставляет средства для проведения низкоуровневых наблюдений за системой. Таким образом, мы не только можем наблюдать систему и настраивать ее соответствующим образом, но и наблюдать эффект этой настройки и перенастраивать при необходимости. Это ключевая особенность bpftune, к которой мы вернемся.

Основные принципы проектирования

Минимизировать накладные расходы. Использовать функции наблюдаемости с осторожностью; не отслеживать события очень высокой частоты.

Ясно указывать изменения политики, предоставляя как «что» — какие изменения были внесены, так и «почему» — как они помогают? Журналирование syslog делает действия политики явными с объяснениями.

Не мешать администратору! Мы можем использовать возможности BPF для наблюдения, если администратор устанавливает настраиваемые значения, которые мы автоматически настраиваем; если это происходит, нам нужно уйти и отключить автоматическую настройку связанного набора функций.

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

Использовать подходы «толк-тяни». Например, при настройке буфера TCP мы часто хотим не мешать приложениям и увеличиваем tcp sndbuf и rcvbuf, но на определенном этапе мы рискуем исчерпать память TCP. Однако мы можем отслеживать, приближаемся ли мы к давлению на память TCP, и если это так, мы можем настроить значения, которые мы настроили. Таким образом, мы можем позволить системе найти баланс между предоставлением ресурсов и их исчерпанием. В некоторых случаях нам не потребуется настраивать значения; они могут быть нормальными, как они есть. Но в других случаях эти ограничения блокируют оптимальную производительность, и если они повышаются безопасно — с учетом глобальных ограничений памяти — мы можем уйти и улучшить производительность. Еще одна проблема заключается в том, что увеличение размера буфера приводит к задержкам — для обработки этого мы коррелируем изменения размера буфера и сглаженное время передачи TCP; если корреляция между ними превышает порог (0,7), мы прекращаем увеличение размера буфера.