Разширено ръководство за оптимизиране на ядрото на Linux и намаляване на латентността

Информатек Дигитал » Ресурси » Разширено ръководство за оптимизиране на ядрото на Linux и намаляване на латентността

Когато говорим за производителност в Linux, почти всичко в крайна сметка сочи към едно и също място: ядрото като централен компонент, който контролира латентността, стабилността и използването на ресурсиПравилната фина настройка може да е от решаващо значение за система, която просто „се справя“ с работата, и такава, която реагира гладко на сървъри, настолни компютри, облачни среди или дори в... много стар хардуер.

Това ръководство се фокусира върху това как Оптимизирайте ядрото на Linux, за да намалите латентността, без да правите компромис със сигурността или поддръжката.Ще разгледаме всичко - от основни архитектурни концепции до настройване със sysctl, компилиране на персонализирани ядра, използване на пачове в реално време, настройване за мрежи с ниска латентност (като в EC2) и техники за наблюдение и бенчмаркинг, за да измерим дали това, което настройвате, действително подобрява нещо.

Архитектура на ядрото на Linux и ключови моменти за латентност

Ядрото на Linux действа като междинен слой между приложенията и хардуера, управлявайки памет, процеси, прекъсвания, драйвери и файлови системи, му монолитен, но модулен дизайнБлагодарение на зареждаемите модули, той ви позволява гъвкаво да активирате или деактивирате функционалности, без да е необходимо да прекомпилирате цялата система.

За да разберем откъде идват латентностите, е ключово да познаваме няколко подсистеми: планиращ процес (планировчик)Управлението на паметта и обработката на прекъсвания са от решаващо значение. Лошо конфигуриран планировчик, агресивна политика за паметта или прекомерен брой неконтролирани прекъсвания могат да доведат до бавно време за реакция, дори при мощен хардуер.

Конфигурацията на ядрото включва опции като CONFIG_PREEMPT, CONFIG_PREEMPT_VOLUNTARY или CONFIG_SMPТези фактори определят степента, до която ядрото може да бъде прекъсвано, за да се справи с по-спешни задачи, и как то използва многоядрените системи. Изборът на правилния модел на превантивно изключване значително променя възприеманата латентност на настолни компютри, сървъри с ниска латентност или индустриални системи.

В съвременните сървъри хардуерната топология също има значение: разпределение на ядра, сокети, NUMA и йерархия на кешаФината настройка на афинитетите на процесора и NUMA политиките (напр. фиксиране на процеси и памет към един и същ възел) помага за намаляване на времето за достъп и подобряване на процента на попадения в кеша, което е ключово, когато искаме да сведем до минимум трептенето и непредсказуемите латентности.

Освен това, взаимодействието между планировчика на процесора и подсистемите на Входно-изходните операции (диск и мрежа) определят пропускателната способност и латентността от край до край които приложенията виждат. Преди да докоснете каквото и да било, препоръчително е да документирате текущото състояние (конфигурация на ядрото, sysctl, GRUB, заредени модули), за да можете бързо да се върнете към предишното състояние, ако промяната влоши производителността.

Корекции чрез sysctl за подобряване на латентността и производителността

интерфейса sysctl ви позволява да променяте параметрите на ядрото в движение чрез /proc/sys, без да е необходимо прекомпилиране. Това е идеалната начална точка за започване на настройката, без да се затруднявате с компилации.

В мрежовото поле, параметри като net.core.rmem_max, net.core.wmem_max или net.ipv4.tcp_congestion_control Те влияят директно върху пропускателната способност, латентността и поведението на TCP връзката. Правилното настройване на буферите и алгоритъма за претоварване е жизненоважно за уеб сървъри с висок трафик или облачни инстанции с ниска латентност.

За паметта, стойности като vm.swappiness, vm.dirty_ratio, vm.vfs_cache_pressure или vm.overcommit_memory Те ви позволяват да контролирате колко swap се използва, как се управлява кешът на страниците и поведението на виртуалната памет. Намаляването на swap (например до 10) обикновено помага да се предотврати твърде честото използване на swap от системата, намалявайки пиковете на латентност на дисковия I/O.

Ако работите с големи бази данни или приложения, които използват огромни количества споделена памет, е изключително важно да коригирате ядро.shmmax, ядро.shmall и максималния брой файлове, отворени с fs.file-max и fs.nr_openТези лошо оразмерени ограничения могат да причинят затруднения и грешки, които са трудни за диагностициране под натоварване.

Най-добрият подход е да се внедрят малки промени, да се измери тяхното въздействие с инструменти за мониторинг и едва след това запазете ги в /etc/sysctl.conf или в /etc/sysctl.d/В контейнеризирани среди, не забравяйте, че много параметри на ядрото са глобални за хоста: небрежната им промяна може да повлияе на всички услуги, така че комбинирането на sysctl с cgroups и namespaces е почти задължително.

Компилиране и поддържане на персонализирани ядра

Компилирането на персонализирано ядро ​​остава много мощен инструмент, когато искате намаляване на латентността, премахване на ненужни режийни разходи или поддръжка на рядък хардуерВъпреки че дистрибуциите се предлагат с доста гъвкави ядра, в определени сценарии конкретното ядро ​​е от решаващо значение.

Класическият работен процес включва изтегляне на кода от kernel.org или пачвани дървета като xanmod или ликьорикси използвайте инструменти като make menuconfig за да изберете опции. Запазването на .config файла във вашето собствено git хранилище, заедно със скриптовете за компилация, ви позволява да възпроизвеждате компилации и да поддържате съгласуваност между версиите.

Ако използвате Debian или негови производни, е много удобно да компилирате „в стила на Дебиан„За да получите .deb пакети на ядрото, заглавните файлове и свързаните с тях библиотеки. Това ви позволява да разположите това персонализирано ядро ​​на множество машини, просто като инсталирате пакетите и управлявате версиите със собствено хранилище.“

В реалния свят, ръчното компилиране често има смисъл, когато работите с стар или много ограничен хардуерТипичен пример е стар нетбук с Atom процесор и 1 GB RAM, където модерно генерично ядро, пълно с ненужни драйвери и сървърни опции, въвежда латентности и допълнителна консумация на процесор, които не можете да си позволите.

Често срещана стратегия е да се започне от текущата конфигурация на ядрото (например чрез копиране на конфигурация /boot) и оттам да изрежете или коригирате. Можете да промените модела на превантивно действие на „Предпазливо ядро ​​(работещ плот с ниска латентност)„за да се даде приоритет на интерактивния отговор на работния плот или да се добавят специфични I/O планировчици, като например Bfq под формата на модул за подобряване на опита с механични дискове.

За да избегнете прекарването на половината от живота си в компилиране, е разумно да извършите компилирането на по-мощна машина и, ако е необходимо, да използвате крос-компилиране (Например, компилиране на 32-битово ядро ​​за Atom от x86_64 компютър, просто чрез настройване на ARCH и съответните инструменти). След това просто трябва да инсталирате .deb файловете на целевата машина и да добавите съответния запис в GRUB.

Трудната част е поддръжката: препоръчително е тестване на новото ядро ​​на възли на Канарските острови, да имат ясни пътища за връщане към предишни версии в мениджъра на зареждане и да записват лог файлове и показатели по време на прехода, за да откриват регресии в производителността или съвместимостта на драйверите.

Модели на превенция и PREEMPT_RT пачове за системи с ниска латентност

Моделът на превантивно изпълнение на ядрото диктува до каква степен една изпълняваща се задача може да бъде прекъсната, за да може задача с по-висок приоритет да поеме контрола, което пряко влияе на латентност на отговораТова включва както стандартни опции за конфигурация, така и корекции в реално време.

Общите ядра предлагат няколко опции: без преемпция (по-фокусирани върху пропускателната способност на сървъра), доброволна преемпция и превантивно ядро ​​за десктопТова дава приоритет на бързото време за реакция на интерактивните приложения. Регулирането на тази настройка може значително да подобри производителността на настолните системи, аудиото или дори на силно натоварени по-стари машини.

Когато трябва да направите още една стъпка, се появява следното: PREEMPT и PREEMPT_RT пачовеТези модификации променят значителни части от ядрото, за да минимизират непредпазваемите секции. PREEMPT_RT е предназначен за системи, където най-лошата латентност (не само средната) трябва да бъде много ниска и предвидима: индустриална автоматизация, професионално аудио, телекомуникации или високочестотна търговия.

Решението за въвеждане на PREEMPT_RT не трябва да се основава на мода, а на специфични измервания на латентност и трептенеПърво, препоръчително е да се използват пълноценно настройките на планировчика, афинитетите на процесора, sysctl и, ако е приложимо, конфигурации като динамично безжично управление (dynamic tickless), преди да се усложнява поддръжката с RT дърво.

Съвместимостта също трябва да се вземе предвид: някои Драйверите и подсистемите не са напълно адаптирани към RT и може да изисква специфични версии или допълнителни пачове. Разумният подход е да се изготви план за поддръжка, който ясно очертава кога и как да се интегрират нови версии на основното ядро ​​с RT клона, който се синхронизира периодично, но все пак изостава донякъде.

Настройка на графика на процесора, работа без тиктакане и изолация на ядрото

В допълнение към избора на модела на преемпция, можете да настроите фино латентността, като експериментирате с планирането на процесора и поведението на таймера на ядрото, особено в корпоративно ориентирани дистрибуции като RHEL.

Red Hat Enterprise Linux 8, например, се предлага с ядрото не се тактува по подразбиране за неактивни процесориТова намалява консумацията на енергия, като избягва периодични прекъсвания, когато ядрото е в покой. Може да се активира режим за чувствителни към латентност натоварвания. динамичен безтиков в набор от ядратака че само един процесор („домашното ядро“) да обработва по-голямата част от задачите, базирани на време, а останалите да са максимално свободни от периодични прекъсвания.

Тази конфигурация се извършва чрез добавяне на подходящи параметри към командния ред на ядрото в GRUBрегенериране на конфигурацията и след това регулиране на афинитета на критични нишки на ядрото, като например RCU нишки или нишки bdi-flush, така че те да се намират в ядрото, запазено за поддръжка.

Този подход може да бъде допълнен с параметъра изолкопусТова позволява ядрата да бъдат изолирани от нормалните задачи в потребителското пространство. Много често в сценарии с ниска латентност е да се резервират няколко ядра изключително за критично приложение, докато останалата част от системата (демони, прекъсвания и др.) се обработва от други ядра.

За да се провери дали динамичният режим без тиктакане работи, могат да се проведат прости тестове с stress или скриптове, които задържат процесора зает за секунда и наблюдават броячи на таймери Как броят на прекъсванията в секунда спада от хиляди до само едно в изолирани ядра, знак, че периодичният таймер е изчезнал.

Управление на паметта и съхранението с фокус върху латентността

Начинът, по който ядрото управлява паметта и дисковия входно/изходен трафик, има огромно влияние върху латентност, възприемана от приложениятаособено в бази данни и услуги, които извършват много малки и чести операции.

От страна на паметта, намалете vm.swappiness минимизиране на използването на swap (който почти винаги е много по-бавен от RAM), vm.vfs_cache_pressure Той контролира колко бързо системата се опитва да изчисти кеша на inode и dentry, и vm.nr_hugepages Това позволява резервиране на статични HugePages за големи натоварвания, като бази данни или JVM, намалявайки TLB режийните разходи.

В хранилището изберете подходящ планировчик на входно/изходни операции според типа на диска Това е критично важно. При съвременните SSD дискове обикновено е добра идея да се използва... none o mq-deadlineДокато при механичните дискове и многозадачните системи, алгоритмите, проектирани за справедливост, може да са по-добри, като например BfqОсвен това, монтиране на файлови системи с опции като noatime y nodiratime Избягвайте ненужни записи всеки път, когато се осъществява достъп до файл или директория.

Относно файловите системи, ext4 и XFS Това остават най-често срещаните опции: добре настроен ext4 е сигурен залог, докато XFS е склонен да се мащабира по-добре при висока паралелност. За много взискателни сценарии, комбинирането на RAID (RAID 10 за бази данни, RAID 0 за временно съхранение) с добър планировчик може да намали средната латентност и, най-вече, променливостта.

Оптимизация на мрежата и ядрото за ниска латентност в Linux и EC2

В високопроизводителните мрежови приложения, латентността зависи не само от хардуера или разстоянието, но и от как са конфигурирани TCP/IP стекът и самото ядроТова е особено видимо в облачни инстанции като Amazon EC2 с ENA интерфейси.

Като начало е ключово да се намалят външните фактори, като например броят на мрежови преходи които пакетите изпълняват: използването на по-директни топологии, балансьори на натоварването близо до backend-а или оптимизирани зони за достъпност намалява времето за пътуване в милисекунди, преди дори да се докосне до операционната система.

В рамките на ядрото, мрежовата конфигурация включва увеличаване файлови дескриптори (ulimit -n), размер на буферите за приемане и изпращане с net.core.rmem_max, net.core.wmem_max, net.ipv4.tcp_rmem, net.ipv4.tcp_wmemи активирайте опции като TCP бързо отваряне за намаляване на латентността при установяване на връзка.

В интерфейсите на AWS ENA, модерирането на прекъсванията играе важна роля: по подразбиране драйверът групира пакетите, за да намали броя на IRQ-тата. rx-usecs и tx-usecsАко искате да намалите латентността до абсолютния минимум, можете да деактивирате тази модерация, като ethtool -CЗадаването на rx-usecs и tx-usecs на нула намалява латентността, но увеличава натоварването от прекъсвания, така че трябва да се намери баланс в зависимост от натоварването.

Може да се използва и irqbalance за разпределяне на IRQ-та между множество ядраили да го деактивирате и ръчно да зададете афинитетите на прекъсванията и мрежовата опашка (RSS/RPS) към конкретни ядра, нещо много типично в среди с ултра ниска латентност или при използване на DPDK и пропускане на голяма част от стека на ядрото.

Друг параметър, който трябва да се вземе предвид, е CPU C състоянияДълбоките състояния на сън намаляват консумацията на енергия, но въвеждат забавяния, когато ядрото се „събужда“. За да намалите латентността на реакцията, можете да ограничите тези дълбоки състояния, като приемете по-висока консумация на енергия и по-малко място за Turbo Boost на други ядра. Всяка среда има своя „златна зона“ между консумираните ватове и спечелените микросекунди.

Оптимизация на процесора, услугите и приложенията за намаляване на латентността

Освен самото ядро, околната среда има много какво да каже за общата латентност: от активни услуги в системата до специфичната конфигурация на всяко приложение.

Високопроизводителният сървър трябва да изпълнява само демони, които са наистина необходимиУслуги като Bluetooth, печат или автоматично откриване на мрежа (CUPS, Avahi и др.) на бекенд машини консумират само процесор, памет и входно/изходни операции, без да предоставят никаква полза. Прегледайте с systemctl list-unit-files --state=enabled А деактивирането на ненужните неща е едно от най-евтините и ефективни неща, които можете да направите.

За да приоритизирате критичните процеси, можете да използвате инструменти като renice, chrt и tasksetНастройването на приоритета на даден процес (renice), задаването му на график в реално време (chrt -f 99) или присвояването му на конкретни ядра (taskset) намалява смущенията с други задачи, подобрявайки предвидимостта на процесора за бази данни, VoIP, стрийминг или търговски услуги.

На ниво приложение, настройката е също толкова важна, колкото и настройката на ядрото. Уеб сървъри като например Nginx или Apache Те се нуждаят от фина настройка на работните процеси, keepalive, кешове и компресия. Бази данни като PostgreSQL или MySQL Те трябва да прегледат размерите на буферите, контролните точки, пула за връзки и параметрите за синхронно записване, за да постигнат ниски и стабилни латентности.

JVM също играят роля: избират колектори за боклук като G1GC или ZGC Регулирането на размерите на heap паметта може да намали паузите, които от външна гледна точка се възприемат като латентност. Във виртуализирани и контейнеризирани среди правилното разпределение е от решаващо значение. vCPU, vRAM и I/O квоти Това избягва тихото съревнование, което по-късно се проявява като безкрайни опашки на диска или наситен процесор.

Мониторинг и бенчмаркинг на ядрото и системата

Цялото това настройване е безполезно, ако не измервате въздействието. Ключът е в комбинирането. непрекъснато наблюдение с възпроизводими тестове за производителносттака че всяка промяна в ядрото или sysctl да може да бъде оценена с обективни данни.

За да видите общото състояние на системата, можете да използвате класически инструменти като htop, vmstat, iotop o sarКогато имате нужда от повече подробности, се намесват специфични инструменти на ядрото, като например perf и ftraceкоито ви позволяват да проследявате поведението на планировчика, прекъсванията и вътрешните повиквания със значителна точност.

В производствени среди се препоръчва внедряването на метрични системи като например Prometheus, collectd или sysstat с експортери които показват броячи на процесора, входно/изходни операции, латентности на диска и мрежата, опашки от процеси и др. Тези данни, визуализирани в Grafana или подобни инструменти, помагат за откриване на регресии или аномалии, преди крайният потребител да забележи проблеми.

За бенчмаркинг идеята е да се възпроизведе действителното натоварване и да се сравни „преди и след“ всяка промяна. Инструменти като sysbench (за процесори и бази данни), Fio (за диск) или iperf3 (За мрежите) те позволяват изграждането на повтарящи се сценарии. Документацията е от съществено значение. версии на ядрото, конфигурации на sysctl, хардуер и тестови параметри така че сравненията да имат смисъл във времето.

На практика, оптимизацията на ядрото на Linux е итеративен процес: тествате серия от промени, измервате резултатите, запазвате това, което осигурява реална полза, и отхвърляте останалите. С добро управление на промените можете да превърнете подобренията в новите версии на ядрото (като например последните серии с подобрения в планировчика, графиката, захранването или мрежата) в измерими ползи за вашите приложения, независимо дали са локални сървъри, в облака или на взискателни работни станции.

Комбинацията от познания за архитектурата на ядрото, фина настройка със sysctl, контролирана компилация, селективно използване на корекции в реално време и добра система за показатели позволява на администратора или оперативния екип да постигне По-бързи отговори, по-ниска латентност и подобрена обща стабилност без да се налага да сменяте хардуер при най-малката провокация или да компрометирате системната сигурност.