- A sysctl segítségével történő fejlett kernelhangolás lehetővé teszi a hálózat, a memória, a fájlok és az ütemező beállítását a teljesítmény és a stabilitás maximalizálása érdekében.
- Alapvető fontosságú az előtte és utána történő mérés, referenciaértékek és monitorozás segítségével, hogy validáljuk az egyes változtatások valódi hatását.
- Az egyes profilok (web, adatbázisok, alacsony késleltetés, Kubernetes) jobb eredményeket érnek el, mint egyetlen általános konfiguráció.
- Az olyan eszközök, mint a perf, az ftrace, a vmstat és az iostat, iteratív, biztonságos és objektív, adatvezérelt optimalizálást tesznek lehetővé.
Ha már egy ideje Linux szervereket kezelsz, előbb-utóbb rájössz, hogy egy közepes rendszer és egy nagy terhelés alatt is működő rendszer közötti különbség a kernel hangolásában rejlik. Nem csak a több RAM vagy egy erősebb CPU telepítéséről van szó: számos szűk keresztmetszet néhány gondosan megválasztott paraméter módosításával megoldható.
A kernel több száz hálózati, memória-, fájlrendszer- és folyamatütemezési beállítást tesz elérhetővé, amelyek menet közben módosíthatók. Az eszközzel sysctl és néhány kiigazítás /procLehetséges a hardverből a legtöbbet kihozni és elérni alacsonyabb késleltetés, nagyobb átviteli sebesség és jobb stabilitás Ez vonatkozik a webszerverekre és adatbázisokra, valamint a valós idejű környezetekre és a Kubernetesre. Azonban elengedhetetlen, hogy pontosan tudd, mit csinálsz, és hogyan méred azt.
Mi a sysctl és hogyan rendszerezi a kernel paramétereket?
Hasznosság sysctl Ez a kapu a kernel paramétereinek módosításához újrafordítás vagy újraindítás nélkül, lehetővé téve értékek olvasása és módosítása futásidejű a konfigurációk azonnali teszteléséhez. Ezek a paraméterek alacsony hierarchikus fában vannak rendezve /proc/sys/és mindegyik a rendszer egy adott viselkedését szabályozza.
A beállítások különálló kategóriákba vannak csoportosítva, így könnyen meghatározható, hogy mit kell módosítani, ha egy adott teljesítmény- vagy stabilitási problémát tapasztal. Ez a struktúra lehetővé teszi, hogy például kizárólag a hálózatra (net.*), a memóriára (vm.*) vagy a fájlrendszerre (fs.*) koncentráljon anélkül, hogy elveszne a kernel többi beállításában.
A főbb kategóriák, amelyeket itt találsz /proc/sys/ Ezek többek között a következők:
- kernel.*: általános kernelbeállítások (ütemező, PID, üzenetek, NUMA stb.).
- vm.*: virtuális memóriakezelés, swap, gyorsítótárak és túlteljesítési szabályzatok.
- nettó.*IPv4/IPv6 hálózati verem, TCP/UDP pufferek, sorok, torlódásvezérlés.
- fs.*: a leírók, inode-ok, inotify, AIO és VFS viselkedés korlátai.
- fejl.*: bizonyos eszközök és illesztőprogramok specifikus paraméterei.
Con sysctl -a Felsorolhatja az összes elérhető paramétert, és olyan parancsokkal, mint a sysctl vm.swappiness o sysctl net.ipv4.tcp_tw_reuse konkrét értékek olvasása, ami kulcsfontosságú az aktuális konfiguráció auditálása mielőtt bármit is megváltoztatna. Valami konkrét megtalálásához gyakori a szűrés a következővel: grepPéldául: sysctl -a | grep tcp.
Egy paraméter menet közbeni módosítása olyan egyszerű, mint a használata sysctl -w clave=valorFontos azonban megérteni, hogy ezek a változtatások átmenetiek. Az újraindítás utáni mentésükhöz elengedhetetlen a konfiguráció biztonsági mentése a következőre: /etc/sysctl.conf vagy a következő fájlokban: /etc/sysctl.d/, általában számozott fájlok használatával (például 10-network.conf, 20-memory.conf, 99-custom.conf), amelyek meghatározzák alkalmazásuk sorrendjét.
Érintés előtt mérj: referenciaértékek és rendszeralapértékek
Mielőtt elkezdenél babrálni a tárcsákkal, bölcs dolog meghatározni egy objektív teljesítményalapértéket . Előzetes adatok nélkül lehetetlen tudni, hogy a változtatások javították vagy rontották-e a rendszert, és a klasszikus „nekem jobbnak tűnik” csapdába esel, ami haszontalan a megalapozott döntések meghozatalához.
Rendszerszinten érdemes néhány percig, reprezentatív terhelés mellett gyűjteni a CPU-, terhelési, memória-, lemez- és hálózati statisztikákat. Ilyen eszközök például a uptime, mpstat, vmstat, iostat -x o sar -n DEV Lehetővé teszik, hogy lásd, hogyan viselkedik a gyári kernel, mennyi swap memóriát használ, hogyan reagál a lemez I/O, és hogy a hálózat telített-e vagy pazarolja-e a sávszélességet.
Ezen áttekintés mellett kulcsfontosságú az optimalizálni kívánt alkalmazáshoz tartozó konkrét benchmarkok futtatása is. Webszervereken használhatja a következőt: ab (Apache Bench) vagy hasonló mérési eszközök másodpercenkénti kérések, átlagos késleltetés és hibákAz adatbázisokban olyan segédprogramok, mint például mysqlslap o sysbench Segítenek kiértékelni a másodpercenkénti tranzakciók számát és a lekérdezési időket.
Például egy finomhangolás nélküli forgatókönyvben gyakoriak az olyan adatok, mint az 500 HTTP kérés/s 200 ms átlagos válaszidővel, körülbelül 250 SQL lekérdezés/s 40 ms késleltetéssel, körülbelül 500 Mbps hálózati sebesség, és a rendszerterhelés a maximális terhelés alatt. Ezeket a számokat fogják felhasználni a kernelmódosítások alkalmazása után annak ellenőrzésére, hogy valóban megvalósul-e az átviteli sebesség mérhető növekedése és a késleltetés csökkenése.
Végül dokumentálja a parancsokat és az eredményeket, mielőtt bármilyen változtatást végezne. Az előzmények birtoklása lehetővé teszi a különböző módosítási kötegek pontos összehasonlítását, és segít a regressziók észlelésében egy kernelfrissítés vagy egy új sysctl profil éles környezetben történő bevezetése után.
Speciális memóriabeállítások: vm.*
A memória az egyik olyan alrendszer, ahol a kernel változásai a leginkább észrevehetők. Egy sok RAM-mal rendelkező, de rosszul konfigurált szerver szükségtelenül használhatja a swap területet, ami... I/O csúcsok és drasztikus teljesítménycsökkenésekEzért olyan paraméterek, mint az vm.swappinessA piszkos oldalak aránya vagy a VFS gyorsítótár viselkedése ugyanolyan fontos.
Paraméter vm.swappiness Ez szabályozza, hogy a kernel mennyi memórialapot küld a swapolásba. Sok disztribúcióban 60-ra van állítva, ez az érték vegyes asztali környezetekhez készült. Adatbázis-kiszolgálók vagy alacsony késleltetésű alkalmazások esetén általában célszerűbb 10-re vagy akár kevesebbre csökkenteni, ami hatékonyabb rendszert eredményez. az adatok RAM-ban való tárolásának előtérbe helyezése és a swappal-ok számának csökkentéseNem ritka, hogy a lemezforgalom zuhanórepülésben van, és az alkalmazások sokkal kevesebb jitterrel reagálnak a beállítás után.
Egy másik alapvető építőelem az vm.dirty_ratio y vm.dirty_background_ratioEzek az értékek határozzák meg, hogy a memória hány százalékát lehet feltölteni piszkos lapokkal, mielőtt a kernel elkezdené azokat lemezre írni. A túlzottan magas értékek nagy írási löketekhez vezethetnek, hatalmas késleltetéssel minden alkalmazás számára, amikor az ürítés megtörténik. Ha ezeket a százalékokat 15-re, illetve 5-re csökkentjük, az jellemzően a következő eredményt adja: konzisztensebb és kiszámíthatóbb I/O minta.
A beállítás vm.vfs_cache_pressure Ez határozza meg, hogy a kernel milyen agresszíven törli az inode és a könyvtár gyorsítótárait. Az alapértelmezett 100-as érték általában gyorsabban törli a gyorsítótárat, míg az 50 körüli beállítások lehetővé teszik a metaadatok hosszabb megőrzését, növelve a fájlműveletek találati arányát és javítva a teljesítményt. a fájlrendszer érzékelt teljesítménye, ami kulcsfontosságú a több millió apró fájlt kezelő szervereken.
A maga részéről vm.min_free_kbytes Foglaljon le egy minimális szabad memóriamennyiséget, hogy a rendszer képes legyen reagálni a lefoglalási löketekre anélkül, hogy hirtelen, a gyári állapotból kiinduló helyzetekbe kerülne. Ennek a teljes RAM körülbelül 0,5%-1%-ára való méretezése általában hatékony biztonsági intézkedés annak megakadályozására, hogy a kernel extrém terhelés alatt kifogyjon a tárhelyből, és elkezdje leállítani a kritikus folyamatokat, ezáltal javítva a teljesítményt. általános gazdastabilitás.
Végül a túllépési politikára is érdemes odafigyelni: olyan paraméterekre, mint vm.overcommit_memory y vm.overcommit_ratio Ezek határozzák meg, hogy a folyamatoknak mennyi virtuális memóriát kell lefoglalni a rendelkezésre álló RAM-hoz és swap-hoz képest. Bizonyos esetekben (például Redis vagy bizonyos adatbázisok esetén) az agresszív túlterhelés megengedett, míg más esetekben egy konzervatívabb szabályzatot részesítenek előnyben a kockázat korlátozása érdekében. OOM és a túlzottan sérült memória helyzeteiAz összetett esetek elemzésének és diagnosztizálásának technikáiért forduljon memória hibakeresés Linuxban.
Speciális hálózatoptimalizálás: net.* és TCP/IP
A hálózati verem talán az a terület, ahol a finomhangolás a legszembetűnőbb az éles környezetekben. A csatlakozási sorok vagy pufferek egyszerű megváltoztatása jelentheti a különbséget egy 500 Mbps-nál lefulladt szerver és egy olyan között, amelyik... Könnyen telíti a gigabitet.A paraméterek alatt net.core.* y net.ipv4.* Ezen a téren ők a legjobb szövetségeseid.
Először is, a socket puffer mérete közvetlenül befolyásolja egy kapcsolat maximális átviteli sebességét, különösen nagy késleltetés vagy nagy kapacitású kapcsolatok esetén. net.core.rmem_max y net.core.wmem_max nagylelkű értékekre (több tíz vagy több száz megabájt) és helyesen definiálja net.ipv4.tcp_rmem y net.ipv4.tcp_wmem (minimum, alapértelmezett érték és maximum) lehetővé teszi, hogy minden socket a következő legyen: a forgalmi lökések tompításához szükséges hely anélkül, hogy a nagyon konzervatív gyári értékek által előírt mesterséges korlátozásokba esne.
Egy másik kulcsfontosságú szempont a csatlakozási sorok mérete. Olyan paraméterek, mint a net.core.somaxconn, net.core.netdev_max_backlog y net.ipv4.tcp_max_syn_backlog Ezek a korlátok határozzák meg, hogy a rendszer hány függőben lévő kapcsolatot képes kezelni, mielőtt eldobná a csomagokat vagy elutasítaná a kézfogásokat. Nagy forgalmú webszervereken ezen korlátok növelése megakadályozhatja a telített sorokat és drasztikusan csökkentheti a terhelést. csatlakozási hibák csúcsterhelés alatt.
A TCP-kapcsolatok viselkedése számos opcióval finomhangolható: engedélyezés net.ipv4.tcp_window_scaling Nagy sávszélességű kapcsolatokon a nagy ablakok támogatásához engedélyezze a net.ipv4.tcp_sack y net.ipv4.tcp_timestamps a veszteség- és újraküldéskezelés javítása, vagy a net.ipv4.tcp_fin_timeout és a menedzsment TIME_WAIT (net.ipv4.tcp_tw_reuse, net.ipv4.tcp_max_tw_buckets) a szerverek erőforrás-fogyasztásának szabályozása érdekében percenként több millió rövid kapcsolat.
A torlódásvezérlési algoritmus megválasztása is számít. Bár cubic Sok disztribúcióban ez marad az alapértelmezett érték; erre változik bbr a modern kernelekben (4.9 és újabb verziók) net.ipv4.tcp_congestion_control y net.core.default_qdisc=fq Komplex veszteségekkel vagy késleltetésekkel járó környezetekben a TCP átviteli sebességét sokszorozhatja meg, bizonyos esetekben a klasszikus konfigurációkhoz képest 2-25-szörös javulást érve el, a következők rovására: némileg eltérő viselkedés túlterhelt hálózatokban.
Nem szabad megfeledkeznünk olyan biztonsági és megbízhatósági paraméterekről, mint net.ipv4.tcp_syncookies, az átirányítások kezelése (net.ipv4.conf.all.accept_redirects, send_redirects) vagy hidakban történő szűrés (net.bridge.bridge-nf-call-iptables Kubernetes környezetekben). Megfelelő konfigurálásuk lehetővé teszi a rendszer védelmét a gyakori támadásokkal szemben (SYN-elárasztás, hamisítás stb.) anélkül, hogy feláldozná a stabil hálózati teljesítményA szabályokkal és az észleléssel kapcsolatos gyakorlati útmutatóért tekintse meg a következőt: Netfilter és Suricata megvalósítása.
Fájlrendszer, leírók és globális korlátok: fs.* és ulimit
A modern szervereken az alacsony fájlleíró korlát a leggyorsabb módja a rendszer feltörésének csúcsidőben. Amikor egy webszerver, fordított proxy vagy adatbázis a klasszikus „túl sok nyitott fájl” hibát tapasztalja, az általában azért van, mert a kernel paraméterek és a felhasználói korlátok nem voltak méretezve a tényleges terheléshez.
Globális szinten, fs.file-max Ez határozza meg, hogy a kernel összesen hány leírót tarthat nyitva. Több ezer egyidejű kapcsolattal rendelkező alkalmazások esetén gyakori, hogy ezt az értéket több millióra növelik, valamint a következő növekedést is. fs.nr_openamely meghatározza a folyamatokonkénti leírók kemény felső határát. Ezenkívül kiigazításokra van szükség. /etc/security/limits.conf hogy a felhasználók (vagy a systemd által kezelt szolgáltatások) a kernel konfigurációjával összhangban lévő soft és hard értékek.
Az inotify alrendszert, amelyet széles körben használnak az IDE-k, webfejlesztő eszközök és fájlfigyelő rendszerek, olyan paraméterek vezérlik, mint a fs.inotify.max_user_watches y fs.inotify.max_user_instancesHa olyan hibákat tapasztal, amelyek a lemezváltozások figyelését leállító figyelőkkel vagy folyamatokkal kapcsolatosak, akkor valószínűleg szüksége van rájuk Növelje ezeket a korlátokat a csendes szűk keresztmetszetek elkerülése érdekében.
Egy másik fontos jellemző az aszinkron I/O (AIO), amelynek globális maximumát a következő határozza meg: fs.aio-max-nrAz aszinkron I/O-ra nagymértékben támaszkodó alkalmazásokban (bizonyos adatbázismotorok, sorkezelő rendszerek stb.), a növelése megakadályozza, hogy a kernel kifogyjon a helyekből az AIO-műveletekhez hatalmas kérésterhelés esetén.
Ezen paraméterek mellett a lemez alrendszer teljesítményét a következők is befolyásolják: I/O ütemező minden blokkeszközön konfigurálva. SSD-ket vagy NVMe-t tartalmazó rendszerekben általában könnyűsúlyú ütemezők használata ajánlott, mint például none o mq-deadline, míg mechanikus lemezek esetén más lehetőségek is hasznosak lehetnek, például bfq a terhelés típusától függően. Állítsa be az ütemezőt a /sys/block/<disco>/queue/scheduler és finomhangolja a beállításokat, például a várólista mélységét (nr_requests) vagy a read_ahead_kb érezhető különbséget hozhat olvasási/írási késleltetés és átviteli sebességFontos figyelembe venni azt is, hogy milyen fájlrendszereket és illesztőprogramokat használnak; például cikkek a következőkről: NTFSplus Linuxon és más rendszerek segíthetnek a heterogén terhelések tervezésében.
Végül nem szabad elfelejteni, hogy ezeknek a kernelkorlátoknak kéz a kézben kell járniuk a rendszerkonfigurációkkal, mint például a ulimit és a systemd egységeket, hogy biztosítsák, hogy a szolgáltatások ténylegesen használhassák a meghatározott további erőforrásokat, és ne legyenek blokkolva korlátozások a felső rétegekben.
Kernel általános, NUMA, CPU affinitás és hatalmas oldalak
A hálózatépítésen, a memórián és a fájlrendszereken túl maga a kernel számos hangolási lehetőséget kínál, amelyek befolyásolják a folyamatok ütemezését, a munkaterhelések elosztását a magok és a NUMA csomópontok között, valamint a memória nagy léptékű kezelését. A modern, sok maggal és akár több foglalattal rendelkező gépeken ezek a részletek gyakran jelentik a különbséget egy kiegyensúlyozott szerver és egy olyan között, amelyben egyes magok telítettek, míg mások alulhasznosítottak . Érdemes alternatív kerneleket is megvizsgálni, mint például a Liquorix kernelt olyan környezetekben, ahol eltérő késleltetési profilra van szükség.
Paraméterek, mint például kernel.pid_max Ezek határozzák meg a rendszer által hozzárendelhető folyamatazonosítók maximális tartományát, ami nagyszámú konténert vagy rövid távú folyamatot futtató csomópontok esetében releváns. A kernel naplózási beállításainak módosítása (kernel.printk) segít csökkenteni a túlzott zajt a dmesg-ben, miközben továbbra is rögzíti a kritikus eseményeket, ami közvetve szintén befolyásolja a diagnosztikai képesség és stabilitás.
A memória topológiát illetően a paraméter kernel.numa_balancing Ez szabályozza, hogy a kernel milyen mértékben mozgatja automatikusan az oldalakat a NUMA csomópontok között. Bizonyos környezetekben a letiltása lehetővé teszi a folyamatok és a memória affinitásának explicitebb kezelését olyan eszközök használatával, mint a numactl annak biztosítása érdekében, hogy a CPU- és RAM-igényes folyamatok ugyanazon a csomóponton maradjanak, csökkentve a távoli hozzáférésből eredő késleltetésA hardver és a központi ütemezés közötti kölcsönhatás jobb megértése érdekében hasznos áttekinteni az olyan technológiákat is, mint például Intel szál igazgató.
A hatalmas oldalak (vm.nr_hugepagesEzek egy másik kulcsfontosságú összetevői az adatbázis-rendszereknek vagy más olyan munkaterheléseknek, amelyek nagy, összefüggő memóriaterületeket kezelnek. Megfelelő számú óriáslap (2 MB vagy akár 1 GB, az architektúrától függően) lefoglalása csökkentheti a TLB terhelését, és jelentősen javíthatja a futó alkalmazások teljesítményét. sok művelet nagy memóriablokkokonAhhoz, hogy ez hatékony legyen, a kernel konfigurációját össze kell hangolni magával az alkalmazással, hogy az explicit módon használja ezt a memóriát.
A késleltetés és az ütemezés területén vannak ütemező paraméterek, mint például kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns o kernel.sched_migration_cost_nsEzek a beállítások finomhangolják az egyes feladatokhoz rendelt CPU-"chunkok" méretét, valamint azt az agresszivitást, amellyel a kernel a folyamatokat a magok között mozgatja. A kisebb értékek egy preemptívebb rendszert jelentenek, amely általában... legjobb válasz interaktív feladatokra néha egy kis nyers áteresztőképesség árán.
Azokban a rendszerekben, ahol a memória érzékeny erőforrás, egyes rendszergazdák úgy döntenek, hogy aktiválják a pánik módot gyári hiba esetén (vm.panic_on_oom) és létrehozza kernel.panic automatikus újraindítási idővel. Ez a stratégia, bár némileg drasztikus, hasznos lehet nagy rendelkezésre állású környezetekben, ahol Egy gyors és kontrollált újraindítás előnyösebb, mint egy lefagyott és instabil gazdagép. órákon át.
Specializált profilok: web, adatbázisok, alacsony késleltetés és Kubernetes
Egyetlen varázsszer alkalmazása helyett hatékonyabb a különböző típusú munkaterhelésekhez – webszerverekhez, adatbázisokhoz, konténerplatformokhoz vagy alacsony késleltetésű rendszerekhez – igazított sysctl profilokat létrehozni. Ezeket a beállításokat olyan fájlokban terjesztheti, mint például a 99-webserver.conf, 99-database.conf o 90-kubernetes.conf segítsen szervezett és könnyen verziózható konfiguráció fenntartásaFontolóra veheted a teljesítményorientált disztribúciókat és kiadásokat is, mint például CachyOS szerver kiadás nagyon specifikus környezetekhez.
Webszerverek (Nginx, Apache, proxyk stb.) esetében a lényeg a nagyszámú, egyidejű kapcsolat kezelése hosszú várakozási időkkel és válaszidővel. FIN_WAIT A finomhangolással, a kibővített efemer porttartománnyal és a nagyon magas leírókorlátokkal gyakori, hogy másodpercenként néhány száz HTTP-kérésről több ezerre emelkedik a kérések száma, ami csökkenti az átlagos késleltetést és kiküszöböli a hibákat. telített sorok vagy megtelt portok.
Az adatbázis oldalon (MySQL, PostgreSQL és hasonlók) prioritást élvez a minimális swap-használat, a dirty page írás finomhangolása, valamint a motor megfelelő megosztott memória- és szemaforbeállításai. Az olyan paraméterek, mint a kernel.shmmax, kernel.shmall, kernel.sem és a hatalmas oldalkonfiguráció nagyban befolyásolja másodpercenkénti tranzakciók és válaszidő, sok esetben a teljesítményt kétszer vagy háromszor szorozva az alapértelmezett értékekhez képest.
Rendkívül alacsony késleltetésű alkalmazásokhoz (kereskedés, online játékok, valós idejű feldolgozás) még specifikusabb beállításokat adnak hozzá: net.ipv4.tcp_low_latency, a lassú indítás kikapcsolása inaktivitás után, a használata tcp_fastopen, foglalt lekérdezési paraméterek (net.core.busy_poll, busy_read) és sok esetben az átlátszó hatalmas oldalak deaktiválása által /sys/kernel/mm/transparent_hugepage/enabledMindez a cél, hogy csökkentse a a feldolgozási sor és a késleltetés a magas percentilisekben csúcsosodik ki, látványos fejlesztéseket elérve a P99-ben.
Konténer- és Kubernetes-környezetekben a hálózati verem és a kapcsolatok követése különösen nagy terhelés alatt áll. Az olyan paraméterek, mint a net.ipv4.ip_forward, net.bridge.bridge-nf-call-iptables, net.netfilter.nf_conntrack_maxA NodePort számára fenntartott portok használata vagy az ARP-táblázatok módosítása gyakori a több száz vagy több ezer podot kezelő csomópontokban. Ezek megfelelő beállítása megelőzi a problémákat. csonkolt kapcsolatok, időtúllépések vagy táblatelítettség a conntrack segítségével.
Ezen specifikus profilokon kívül egyes szervezetek a teljesítményre összpontosító, fokozott biztonságú archívumot választanak, amely a nagy hálózati puffereket és a csökkentett swappinitást olyan intézkedésekkel ötvözi, mint például tcp_syncookies vagy a veszélyes átirányítások blokkolása. A cél egy egyensúlypont az agresszív teljesítmény és az ésszerű keményedés között.
Kernelprofilozó és monitorozó eszközök
A kernel mérés nélküli beállítása olyan, mintha bekötött szemmel játszanánk egy hangkeverőn. A Linux eszközök arzenálját kínálja a rendszer tényleges működésének megértéséhez, az egyszerű számlálóktól a kernelfüggvények részletes nyomon követéséig, lehetővé téve a konfigurációs változtatások mérhető hatásokkal való összefüggésbe hozását.
A mindennapi közművek közé tartoznak a következők: vmstat, iostat, sar, ss, slabtop, htop o pidstatamelyek gyors információkat nyújtanak a folyamatokról, a CPU-ról, az I/O-ról, a socketekről és a gyorsítótár használatáról. A Prometheusba, Grafanába vagy a collectd-be exportált rendszernaplókkal és metrikák, valamint olyan erőforrások kombinációjával kombinálva, mint például fejlett rendszerfigyelő LinuxhozMeglehetősen teljes képet adnak arról, hogyan viselkedik a házigazda az egyes hangolások előtt és után.
Hogy részletesebben is kifejtsük, olyan eszközök, mint perf Lehetővé teszik a CPU-használat profilalkotását függvényszinten, mind felhasználói, mind kernel szinten, események naplózását néhány másodpercig vagy percig, majd interaktív jelentést készítenek. perf stat, perf record y perf report láthatod hol fogy valójában a CPU-idő, és melyik rész felel meg a magnak, például egy megszakítási vihart vagy egy rosszul beállított ütemezőt azonosítva.
Ha még nagyobb részletességre van szüksége, ftrace A kernel nyomkövető alrendszere lehetővé teszi bizonyos nyomkövetők (például a tracer függvény) aktiválását, és valós időben vagy utólagos vizsgálatát, hogy milyen hívások történnek. A megfelelő nyomkövető engedélyezése és tartalmának elemzése /sys/kernel/debug/tracing/trace felfedi neked a kernelen belüli hotspotokEz nagyon hasznos, ha a magas szintű mérőszámok nem elegendőek.
Ezzel párhuzamosan célszerű automatizált monitorozó szkripteket bevezetni, amelyek rendszeresen rögzítik a kulcsfontosságú adatokat (hálózati statisztikák, memóriaszámlálók, a megnyitott fájlleírók száma stb.) forgó naplókba. Bizonyos küszöbértékek elérése után (például a megnyitott fájlleírók száma meghalad egy meghatározott értéket) ezek a szkriptek riasztásokat generálhatnak e-mailben vagy más csatornákon keresztül, segítve a veszélyes trendek észlelését, mielőtt a probléma eszkalálódna.
Végül, a hosszabb stressztesztelési fázisokban (24 óra vagy több), olyan eszközök, mint a stress-ng a mérőszámok folyamatos gyűjtésével kombinálva (a vmstat, iostat, sar) lehetővé teszik a rendszer stabilitásának felmérését az új kernelkonfigurációval, ellenőrizve, hogy nincsenek-e OOM események, összeomlások, váratlan újraindítások vagy fokozatos teljesítményromlások tartós terhelés alatt.
A Linux kernel optimalizálása a sysctl és más mechanizmusok segítségével nem egyszeri feladat, hanem egy iteratív folyamat, amely magában foglalja az eredmények mérését, a paraméterek módosítását és mindent aprólékosan dokumentál. Egyértelmű módszertannal, az egyes munkaterhelés-típusokhoz tartozó specifikus profilokkal, a profilkészítő eszközök robusztus készletével és a szigorú változáskezeléssel olyan szerverek érhetők el, amelyek teljes mértékben kihasználják a hardverüket, megnövelt átviteli sebességgel, csökkentett késleltetéssel és jelentősen nagyobb stabilitással, mint az általános gyári konfiguráció.
