Haladó útmutató a Linux kernel optimalizálásához és a késleltetés csökkentéséhez

Informatec Digital » Források » Haladó útmutató a Linux kernel optimalizálásához és a késleltetés csökkentéséhez

Amikor Linuxban a teljesítményről beszélünk, szinte minden ugyanarra a dologra mutat: a kernelre, mint központi komponensre, amely a késleltetést, a stabilitást és az erőforrás-felhasználást szabályozza . Ennek finomhangolása jelentheti a különbséget egy olyan rendszer között, amely éppen csak "megbirkózik" a feladatokkal, és egy olyan között, amely simán reagál szervereken, asztali gépeken, felhőalapú környezetekben vagy akár nagyon régi hardvereken is.

Ez az útmutató arra összpontosít, hogyan optimalizálható a Linux kernel a késleltetés minimalizálása érdekében a biztonság vagy a karbantarthatóság veszélyeztetése nélkül . Mindent lefedünk az alapvető architektúrai koncepcióktól kezdve a sysctl használatával végzett finomhangolásokon át az egyéni kernelek fordításáig, a valós idejű javítások használatáig, az alacsony késleltetésű hálózatokhoz (például az EC2) való hangolásig, valamint a monitorozási és teljesítményértékelési technikákig, amelyekkel mérhető, hogy a finomhangolások valóban javítják-e a teljesítményt.

Linux kernel architektúra és a késleltetés kulcsfontosságú pontjai

A Linux kernel közvetítő rétegként működik az alkalmazások és a hardver között, kezelve a memóriát, a folyamatokat, a megszakításokat, az illesztőprogramokat és a fájlrendszereket . Monolitikus, mégis moduláris felépítése a betölthető moduloknak köszönhetően lehetővé teszi a funkciók rugalmas engedélyezését vagy letiltását a teljes rendszer újrafordítása nélkül.

A késleltetés forrásának megértéséhez elengedhetetlen számos alrendszer ismerete: a folyamatütemező , a memóriakezelés és a megszakításkezelés. Egy rosszul konfigurált ütemező, egy agresszív memóriapolitika vagy a túl sok ellenőrizetlen megszakítás lassú válaszidőket eredményezhet, még nagy teljesítményű hardverek esetén is.

A kernel konfigurációs beállításai, mint például a CONFIG_PREEMPT, CONFIG_PREEMPT_VOLUNTARY és CONFIG_SMP, szerepet játszanak . Ezek határozzák meg, hogy a kernel milyen mértékben vehető igénybe sürgősebb feladatok elvégzésére, és hogyan kezeli a többmagos rendszereket. A megfelelő megelőzési modell kiválasztása jelentősen megváltoztatja az érzékelt késleltetést asztali számítógépeken, alacsony késleltetésű szervereken vagy ipari rendszereken.

A modern szerverekben a hardver topológia is számít: a magok elosztása, a socketek, a NUMA és a gyorsítótár hierarchiája . A CPU-affinitások és a NUMA-szabályzatok finomhangolása (például a folyamatok és a memória ugyanahhoz a csomóponthoz rendelése) segít csökkenteni az elérési időket és javítani a gyorsítótár találati arányát, ami kulcsfontosságú a jitter és a kiszámíthatatlan késleltetések minimalizálása szempontjából.

Továbbá a CPU ütemező és az I/O alrendszerek (lemez és hálózat) közötti interakció határozza meg az alkalmazások által tapasztalt végpontok közötti átviteli sebességet és késleltetést . Mielőtt bármilyen változtatást végrehajtana, célszerű dokumentálni az aktuális állapotot (kernel konfiguráció, sysctl, GRUB, betöltött modulok), hogy lehetővé tegye a gyors visszaállítást, ha egy módosítás rontja a teljesítményt.

Sysctl-en keresztüli módosítások a késleltetés és a teljesítmény javítása érdekében

A sysctl interfész lehetővé teszi a kernel paramétereinek menet közbeni módosítását a /proc/sys fájlon keresztül, újrafordítás nélkül. Ideális belépési pont a finomhangoláshoz anélkül, hogy elakadnánk a fordításban.

Hálózati környezetben az olyan paraméterek, mint a net.core.rmem_max, net.core.wmem_max és net.ipv4.tcp_congestion_control, közvetlenül befolyásolják az átviteli sebességet, a késleltetést és a TCP-kapcsolat viselkedését. A pufferek és a torlódási algoritmus megfelelő beállítása létfontosságú a nagy forgalmú webszerverek vagy az alacsony késleltetésű felhőpéldányok számára.

Memória esetén az olyan értékek, mint a vm.swappiness, vm.dirty_ratio, vm.vfs_cache_pressure és vm.overcommit_memory lehetővé teszik a swap memória használatának szabályozását, az oldalgyorsítótár kezelésének módját és a virtuális memória viselkedését. A swappiness csökkentése (például 10-re) általában segít megakadályozni, hogy a rendszer túl gyakran használja a swap memóriát, csökkentve a lemez I/O miatti késleltetési csúcsokat.

Ha nagy adatbázisokkal vagy olyan alkalmazásokkal dolgozik, amelyek hatalmas mennyiségű megosztott memóriát használnak, kritikus fontosságú a kernel.shmmax, kernel.shmall értékek , valamint a megnyitott fájlok maximális számának módosítása az fs.file-max és az fs.nr_open paraméterek használatával . A nem megfelelően méretezett korlátok szűk keresztmetszeteket és hibákat okozhatnak, amelyeket terhelés alatt nehéz diagnosztizálni.

Javasoljuk, hogy apró változtatásokat hajts végre, mérje fel azok hatását monitorozó eszközökkel, és csak ezután commitolja őket az /etc/sysctl.conf vagy az /etc/sysctl.d/ fájlba . Konténerizált környezetekben ne feledje, hogy számos kernelparaméter globális a gazdagép számára: a gondatlan módosítások az összes szolgáltatást érinthetik, így a sysctl kombinálása cgroups-szal és névterekkel szinte kötelező.

Egyéni kernelek fordítása és karbantartása

Egyéni kernel fordítása továbbra is hatékony eszköz, ha csökkenteni szeretnéd a késleltetést, el szeretnéd távolítani a felesleges terhelést, vagy szokatlan hardvereket szeretnél támogatni . Bár a disztribúciók meglehetősen sokoldalú kerneleket tartalmaznak, bizonyos esetekben egy adott kernel mindent megváltoztat.

A klasszikus munkafolyamat magában foglalja a kód letöltését a következő helyről: kernel.org vagy olyan foltozott fák, mint a xanmod vagy liquorixés használjon olyan eszközöket, mint make menuconfig a beállítások kiválasztásához. A .config fájl mentése a saját git reprodukálódba a build szkriptekkel együtt lehetővé teszi a buildek reprodukálását és a verziók közötti konzisztencia megőrzését.

Ha Debiant vagy annak egy származékát használod, nagyon kényelmes " a Debian módján " lefordítani, hogy a kernel, a fejlécek és a kapcsolódó könyvtárak .deb csomagjait megszerezd. Ez lehetővé teszi, hogy az egyéni kernelt több gépre is telepítsd egyszerűen a csomagok telepítésével és a verziók kezelésével a saját adattáradból.

A való világban a kézi fordítás gyakran logikusnak tűnik régi vagy nagyon korlátozott hardverek esetén . Tipikus példa erre egy régi netbook Atom CPU-val és 1 GB RAM-mal, ahol egy modern, generikus kernel, tele felesleges illesztőprogramokkal és szerver szintű opciókkal, késleltetést és extra CPU-használatot okoz, amit nem engedhetünk meg magunknak.

Egy gyakori stratégia az, hogy az aktuális kernelkonfigurációval kezdünk (például a konfigurációs fájl másolásával a /boot könyvtárból ), majd azt vágjuk vagy módosítjuk. A preemptio modellt „ Preemptible Kernel (Low-Latency Desktop) ” értékre módosíthatjuk, hogy az asztal interaktív válaszát rangsoroljuk, vagy hozzáadhatunk specifikus I/O ütemezőket, például a BFQ-t modulként a mechanikus lemezek élményének javítása érdekében.

Hogy elkerüljük a fordítással eltöltött hosszú időt, érdemes egy erősebb gépre építkezni, és ha szükséges, keresztfordítást használni (például egy 32 bites kernelt egy Atomhoz egy x86_64 PC-ről az ARCH és a hozzá tartozó eszközláncok egyszerű módosításával). Ezután már csak telepítenünk kell a .deb fájlokat a célgépre, és hozzá kell adni a megfelelő bejegyzést a GRUB-hoz.

A trükkös rész a karbantartás: ajánlott az új kernelt a Kanári-szigeteki csomópontokon tesztelni , egyértelmű visszagörgetési útvonalakat használni a rendszerindító kezelőben, és naplókat és metrikák rögzítése az átmenet során a teljesítmény vagy az illesztőprogram-kompatibilitás visszaesésének észlelése érdekében.

Preemption modellek és PREEMPT_RT javítások alacsony késleltetésű rendszerekhez

A kernel megelőző üzemmódba állítási modellje határozza meg, hogy egy futó feladat mennyire szakítható félbe, hogy egy magasabb prioritású feladat átvehesse az irányítást, ami közvetlenül befolyásolja a válasz késleltetését . Ez magában foglalja mind a standard konfigurációs beállításokat, mind a valós idejű javításokat.

Az általános kernelek számos lehetőséget kínálnak: nincs előzetes engedélyezés (inkább a szerver átviteli sebességére összpontosít), önkéntes előzetes engedélyezés, és egy asztali számítógépekhez való előzetes engedélyezésre alkalmas kernel , amely az interaktív alkalmazások gyors válaszidejét részesíti előnyben. Ennek a beállításnak a módosítása jelentősen javíthatja az asztali rendszerek, az audioalkalmazások vagy akár a régebbi, nagy terhelésű gépek teljesítményét.

Amikor egy lépéssel tovább kell lépni, megjelennek a PREEMPT és a PREEMPT_RT javítások , amelyek a kernel fontos részeit módosítják a nem preemptálható szakaszok minimalizálása érdekében. A PREEMPT_RT olyan rendszerekhez készült, ahol a legrosszabb esetre vonatkozó késleltetésnek (nem csak az átlagosnak) nagyon alacsonynak és kiszámíthatónak kell lennie: ipari automatizálás, professzionális hangtechnika, telekommunikáció vagy nagyfrekvenciás kereskedés.

A PREEMPT_RT bevezetéséről szóló döntést nem trendeken, hanem a késleltetés és a jitter konkrét mérésein kell alapulnia . Először is, tanácsos teljes mértékben megvizsgálni az ütemező beállításait, a CPU-affinitásokat, a sysctl-t és adott esetben a dinamikus ticklesshez hasonló konfigurációkat, mielőtt a karbantartást egy RT-fával bonyolítanánk.

A kompatibilitást is figyelembe kell venni: egyes illesztőprogramok és alrendszerek nincsenek teljesen adaptálva az RT-hez , és speciális verziókra vagy további javításokra lehet szükségük. Az ésszerű megközelítés egy karbantartási terv elkészítése, amely világosan felvázolja, hogy mikor és hogyan kell integrálni a fő kernel új verzióit az RT ággal, amely időszakosan szinkronizálódik, de még mindig némileg le van maradva.

CPU ütemezési hangolás, zavartalan működés és magizoláció

A preempciós modell kiválasztása mellett a CPU-ütemezés és a kernel időzítő viselkedésének módosításával is finomhangolhatja a késleltetést, különösen a vállalati alapú disztribúciókban, mint például az RHEL.

A Red Hat Enterprise Linux 8 például egy alapértelmezett, pulzusmentes kernelt tartalmaz az üresjárati CPU-khoz , amely csökkenti az energiafogyasztást azáltal, hogy elkerüli a periodikus megszakításokat, amikor a kernel tétlen. A késleltetésre érzékeny munkaterhelések esetén egy dinamikus pulzusmentes mód engedélyezhető egy kernelkészleten , így csak egy CPU (a "home kernel") kezeli az időzítési feladatok nagy részét, a többi pedig a lehető legmentesebb a periodikus megszakításoktól.

Ez a konfiguráció a megfelelő paraméterek hozzáadásával történik. a kernel parancssora a GRUB-bana konfiguráció újragenerálása, majd a kritikus kernelszálak, például az RCU-szálak vagy a szálak affinitásának beállítása bdi-flush, így azok a karbantartásra fenntartott magban helyezkednek el.

Ez a megközelítés kiegészíthető az `isolcpus` paraméterrel , amely lehetővé teszi a magok elkülönítését a normál felhasználói térbeli feladatoktól. Alacsony késleltetésű forgatókönyvekben nagyon gyakori, hogy több magot kizárólag egy kritikus alkalmazás számára tartanak fenn, míg a rendszer többi részét (démonok, megszakítások stb.) más magok kezelik.

A dinamikus, ketyegetlen mód működésének ellenőrzéséhez egyszerű teszteket lehet futtatni a következővel: stress vagy olyan szkripteket, amelyek egy másodpercre lefoglalják a CPU-t, és megfigyelik őket időzítő ketyeg számlálók Hogyan csökken a másodpercenkénti megszakítások száma több ezerről egyre az elszigetelt magokban, ami annak a jele, hogy a periodikus időzítő eltűnt.

Memória- és tárhelykezelés, különös tekintettel a késleltetésre

A kernel memória- és lemez I/O-kezelési módja óriási hatással van az alkalmazások által érzékelt késleltetésre , különösen az adatbázisokban és szolgáltatásokban, amelyek sok apró, gyakori műveletet hajtanak végre.

A memória oldalon a vm.swappiness csökkentése minimalizálja a swap-használatot (ami szinte mindig sokkal lassabb, mint a RAM), a vm.vfs_cache_pressure szabályozza, hogy a rendszer milyen gyorsan szabadítsa fel az inode és a dentry gyorsítótárat, a vm.nr_hugepages pedig lehetővé teszi statikus HugePages oldalak lefoglalását nagy terhelésű gépekhez, például adatbázisokhoz vagy JVM-ekhez, csökkentve a TLB terhelését.

A tárolás során válassza ki a megfelelő I/O ütemező a lemez típusának megfelelően Kritikus fontosságú. A modern SSD-ken általában jó ötlet használni... none o mq-deadlineMíg a mechanikus lemezeken és a multitasking rendszerekben a méltányosságra tervezett algoritmusok jobbak lehetnek, mint például BfqEzenkívül a fájlrendszerek csatolása olyan opciókkal, mint például noatime y nodiratime Kerülje a felesleges írásokat minden alkalommal, amikor egy fájlhoz vagy könyvtárhoz hozzáfér.

A fájlrendszereket tekintve az ext4 és az XFS továbbra is a leggyakoribb választások: egy jól hangolt ext4 biztonságos választás, míg az XFS általában jobban skálázódik magas párhuzamosság esetén. Nagyon igényes forgatókönyvek esetén a RAID (RAID 10 adatbázisokhoz, RAID 0 ideiglenes tárolókhoz) és egy jó ütemező kombinálása csökkentheti az átlagos késleltetést és mindenekelőtt a változékonyságot.

Hálózati és kernel optimalizálás az alacsony késleltetés érdekében Linux és EC2 alatt

Nagy teljesítményű hálózati alkalmazásokban a késleltetés nemcsak a hardvertől vagy a távolságtól függ, hanem attól is, hogy a TCP/IP verem és maga a kernel hogyan van konfigurálva . Ez különösen olyan felhőpéldányokban észrevehető, mint az ENA interfészekkel rendelkező Amazon EC2.

Először is, kulcsfontosságú a külső tényezők, például a csomagok által végrehajtott hálózati ugrások számának csökkentése : a közvetlenebb topológiák, a háttérrendszerhez közeli terheléselosztók vagy az optimalizált rendelkezésre állási zónák használata milliszekundumokban csökkenti az utazási időt, mielőtt még az operációs rendszert érintenék.

A kernelen belül a hálózati konfiguráció magában foglalja a fájlleírók növelését (ulimit -n) , a fogadó és küldő pufferek méretezését a net.core.rmem_max, net.core.wmem_max, net.ipv4.tcp_rmem, net.ipv4.tcp_wmem paraméterekkel , valamint olyan opciók engedélyezését, mint a TCP Fast Open, a kapcsolatlétesítési késleltetés csökkentése érdekében.

Az AWS ENA interfészekben a megszakításmoderálás fontos szerepet játszik: alapértelmezés szerint a meghajtóprogram csoportosítja a csomagokat az IRQ-k számának csökkentése érdekében. rx-usecs és tx-usecsHa a késleltetést a lehető legkisebbre szeretné csökkenteni, letilthatja ezt a moderálást a következővel: ethtool -CAz rx-usecs és tx-usecs nullára állítása csökkenti a késleltetést, de növeli a megszakítás többletterhelését, ezért a terheléstől függően kell egyensúlyt találni.

Az irqbalance függvényt használhatod az IRQ-k több mag között történő elosztására is , vagy letilthatod, és manuálisan beállíthatod a megszakítás- és hálózati sor (RSS/RPS) affinitásokat adott magokhoz, ami nagyon gyakori az ultra alacsony késleltetésű környezetekben, vagy DPDK használatakor, és a kernelverem nagy részének kihagyásakor.

Egy másik figyelembe veendő paraméter a CPU C-állapotai : a mély alvó állapotok csökkentik az energiafogyasztást, de késleltetést okoznak, amikor a mag „felébred”. A válaszidő csökkentése érdekében korlátozhatja ezeket a mély állapotokat, elfogadva a magasabb energiafogyasztást és kevesebb mozgásteret a Turbo Boost számára a többi magon. Minden környezetnek megvan a maga optimális tartománya a fogyasztott wattok és a megnövelt mikroszekundumok között.

CPU-, szolgáltatás- és alkalmazásoptimalizálás a késleltetés csökkentése érdekében

Magán a kernelen kívül a környező környezetnek is sokat kell mondania az általános késleltetésről: a rendszeren aktív szolgáltatásoktól kezdve az egyes alkalmazások specifikus konfigurációjáig.

Egy nagy teljesítményű szerver csak a következőt futtathatja: démonok, akikre valóban szükség vanAz olyan szolgáltatások, mint a Bluetooth, a nyomtatás vagy a hálózat automatikus felismerése (CUPS, Avahi stb.) a háttérgépeken csak CPU-t, memóriát és I/O-t fogyasztanak, anélkül, hogy bármilyen hasznot nyújtanának. systemctl list-unit-files --state=enabled A felesleges dolgok letiltása pedig az egyik legolcsóbb és leghatékonyabb dolog, amit tehetsz.

A kritikus folyamatok rangsorolásához olyan eszközöket használhat, mint a renice, a chrt és a taskset . Egy folyamat prioritásának módosítása (renice), valós idejű ütemezés hozzárendelése (chrt -f 99), vagy adott magokhoz való hozzárendelése (taskset) csökkenti a más feladatokkal való interferenciát, javítva a CPU-előrejelezhetőséget adatbázisok, VoIP, streaming vagy kereskedelmi szolgáltatások esetén.

Alkalmazásszinten a finomhangolás ugyanolyan fontos, mint a kernel finomhangolása. Az olyan webszerverek, mint az Nginx vagy az Apache, a workerek, a keepalive, a gyorsítótárak és a tömörítés finomhangolására szorulnak. Az olyan adatbázisok, mint a PostgreSQL vagy a MySQL , a pufferméretek, az ellenőrzőpontok, a kapcsolatkészletek és a szinkron írási paraméterek felülvizsgálatát igénylik az alacsony és stabil késleltetés elérése érdekében.

A JVM is szerepet játszik: a szemétgyűjtők, mint például a G1GC vagy a ZGC, kiválasztása és a heap méretének módosítása csökkentheti a kívülről késleltetésnek tűnő szüneteket. Virtualizált és konténerizált környezetekben a vCPU, a vRAM és az I/O kvóták megfelelő kiosztása megakadályozza a csendes versengést, ami később végtelen lemezsorokként vagy CPU-túlterhelésként jelentkezik.

Kernel- és rendszerfelügyelet és teljesítményértékelés

Mindez a finomhangolás haszontalan, ha nem méred a hatását. A lényeg a folyamatos monitorozás és a reprodukálható teljesítménytesztek kombinációja , hogy a kernel vagy a sysctl minden módosítását objektív adatokkal lehessen értékelni.

A rendszer általános állapotának megtekintéséhez használhat klasszikus eszközöket, mint például htop, vmstat, iotop o sarHa további részletekre van szükséged, akkor specifikus kerneleszközök jönnek képbe, például perf és ftraceamelyek lehetővé teszik az ütemező, a megszakítások és a belső hívások viselkedésének jelentős pontossággal történő nyomon követését.

Éles környezetekben ajánlott olyan metrikarendszereket telepíteni, mint a Prometheus, a collectd vagy a sysstat, olyan exportálókkal , amelyek CPU-számlálókat, I/O-adatokat, lemez- és hálózati késleltetéseket, folyamatsorokat stb. tesznek elérhetővé. Ezen adatok Grafana vagy hasonló eszközökben történő vizualizációja segít a regressziók vagy anomáliák észlelésében, mielőtt a végfelhasználó problémákat észlelne.

A benchmarking esetében az a lényeg, hogy megismételjük a tényleges munkaterhelést, és összehasonlítsuk az egyes változtatások „előtte-utána” állapotát. Az olyan eszközök, mint a sysbench (CPU-hoz és adatbázisokhoz), a fio (lemezhez) vagy az iperf3 (hálózathoz) lehetővé teszik megismételhető forgatókönyvek létrehozását. Alapvető fontosságú a kernel verziók, a sysctl konfigurációk, a hardver és a tesztparaméterek dokumentálása , hogy az összehasonlítások idővel értelmesek legyenek.

A gyakorlatban a Linux kernel optimalizálása egy iteratív folyamat: tesztelünk egy sor módosítást, mérjük az eredményeket, megtartjuk azokat, amelyek valódi előnyöket biztosítanak, és elvetjük a többit. Jó változásirányítással az új kernel verziókban található fejlesztéseket (például az ütemezővel, grafikával, teljesítmény- vagy hálózati fejlesztésekkel ellátott legújabb sorozatokat) mérhető előnyökké alakíthatjuk az alkalmazásaink számára, legyenek azok helyszíni szerverek, felhőalapúak vagy igényes munkaállomások.

A kernel architektúrájának ismerete, a sysctl-lel végzett finomhangolás, az ellenőrzött fordítás, a valós idejű javítások szelektív használata és egy jó metrikarendszer kombinációja lehetővé teszi az adminisztrátor vagy az üzemeltetési csapat számára, hogy gyorsabb válaszokat, alacsonyabb késleltetést és jobb általános stabilitást érjen el anélkül, hogy a legkisebb provokációra is hardvert kellene cserélnie, vagy a rendszer biztonságát veszélyeztetné.