Розширена оптимізація ядра Linux за допомогою sysctl

Інформатек Діджитал » Ресурси » Розширена оптимізація ядра Linux за допомогою sysctl

Якщо ви вже деякий час керуєте серверами Linux, то зрештою виявите, що різниця між посередньою системою та тією, яка працює під великим навантаженням, полягає в тому, наскільки добре ви налаштували ядро. Йдеться не лише про встановлення більшої кількості оперативної пам'яті або потужнішого процесора: багато вузьких місць вирішуються шляхом налаштування кількох ретельно підібраних параметрів.

Ядро надає сотні параметрів планування мережі, пам'яті, файлової системи та процесів, які можна змінювати на льоту. За допомогою інструменту sysctl та деякі коригування в /procМожливо отримати максимальну віддачу від апаратного забезпечення та досягти менша затримка, вища пропускна здатність та краща стабільність Це стосується веб-серверів і баз даних, а також середовищ реального часу та Kubernetes. Однак важливо точно знати, що ви робите і як це вимірювати.

Що таке sysctl і як він організовує параметри ядра?

Утиліта sysctl Це шлюз для зміни параметрів ядра без необхідності перекомпіляції чи перезавантаження, що дозволяє читати та змінювати значення під час виконання для миттєвого тестування конфігурацій. Ці параметри організовані в низьке ієрархічне дерево /proc/sys/і кожен з них контролює певну поведінку системи.

Налаштування згруповано в окремі категорії, що дозволяє легко визначити, що потрібно налаштувати, коли ви зіткнулися з певною проблемою продуктивності або стабільності. Така структура дозволяє зосередитися, наприклад, виключно на мережі (net.*), пам'яті (vm.*) або файловій системі (fs.*), не гублячись в інших параметрах ядра.

Основні категорії, які ви знайдете в /proc/sys/ До них належать, серед іншого:

• ядро.*: загальні параметри ядра (планувальник, PID, повідомлення, NUMA тощо).
• вм.*: управління віртуальною пам'яттю, підкачка, кеші та політики перевищення фіксації.
• нетто.*Мережевий стек IPv4/IPv6, буфери TCP/UDP, черги, контроль перевантаження.
• фс.*: обмеження дескрипторів, inodes, inotify, поведінки AIO та VFS.
• розробник*: специфічні параметри певних пристроїв та драйверів.

з sysctl -a Ви можете перерахувати всі доступні параметри, а за допомогою таких команд, як sysctl vm.swappiness o sysctl net.ipv4.tcp_tw_reuse зчитування конкретних значень, що є ключовим для аудит поточної конфігурації перш ніж щось змінювати. Щоб знайти щось конкретне, зазвичай використовується фільтрація за допомогою grep, наприклад: sysctl -a | grep tcp.

Зміна параметра на льоту така ж проста, як використання sysctl -w clave=valorОднак важливо розуміти, що ці зміни тимчасові. Щоб зберегти їх після перезавантаження, необхідно створити резервну копію конфігурації на /etc/sysctl.conf або у файлах /etc/sysctl.d/, зазвичай використовуючи нумеровані файли (наприклад 10-network.conf, 20-memory.conf, 99-custom.conf), що визначають порядок їх застосування.

Виміряйте, перш ніж торкатися: контрольні показники та базові показники системи

Перш ніж почати маніпулювати циферблатами, варто встановити об'єктивний базовий рівень продуктивності . Без попередніх даних неможливо знати, чи зміни покращили чи погіршили роботу системи, і ви потрапите в класичну пастку «мені здається, що так краще», яка марна для прийняття обґрунтованих рішень.

На системному рівні гарною ідеєю є збирати статистику процесора, завантаження, пам'яті, диска та мережі протягом кількох хвилин під репрезентативним навантаженням. Такі інструменти, як uptime, mpstat, vmstat, iostat -x o sar -n DEV Вони дозволяють побачити, як поводиться стандартне ядро, скільки підкачки воно використовує, як реагує дисковий ввід/вивід, а також чи перенасичена мережа, чи витрачає вона пропускну здатність.

Окрім цього огляду, важливо провести спеціальні тести для програми, яку ви хочете оптимізувати. На веб-серверах ви можете використовувати ab (Apache Bench) або аналогічні інструменти для вимірювання запитів за секунду, середня затримка та помилкиУ базах даних такі утиліти, як mysqlslap o sysbench Вони допомагають оцінювати транзакції за секунду та час запитів.

Наприклад, у сценарії без налаштування часто можна знайти такі показники, як 500 HTTP-запитів/с із середнім часом відгуку 200 мс, близько 250 SQL-запитів/с із затримкою 40 мс, швидкість мережі приблизно 500 Мбіт/с та системне навантаження, що наближається до своєї межі під навантаженням. Ці показники будуть використані для перевірки, після застосування змін ядра, чи дійсно досягнуто вимірного збільшення пропускної здатності та зменшення затримки.

Зрештою, задокументуйте команди та результати, перш ніж вносити будь-які зміни. Наявність історії дозволить вам точно порівнювати різні пакети налаштувань, а також допоможе виявляти регресії після оновлення ядра або після впровадження нового профілю sysctl у продакшн.

Розширені налаштування пам'яті: vm.*

Пам'ять – це одна з підсистем, де зміни ядра найбільш помітні. Сервер з великою кількістю оперативної пам'яті, але погано налаштований, може непотрібно використовувати простір підкачки, що призводить до... Піки вводу/виводу та різке падіння продуктивностіОсь чому такі параметри, як vm.swappinessСпіввідношення «брудних» сторінок або поведінка кешу VFS не менш важливі.

Параметр vm.swappiness Це визначає, скільки сторінок пам'яті ядро ​​надсилає на swap. У багатьох дистрибутивах це значення встановлено на 60, що призначено для змішаних середовищ робочого столу. Для серверів баз даних або програм з низькою затримкою зазвичай краще знизити його до 10 або навіть менше, що призведе до більш ефективної роботи системи. пріоритет зберігання даних в оперативній пам'яті та зменшення кількості підкачокНерідко можна побачити, як після такого коригування трафік диска різко падає, а програми реагують зі значно меншим джиттером.

Ще одним фундаментальним будівельним блоком є vm.dirty_ratio y vm.dirty_background_ratioЦі значення визначають, який відсоток пам'яті може бути заповнений брудними сторінками, перш ніж ядро ​​почне скидати їх на диск. Надмірно високі значення можуть призвести до великих сплесків запису з величезними затримками для всіх програм, коли відбувається скидання. Зменшення цих відсотків до таких цифр, як 15 та 5 відповідно, зазвичай призводить до... більш послідовний та передбачуваний шаблон вводу/виводу.

Налаштування vm.vfs_cache_pressure Це визначає, наскільки агресивно ядро ​​очищує кеш inode та каталогів. Значення за замовчуванням 100, як правило, очищує кеш швидко, тоді як налаштування близько 50 дозволяють довше зберігати метадані, збільшуючи частоту виконання файлових операцій та покращуючи продуктивність. сприйнята продуктивність файлової системи, що є ключовим для серверів, які обробляють мільйони невеликих файлів.

Зі свого боку, vm.min_free_kbytes Резервуйте мінімальний обсяг вільної пам'яті, щоб система могла реагувати на сплески виділення, не стикаючись з раптовими ситуаціями «поза коробкою» (OOB). Виділення цього розміру приблизно від 0,5% до 1% від загального обсягу оперативної пам'яті зазвичай є ефективним заходом безпеки, щоб запобігти вичерпанню місця в ядрі під екстремальним навантаженням і початку завершення критичних процесів, тим самим покращуючи продуктивність. загальна стабільність господаря.

Зрештою, заслуговує на увагу політика надмірного виконання зобов'язань: такі параметри, як vm.overcommit_memory y vm.overcommit_ratio Вони визначають, скільки віртуальної пам'яті виділяється процесам відносно доступної оперативної пам'яті та підкачки. У деяких випадках (наприклад, з Redis або певними базами даних) дозволяється агресивне перевищення ресурсів, тоді як в інших перевага надається більш консервативній політиці для обмеження ризику... OOM та ситуації надмірного порушення пам'ятіЩодо методів аналізу та діагностики складних випадків, зверніться налагодження пам'яті в Linux.

Розширена оптимізація мережі: net.* та TCP/IP

Мережевий стек, мабуть, є тією областю, де налаштування найбільш помітне у виробничому середовищі. Проста зміна в чергах з’єднань або буферах може мати вирішальне значення між сервером, який задихається на швидкості 500 Мбіт/с, і тим, який... Він легко насичує гігабіт.Параметри, зазначені нижче net.core.* y net.ipv4.* У цій галузі вони ваші найкращі союзники.

Почнемо з того, що розміри буферів сокетів безпосередньо впливають на максимальну пропускну здатність з'єднання, особливо за високих затримок або з'єднань з високою пропускною здатністю. Налаштуйте net.core.rmem_max y net.core.wmem_max до щедрих значень (десятки чи сотні мегабайт) та правильно визначити net.ipv4.tcp_rmem y net.ipv4.tcp_wmem (мінімальне, значення за замовчуванням та максимальне) дозволяє кожному сокету мати простір, необхідний для пом'якшення сплеску руху транспорту не потрапляючи під штучні обмеження, нав'язані дуже консервативними заводськими цінностями.

Ще одним ключовим моментом є розмір черг з’єднань. Такі параметри, як net.core.somaxconn, net.core.netdev_max_backlog y net.ipv4.tcp_max_syn_backlog Ці обмеження визначають, скільки з’єднань, що очікують обробки, система може обробити, перш ніж скинути пакети або відхилити рукостискання. На веб-серверах з високим трафіком збільшення цих обмежень може запобігти перенасиченню черг і значно зменшити навантаження. помилки підключення під час пікових навантажень.

Поведінку TCP-з’єднань також можна точно налаштувати за допомогою безлічі опцій: увімкнути net.ipv4.tcp_window_scaling Щоб підтримувати великі вікна на високошвидкісних з’єднаннях, увімкніть net.ipv4.tcp_sack y net.ipv4.tcp_timestamps покращити управління втратами та ретрансляцією або налаштувати net.ipv4.tcp_fin_timeout та управління о TIME_WAIT (net.ipv4.tcp_tw_reuse, net.ipv4.tcp_max_tw_buckets) для контролю споживання ресурсів на серверах за допомогою мільйони коротких з'єднань за хвилину.

Вибір алгоритму контролю перевантаження також має значення. Хоча cubic Це залишається значенням за замовчуванням у багатьох дистрибутивах; зміна на bbr у сучасних ядрах (4.9 та пізніших версій) net.ipv4.tcp_congestion_control y net.core.default_qdisc=fq Він може збільшити пропускну здатність TCP у середовищах зі складними втратами або затримками, досягаючи покращень від 2 до 25 разів порівняно з класичними конфігураціями в певних сценаріях, але за рахунок... дещо інша поведінка в перевантажених мережах.

Не можна забувати про такі параметри безпеки та надійності, як net.ipv4.tcp_syncookies, обробка переадресацій (net.ipv4.conf.all.accept_redirects, send_redirects) або фільтрація в мостах (net.bridge.bridge-nf-call-iptables (у середовищах Kubernetes). Правильно налаштовані, вони дозволяють захистити систему від поширених атак (SYN-флуд, спуфінг тощо) без шкоди для стабільна продуктивність мережіЩоб отримати практичний посібник з правил та виявлення, перегляньте Реалізація Netfilter та Suricata.

Файлова система, дескриптори та глобальні обмеження: fs.* та ulimit

На сучасних серверах низький ліміт файлових дескрипторів – це найшвидший спосіб зламати систему в години пік. Коли веб-сервер, зворотний проксі-сервер або база даних стикаються з класичною помилкою «занадто багато відкритих файлів», це зазвичай відбувається тому, що параметри ядра та обмеження користувачів не були масштабовані для фактичного навантаження.

Глобально, fs.file-max Це визначає, скільки дескрипторів ядро ​​може відкрити загалом. Для програм з тисячами одночасних підключень зазвичай це значення збільшують до кількох мільйонів, а також збільшують fs.nr_openщо встановлює жорстку стелю для дескрипторів на кожен процес. Крім того, необхідні коригування. /etc/security/limits.conf щоб користувачі (або служби, якими керує systemd) мали м'які та жорсткі значення, що відповідають конфігурації ядра.

Підсистема inotify, яка широко використовується в IDE, інструментах веб-розробки та системах моніторингу файлів, контролюється такими параметрами, як fs.inotify.max_user_watches y fs.inotify.max_user_instancesЯкщо ви зіткнулися з помилками, пов’язаними зі спостерігачами або процесами, які припиняють моніторинг змін на диску, вам, ймовірно, потрібно Збільште ці обмеження, щоб уникнути тихих вузьких місць.

Ще однією важливою особливістю є асинхронний ввід/вивід (AIO), глобальний максимум якого визначається за допомогою fs.aio-max-nrУ застосунках, які значною мірою залежать від асинхронного вводу-виводу (певні механізми баз даних, системи черг тощо), збільшення цього значення запобігає вичерпанню слотів ядра для операцій AIO під час масивного навантаження запитів.

Окрім цих параметрів, на продуктивність дискової підсистеми впливає Планувальник вводу/виводу налаштовано на кожному блочному пристрої. У системах із SSD або NVMe зазвичай рекомендується використовувати легкі планувальники, такі як none o mq-deadline, тоді як на механічних дисках інші варіанти можуть мати сенс, такі як bfq залежно від типу навантаження. Налаштуйте планувальник за допомогою /sys/block/<disco>/queue/scheduler та налаштувати параметри, такі як глибина черги (nr_requests) або read_ahead_kb може зробити помітну різницю в затримка та пропускна здатність читання/записуТакож важливо враховувати, які файлові системи та драйвери використовуються; наприклад, статті про NTFSplus у Linux та інші системи можуть допомогти при проектуванні неоднорідних навантажень.

Зрештою, не слід забувати, що ці обмеження ядра повинні йти пліч-о-пліч із конфігураціями системи, такими як ті, що... ulimit та одиниці systemd, щоб гарантувати, що служби можуть фактично використовувати визначені додаткові ресурси та не блокуються обмеження у верхніх шарах.

Загальні характеристики ядра, NUMA, спорідненість процесора та величезні сторінки

Окрім мережевих, пам'ятних та файлових систем, саме ядро ​​пропонує низку опцій налаштування, які впливають на планування процесів, розподіл робочих навантажень між ядрами та вузлами NUMA, а також на управління пам'яттю в масштабі. На сучасних машинах з багатьма ядрами та навіть кількома сокетами ці деталі часто визначають різницю між збалансованим сервером та сервером, у якого деякі ядра перенасичені, а інші використовуються недостатньо . Варто також дослідити альтернативні ядра, такі як ядро ​​Liquorix, у середовищах, де потрібен інший профіль затримки.

Такі параметри, як kernel.pid_max Вони встановлюють максимальний діапазон ідентифікаторів процесів, які може призначити система, що актуально для вузлів, на яких працює велика кількість контейнерів або ефемерних процесів. Налаштування параметрів ведення журналу ядра (kernel.printk) допомагає зменшити надмірний шум у dmesg, водночас записуючи критичні події, що також опосередковано впливає на діагностичні можливості та стабільність.

Щодо топології пам'яті, параметр kernel.numa_balancing Він контролює ступінь, до якої ядро ​​автоматично переміщує сторінки між вузлами NUMA. Його вимкнення в певних середовищах дозволяє більш чітко керувати спорідненістю процесів та пам'яті за допомогою таких інструментів, як numactl щоб забезпечити, щоб процеси, що ресурсомісткі для процесора та оперативної пам'яті, залишалися на одному вузлі, зменшуючи затримка, що виникає внаслідок віддаленого доступуЩоб краще зрозуміти взаємодію між апаратним забезпеченням та плануванням роботи основних пристроїв, також корисно розглянути такі технології, як Директор потоків Intel.

Величезні сторінки (vm.nr_hugepagesЦе ще один ключовий компонент у системах баз даних або інших робочих навантаженнях, які обробляють великі області суміжної пам'яті. Резервування відповідної кількості гігантських сторінок (2 МБ або навіть 1 ГБ, залежно від архітектури) може зменшити накладні витрати TLB та значно покращити продуктивність програм, що працюють. багато операцій з великими блоками пам'ятіЩоб це було ефективно, конфігурація ядра має бути узгоджена з самою програмою, щоб вона явно використовувала цю пам'ять.

У сфері затримки та планування існують такі параметри планувальника, як kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns o kernel.sched_migration_cost_nsЦі параметри точно налаштовують розмір «фрагментів» процесора, що виділяються для кожного завдання, та агресивність, з якою ядро ​​переміщує процеси між ядрами. Менші значення представляють собою більш випереджувальну систему, яка, як правило, пропонує найкраща відповідь для інтерактивних завдань ціною, іноді, невеликої пропускної здатності.

У системах, де пам'ять є чутливим ресурсом, деякі адміністратори вирішують активувати режим паніки у разі виникнення помилки "з коробки" (vm.panic_on_oom) і встановити kernel.panic з автоматичним часом перезапуску. Ця стратегія, хоча й дещо радикальна, може бути корисною в середовищах високої доступності, де Швидке та контрольоване перезавантаження краще, ніж завислий та нестабільний хост. протягом годин.

Спеціалізовані профілі: веб, бази даних, низька затримка та Kubernetes

Замість застосування одного чарівного засобу, ефективніше створювати профілі sysctl, адаптовані до різних типів робочих навантажень: веб-серверів, баз даних, контейнерних платформ або систем з низькою затримкою. Розподіл цих налаштувань у файлах, таких як 99-webserver.conf, 99-database.conf o 90-kubernetes.conf допомогти підтримувати організовану та просту в версійній налаштуванні конфігураціюВи також можете розглянути дистрибутиви та видання, орієнтовані на продуктивність, такі як Серверна версія CachyOS для дуже специфічних середовищ.

Для веб-серверів (Nginx, Apache, проксі тощо) найважливішим є обробка великих обсягів одночасних з'єднань з великими чергами та часом відгуку. FIN_WAIT Завдяки точному налаштуванню, розширеному діапазону тимчасових портів та дуже високим обмеженням дескрипторів, зазвичай кількість HTTP-запитів за секунду зростає від кількох сотень до кількох тисяч, що зменшує середню затримку та усуває помилки. перенасичені черги або повні порти.

На стороні баз даних (MySQL, PostgreSQL та подібні) пріоритет надається мінімальному використанню swap, точному налаштуванню запису брудних сторінок та відповідним налаштуванням спільної пам'яті та семафорів для рушія. Такі параметри, як kernel.shmmax, kernel.shmall, kernel.sem а конфігурація величезних сторінок має значення з точки зору транзакцій за секунду та час відгуку, множачи продуктивність на два або три порівняно зі значеннями за замовчуванням у багатьох сценаріях.

Для програм з надзвичайно низькою затримкою (торгівля, онлайн-ігри, обробка даних у реальному часі) додано ще більш специфічні налаштування: net.ipv4.tcp_low_latency, деактивація повільного запуску після бездіяльності, використання tcp_fastopen, параметри опитування зайнятості (net.core.busy_poll, busy_read) та, в багатьох випадках, деактивація прозорих величезних сторінок за допомогою /sys/kernel/mm/transparent_hugepage/enabledВсе це спрямовано на зменшення черга обробки та піки затримки на високих процентилях, досягаючи вражаючих покращень у P99.

У контейнерних середовищах та середовищах Kubernetes мережевий стек та відстеження з’єднань зазнають особливого навантаження. Такі параметри, як net.ipv4.ip_forward, net.bridge.bridge-nf-call-iptables, net.netfilter.nf_conntrack_maxВикористання зарезервованих портів для NodePort або налаштування таблиць ARP є поширеними на вузлах, які обробляють сотні або тисячі pod-систем. Правильне їх налаштування запобігає проблемам. обрізані з'єднання, тайм-аути або перенасичення таблиці за допомогою conntrack.

Окрім цих специфічних профілів, деякі організації обирають архів, орієнтований на продуктивність, з покращеною безпекою, поєднуючи великі мережеві буфери та зменшену кількість обмінних даних з такими заходами, як tcp_syncookies або блокування небезпечних переадресацій. Мета полягає в досягненні точка балансу між агресивною дією та розумним посиленням.

Інструменти профілювання та моніторингу ядра

Налаштування ядра без вимірювань — це як грати на аудіомікшері із зав'язаними очима. Linux пропонує арсенал інструментів для розуміння того, що насправді робить система, від простих лічильників до детальних трас функцій ядра, що дозволяє співвідносити зміни конфігурації з вимірюваними ефектами.

Серед повсякденних утиліт є vmstat, iostat, sar, ss, slabtop, htop o pidstatякі надають швидку інформацію про процеси, процесор, операції вводу/виводу, сокети та використання кешу. У поєднанні із системними журналами та метриками, експортованими до Prometheus, Grafana або collectd, а також з такими ресурсами, як розширений системний монітор для LinuxВони дають досить повне уявлення про те, як поводиться хост до і після кожного налаштування.

Якщо вдатися до більш детального опису, то такі інструменти, як perf Вони дозволяють профілювати використання процесора на рівні функцій, як користувача, так і ядра, реєструвати події протягом кількох секунд або хвилин, а потім надавати інтерактивний звіт. perf stat, perf record y perf report ви можете побачити де фактично витрачається процесорний час і яка його частина відповідає ядру, ідентифікуючи, наприклад, шторм переривань або погано налаштований планувальник.

Якщо вам потрібна ще більша деталізація, ftrace Підсистема трасування ядра пропонує можливість активувати певні трасери (наприклад, трасер функцій) та перевіряти в режимі реального часу або після аналізу, які виклики відбуваються. Увімкнення відповідного трасера ​​та аналіз його вмісту /sys/kernel/debug/tracing/trace це відкриває тобі гарячі точки в самому ядріЦе дуже корисно, коли показників високого рівня недостатньо.

Паралельно з цим доцільно впроваджувати автоматизовані скрипти моніторингу, які періодично виводять ключові дані (мережеву статистику, лічильники пам'яті, кількість відкритих файлових дескрипторів тощо) в обертові журнали. Після досягнення певних порогових значень (наприклад, перевищення заданої кількості відкритих файлових дескрипторів) ці скрипти можуть генерувати сповіщення електронною поштою або іншими каналами, допомагаючи виявляти небезпечні тенденції до того, як проблема загостриться.

Зрештою, у тривалих фазах стрес-тестування (24 години або більше) такі інструменти, як stress-ng у поєднанні з безперервним збором показників (через vmstat, iostat, sar) дозволяють оцінити стабільність системи з новою конфігурацією ядра, перевіряючи відсутність подій OOM, збоїв, неочікуваних перезавантажень або поступового зниження продуктивності під тривалим навантаженням.

Оптимізація ядра Linux за допомогою sysctl та інших механізмів — це не одноразове завдання, а радше ітеративний процес, що включає вимірювання результатів, налаштування параметрів та ретельне документування всього. Завдяки чіткій методології, специфічним профілям для кожного типу робочого навантаження, надійному набору інструментів профілювання та суворому контролю змін, можливо створити сервери, які повністю використовують своє обладнання, зі збільшеною пропускною здатністю, зменшеною затримкою та значно більшою стабільністю, ніж типова заводська конфігурація.