Milleks Linuxis IRQbalance'i kasutatakse ja kuidas see sobib edasijõudnutele optimeerimisse?

Kui hakkate GNU/Linuxi süsteemi jõudluse kallal nokitsema, ilmub varem või hiljem korduv peategelane: irqbalance ja riistvaraliste katkestuste jaotus protsessorite vahelSellest räägitakse foorumites, levitamise dokumentatsioonis ja õpetustes süsteemi "häälestamise" kohta, et see lendama hakkaks... aga harva selgitatakse hästi, mida see tegelikult teeb, millistes stsenaariumides see kaasa aitab ja millistes olukordades sa midagi ei märka.

Lisaks kõigele sellele, IRQ tasakaalustamine See läheb sassi teiste edasijõudnute kontseptsioonidega: NAPI, kerneli vastuvõtujärjekorrad, võrgukaardi puhvrid, TCP ummikute juhtimise algoritmid, RSS/RPS, BBR, sysctl seaded, jõudlusdeemonid nagu eellaadimine, zram-tihendatud swap, GTK optimeerimine, ajutised failid RAM-is jne. Parameetrite seas on väga lihtne ära eksida. käsud ja konfiguratsioonifailid ilma selge arusaamata iga asja funktsioonist.

Mis on IRQbalance ja milleks seda Linuxis tegelikult kasutatakse?

irqbalance on kasutajaruumi deemon, mis vastutab riistvarakatkestuste (IRQ-de) jaotamise eest erinevate protsessori tuumade vahel. SMP (mitmeprotsessorilistes või mitmetuumalistes) süsteemides. Selle eesmärk ei ole maagiline: see lihtsalt püüab takistada kogu teenindavate seadmete (võrgu, ketaste, USBjne) langeb alati samale tuumale.

Kui seade genereerib IRQ, käivitab kernel katkestuste käitleja. Kui paljud neist katkestustest on koondunud ühele protsessorile, võib see protsessor ülekoormatud olla, samal ajal kui teised jäävad jõudeolekusse. irqbalance analüüsib katkestuste mahtu seadme kohta ja määrab igale IRQ-le koormuse jaotamiseks "sobiva" tuuma., püüdes samal ajal minimeerida vahemälu kadusid ja austada loogilisi seoseid (näiteks hoides sama võrguliidese IRQ-d seotuna).

Süsteemides koos üks protsessor või tuumad, mis jagavad täielikult L2 vahemäluirqbalance tuvastab ise, et tal pole midagi kasulikku teha ja sulgub. See ei ole viga; lihtsalt pole ruumi paremaks muutmiseks. Mitme füüsilise protsessori või paljude tuumadega serverites, eriti suure võrguliikluse või suure sisend-/väljundmahu korral, võib see aga latentsust ja stabiilsust mõjutada.

Deemon saab töötada taustal (teenindusrežiimis) või vastavalt vajadusele valikuga –üks lask. Samuti võimaldab teatud IRQ-sid välistada valiku järgi --banirq ja takistada sellel teatud tuumade kasutamist keskkonnamuutujas määratletud protsessori maskiga IRQBALANCE_BANNED_CPUSKõike seda juhitakse tavaliselt teie konfiguratsioonifailist, mis paljudes distributsioonides asub kaustas /etc/default/irqbalance o /etc/irqbalance.env.

IRQ tasakaalustamine: kernel vs irqbalance ja millal see on märgatav

Linuxil on juba oma sisemine mehhanism, mis otsustab, milline protsessor iga IRQ-d teenindab, ilma et oleks vaja irqbalance'i. Kernel saab määrata katkestuste afiinsused ja jaotada need lihtsate heuristikameetodite abil.Ja paljudel lauaarvutitel on sellest enam kui küll: keskmine kasutaja ei märka irqbalance'i sisse- või väljalülitamisel mingit vahet.

Seepärast on suhteliselt tavaline, et keegi proovib oma töölaua distributsioonis irqbalance'i ja ütleb: "Ma ei märka mingit paranemist, aga midagi halba ka mitte."See on täiesti normaalne. Neljatuumalise protsessori ja ühe võrgukaardiga sülearvutil, millel pole suurt sisend-/väljundkoormust, hoiavad Linuxi ajastaja ja sisemised kerneli mehhanismid (NAPI, võrgujärjekorrad jne) asjad juba mõistlikult tasakaalus.

Kus see mõtet omab, on see mitme südamikuga ja intensiivse liiklusega serverid: andmebaasid suured pöördproksid, suure liiklusega veebiserverid, ladustamine varukoopiatest, tugevalt koormatud virtuaalmasinadjne. Paljude võrgu- või ketta-IRQ-de ühele tuumale kinnitamine võib muutuda pudelikaelaks. Nende õige jaotamine vähendab järjekordi, teenindusaegu ja latentsusaja pikenemist.

Mõned kasutajad eelistavad irqbalance'i asemel kasutada irqbalance'i parameetriseerige kernel selliste valikutega nagu acpi_irq_balance GRUBis. See parameeter mõjutab seda, kuidas ACPI ja kernel IRQ-sid eraldavad, kuid see ei paku sama dünaamilist paindlikkust kui irqbalance, mis hindab jaotust ümber tegeliku koormuse põhjal. Need on erinevad lähenemisviisid: esimene on staatilisem ja madala tasemega; teine ​​adaptiivsem.

Ülimadala latentsusega keskkondades (näiteks teatud kauplemisplatvormidel või DPDK-ga võrkudes) toimub vastupidine: irqbalance on tavaliselt keelatud ja IRQ-d määratakse käsitsi konkreetsetele tuumadele.koos hoolika kaardistamisega võrgukaardi järjekordade ja protsessorite vahel. Sellistel juhtudel taotletakse absoluutset kontrolli ja ohverdatakse osa automatiseerimisest.

Katkestused, NAPI ja võrgujärjekorrad: kuidas IRQbalance sobib

Irqbalance'i rolli paremaks mõistmiseks peame minema järgmisele tasemele ja vaatama, kuidas Linux nendega toime tuleb. võrgukatkestused ja pakettide vastuvõttKerneli võrgu alamsüsteem ühendab endas mitu põhikomponenti: NAPI, vastuvõtujärjekorrad (DMA puhver), parameetrid net.core.*, järjekorrahaldusalgoritmid (qdisc) ja külgmine skaleerimine (RSS/RPS).

NAPI (uus API) See on mehhanism, mille abil kernel vähendab katkestuste tormi suure liikluse saabumisel. Iga paketi jaoks IRQ käivitamise asemel genereerib võrgukaart katkestuse, mis näitab, et "töö on pooleli", ja kernel sond Vastuvõtujärjekorda töödeldakse seni, kuni see on tühi või aja-/paketieelarve on ammendunud. See vähendab värinat ja parandab jõudlust, kuigi see võib kaasa tuua ka teatud latentsusaja kõikumisi.

Järjekorda, kuhu paketid enne võrgupinu poolt töötlemist maanduvad, nimetatakse tavaliselt järjekorraks kerneli vastuvõtujärjekord või DMA puhverSelle mahtuvust piiravad sellised parameetrid nagu:

• net.core.netdev_max_backlog: tarkvara vastuvõtujärjekorras olevate pakettide maksimaalne arv, mille puhul kernel ei suuda neid saabumiskiirusega töödelda.
• net.core.netdev_budget_usecs: aja „eelarve” mikrosekundites, mille NAPI peab igas tsüklis järjekordade tühjendamiseks kulutama.
• net.core.dev_weight: iga eelarve piires igas voorus liidese kohta töödeldud pakettide arv.

Si netdev_max_backlog on väga madal ja võrgukaart saadab rohkem pakette, kui kernel suudab käsitleda, hakkame nägema "katkestatud pakette" /proc/net/softnet_statTüüpiline alguspunkt suure liiklusega serverite peenhäälestamiseks on vahemikus 4000 pakki, konfigureeritud /etc/sysctl.conf millegi sellisega:

net.core.netdev_max_backlog = 4000

Pärast selle muutmist rakendatakse seda koos sysctl -p või a-ga sysctl -w täpne. Sel viisil saba neelab saabumispiike paremini pakette kaotamata, kui ülejäänud töötlemistee vastu peab.

Selle vooluringi vältel otsustab irqbalance, milline protsessor haldab võrguliidesega seotud IRQ-sid. Kui koondada kõik võrgukaardi katkestused ühele tuumale, siis see tuum käivitab NAPI rutiinid ja tühjendab järjekorra ise.Kui jaotame IRQ-d õigesti ja kasutame selliseid mehhanisme nagu RSS või RPS, saavad mitu protsessorit pakettide töötlemisel koostööd teha, vähendades järjekordi ja kadusid.

Tiheda liikluse jaoks järjekordade, puhvrite ja TCP akna peenhäälestamine

Kui server liigutab palju andmeid (näiteks varukoopiaid, FTP-liiklust, suuri faile või replikeeritud andmebaase), ei piisa ainult "irqbalance'i lubamisest". Ühtlustada tuleb mitu tasandit: kerneli järjekorrad, kaardi puhvrid, TCP akna suurused ja ülekoormuse parameetrid.nii et kõik sõudsid samas suunas.

Esimene reguleerimisplokk asub pakettide vastuvõtupuhver ja TCP akenLinux pakub selliseid parameetreid nagu:

• net.ipv4.tcp_rmem: TCP vastuvõtumälu triplett (miinimum, vaikeväärtus, maksimum) sokli kohta.
• net.ipv4.tcp_wmem: samaväärne laevandusega.
• net.core.rmem_max y net.core.wmem_max: maksimaalne kõva puhver, mida rakendus saab taotleda.

Praktiline viis nende madala latentsusega gigabitiühenduse jaoks kohandamiseks on arvutada BDP (ribalaiuse ja viivituse korrutis) ja rakendage skaleerimistegurit (tänu valikule TCP akna skaleerimine(vaikimisi lubatud enamikus tänapäevastes kernelites). Praktikas saavad paljud administraatorid tulemuseks mitu megabaiti suurused maksimaalsed väärtused, näiteks:

net.ipv4.tcp_rmem = 4096 16384 10880000
net.ipv4.tcp_wmem = 4096 16384 10880000

See maksimaalne ~ 10,8 MB See tuleneb spetsiifilistest arvutustest 1 Gbps linkide jaoks, millel on väga madal RTT (~0,00017 s). Mida suurem on läbilaskevõime või latentsus, seda suurem peab olema puhver, et ribalaiust ära kasutada ilma akna piiranguteta.

Oluline on seostada see maksimum pakettide vastuvõtujärjekorra suurusega. Kui netdev_max_backlog = 4000 ja iga efektiivne pakett on umbes 1480 baiti, moodustab see järjekord umbes ~5,9 MB. TCP aknapuhver peab olema suurem kui järjekorda mahuv mahtvõi kaotame pakette, küllastades puhvri enne järjekorda.

Kahjude jälgimiseksKasutada saab selliseid käske nagu järgmised:

• cat /sys/class/net/eth0/statistics/rx_dropped: võrgukaardis kaduma läinud paketid.
• watch -n 1 -t -d cat /proc/net/softnet_stat: töödeldud veerud, eemaldatud veerud, ajaliselt piiratud veerud jne protsessori kohta.
• watch -n 1 -t -d "netstat -s | grep err": võrgupinu vead.

Si netstat näitab vigu, aga /proc/net/softnet_stat mitteTõenäoliselt tekivad kaod väljaspool meie hosti (mööda teed, läbi vahepealse tulemüüri jne). Ummikute juhtimise algoritmide tõttu tekib alati teatav kadu, kuid see peaks jääma kontrolli alla ja olema korrelatsioonis liikluse järskude tõusudega.

Järjekorra haldus (qdisc), QoS ja TCP ummikute kontroll

Kuigi kerneli sisemised järjekorrad on kriitilise tähtsusega, on seda ka võrguliidestega seotud järjekorra distsipliin (qdisc)See määrab, kuidas pakette väljundis järjestatakse, rühmitatakse ja kõrvale heidetakse, ning võib olla oluline selliste nähtuste nagu puhverpaisumise korral.

Linuxi pakkumised mitu asjakohast qdisc'i:

• pfifo_fast: vana vaikimisi distsipliin, FIFO kolme prioriteetsusvahemikuga.
• fq_kood: õiglase järjekorra loomise ja CoDeli kombinatsioon puhverpaisumise vastu võitlemiseks, väga soovitatav ruuteritele ja üldiseks kasutamiseks.
• fq: lihtne õiglane järjekorda seadmine, väga kasulik suure koormusega serverites.
• kook (sch_cake): tänapäeval kõige arenenum, aga see nõuab mooduli kompileerimist või olemasolu kernelis.

Vaikimisi näeb qdisc välja selline:

sysctl net.core.default_qdisc

Ja seda saab käigult vahetada:

sysctl -w net.core.default_qdisc=fq_codel

Selleks, et tagada konkreetse liidese kasutamine kindla distsipliini alusel, pöördutakse tc:

sudo tc qdisc asendab dev eth0 juur fq_kood

Sellega seoses TCP ummikute juhtimise algoritm See on oluline ka WAN-keskkondades või suure liiklusega keskkondades. Kernel pakub mitmeid (cubic, reno jne) ja tänapäevased versioonid sisaldavad järgmist BB laiendus välja töötanud Googlemis tavaliselt parandab püsivat läbilaskevõimet ilma latentsust suurendamata. Selle aktiveerib:

sudo sysctl -w net.ipv4.tcp_congestion_control=bbr

Saadaval olevate algoritmide loendit saab vaadata mooduleid vaadates. tcp_* en /lib/modules/<versión>/kernel/net/ipv4/. Kombineeri BBR sobiva qdisc'iga (fq/fq_code) ja hea puhverkonfiguratsiooniga See tagab palju stabiilsema andmevoo.

Täiustatud võrgukaardi sätted: rõngaspuhvrid, RSS, RPS ja koormuse mahalaadimine

Ka võrgukaardil endal on oma järjekordade ja puhvrite komplekt: rõngaspuhvrid vastuvõtmiseks (RX) ja edastamiseks (TX)Selle maksimaalne suurus sõltub riistvarast ja kuvatakse järgmiselt:

ethtool -g ethX

Väljad "Eelnevalt seatud maksimumid" Need näitavad, kui palju seda suurendada saab. Kui kaart seda lubab, saab RX-i ja TX-i suurendada väärtusteni nagu 4096, 8192 või 16384, kasutades järgmist:

ethtool -G ethX rx 4096 tx 4096

Kui kuvatakse tõrge, näiteks „Seadme helinaparameetreid ei saa määrata: sobimatu argument”, See väärtus ületab võrgukaardi võimekust. ja me peame proovima väiksemaid jagajaid.

et takistada ühel protsessoril kogu vastuvõetava töö käsitlemistPaljud tänapäevased võrgukaardid rakendavad RSS (vastuvõtupoolne skaleerimine)luues mitu riistvarajärjekorda, mis on seotud erinevate kernelidega. Linuxis näeb see jaotus välja selline:

cat /proc/katkestused | grep

RSS-ita kaartidel saab midagi sarnast "jäljendada" RPS (pakettide vastuvõtmise juhtimine), määrates protsessorid liidese tarkvara järjekordadele:

kaja f > /sys/class/net/enp4s0f0/queues/rx-0/rps_cpus

Väärtus on kuueteistkümnendsüsteemis mask. Näiteks f Binaarkoodis (1111) näitab see esimese nelja kerneli kasutamist. Kernel tuleb kompileerida CONFIG_RPS Et see toimiks.

Samuti saab mängida kontrollsumma mahalaadimine ja segmenteerimine töö CPU-lt NIC-protsessorile üleandmiseks. ethtool -k Aktiveeritud funktsioonid on nähtavad ja sisse saab lülitada näiteks järgmised funktsioonid:

ethtool -K ethX rx sees (kontrollsumma kontrollimine vastuvõtus)
ethtool -K ethX tso sees (TCP segmenteerimise mahalaadimine)

Et need muutused oleksid püsivad, paigutatakse tavaliselt võrguskriptidesse (/etc/network/interfaces Debianis/Ubuntus /etc/sysconfig/network-scripts/ifcfg-ethX Red Hatis) või udevi reeglites.

IRQ afiinsuse käsitsi peenhäälestamine ja IRQbalance'i kasutamine

Vanemates kernelites või juhtudel, kui soovime täpset kontrolli, on see võimalik Määrake käsitsi, milline protsessor konkreetset IRQ-d haldab.Kogu teave on sees /proc/irq y /proc/interruptsTüüpiline voog oleks:

• Kuva katkestused: kass / proc / katkestab ja leidke võrguliidese liin (nt IRQ 25 enp0s8 jaoks).
• Kontrollige praegust afiinsust: cat /proc/irq/25/smp_affinity (kuueteistkümnendsüsteemis mask: 02 = CPU1, 01 = CPU0, 04 = CPU2 jne).
• Muutke seda: kaja 1 > /proc/irq/25/smp_affinity et see CPU0-le teisaldada.

Sel viisil saate näiteks ülekoormatud protsessori koormuse vähendamine IRQ liigutamine vähem hõivatud tuuma. Kui irqbalance on installitud ja lubatud, on oluline öelda, et see ei puudutaks seda konkreetset katkestust, lisades sellise valiku nagu:

VALIKUD="--banirq=25"

en /etc/default/irqbalancevõi kasutades valikut --banirq=25 Kui deemon alustab. Niimoodi. Sa jätad selle automaatsest jaotusloogikast välja. ja sa austad oma käsitsi tehtud ülesannet.

Seega muutub see nii echo 1 > /proc/irq/25/smp_affinity ellu jääda taaskäivituste ajalTavaliselt lisatakse need klassikale. /etc/rc.local (kui lubatud) või konkreetsetele systemd üksustele.

Muud seotud jõudlusseaded: swap, zram, ajutised failid, eellaadimine

Kogu see töö võrgu reageerimisvõime ja IRQ-jaotuse parandamiseks kaasneb tavaliselt muu süsteemi häälestamine mis, kuigi mitte otseselt irqbalance'iga seotud, täiendavad tulemuspilti.

Mälu valdkonnas vähendavad paljud administraatorid vahetuste agressiivne kasutamine modifitseerimine /etc/sysctl.conf selliste parameetritega nagu:

• vm.vahetus: kui palju kernel eelistab swapi kasutada (0–100, vaikimisi 60). Madalad väärtused (1–10) seavad esikohale RAM-i.
• vm.vfs_cache_pressureRõhk inode'ile ja dentry vahemälule. Selle vähendamine aitab metaandmeid RAM-is hoida.
• vm.dirty_writeback_centisecs y vm.dirty_expire_centisecs: määrdunud lehtede kettale kirjutamise sagedus ja aegumine.
• vm.dirty_ration y vm.dirty_background_ratio: mälu protsent, mida saab enne sunnitud kirjutamist määrdunud andmetega täita.

Sobivate väärtustega (näiteks vm. vahetus = 1, vm.vfs_cache_pressure=50jne) saavutatakse see, et Enne lehe printimise alustamist kasutab süsteem rohkem muutmälu., midagi soovitavat serverites, kus on palju mälu.

Teine klassikaline mõõt on teisalda ajutised kataloogid RAM-i paigaldades neid nii tmpfs en /etc/fstab:

tmpfs /tmp tmpfs noatime,nodiratime,nodev,nosuid,mode=1777,defaults 0 0
tmpfs /var/tmp tmpfs noatime,nodiratime,nodev,nosuid,mode=1777,defaults 0 0

Selle abil tehakse ajutisi juurdepääsufaile (kompilatsioonid, rakenduste tööfailid jne). RAM-i kiirus ja vähendab ketaste kulumist SSD.

Samuti on ressursivaestes keskkondades tavaline aktiveerida zram-vahetusTihendatud vahetusseade muutmälus (RAM). See installitakse repositooriumist (näiteks Giti kloonimise teel). zram-swap ja tema täidesaatmine install.sh) ja loob tihendatud plokkseadme, kus süsteem vahetab enne kettavahetuse kasutamist, kui see on võimalik. Saate efektiivset mälu veidi suurema protsessori arvelt.mis kompenseerib paljusid koormusi.

Lõpuks, deemonid nagu eelkoormus Nad analüüsivad, millised rakendused kõige sagedamini töötavad, ja laadivad nende binaarfailid ja teegid RAM-i eelmälusse, kiirendades käivitamist mälu tarbimise arvelt. See on mõistlik rohke RAM-iga lauaarvutites; piiratud ressurssidega serverites see tavaliselt ära jäetakse.

GTK, GRUB, Firefox ja muud „elukvaliteedi” näpunäited

Lisaks serveri jõudlusele sisaldavad paljud õpetused väga pikki osi teemal optimeeri töölauakogemustGTK menüü reageerimisajad, fondid, tumedad teemad, heli, hiire käitumine jne. Kuigi need ei mõjuta otseselt IRQ tasakaalu ega võrguliiklust, aitavad need kaasa süsteemi reageerimisvõimelisemale toimimisele.

GTK2, GTK3 ja GTK4 puhul saab teha kohandusi. kümneid parameetreid failides, näiteks ~/.gtkrc-2.0, ~/.config/gtk-3.0/settings.ini o ~/.config/gtk-4.0/settings.iniAnimatsioonid, topeltklõpsu ajastus, kursori suurus, tiitliriba kujundus, tumedate teemade kasutamine, kohtspikri käitumine, fondi antialiasing jne. Neid faile redigeeritakse käsitsi (koos nano) või lisades ridu läbi echo >> pärit terminal.

Tavaliselt kohandatakse ka versioone. "globaalne" nendest parameetritest /etc/gtk-2.0/gtkrc, /etc/gtk-3.0/settings.ini y /etc/gtk-4.0/settings.ini, nii et need mõjutavad kõiki kasutajaid, arvestades alati, et sellistel juhtudel peate olema root (via su - o sudo).

El juhi ooteaeg saabas GRUB Redigeerimisega läheb lühemaks. /etc/default/grub ja muutmine GRUB_TIMEOUT (näiteks 10 sekundist 3 sekundini) ja kerneli parameetrite lisamine, näiteks noresume o acpi_irq_balance en GRUB_CMDLINE_LINUX_DEFAULTSeejärel see täidetakse. update-grub (Debian/Ubuntu) või grub-mkconfig -o /boot/grub/grub.cfg (Arhiivid ja derivaadid).

Brauseri puhul on olemas sellised failid nagu user.js Firefoxi jaoks Need seaded võimaldavad teil rakendada sirvimise kiirendamiseks mitmeid eelistusi: ühenduste arv, vahemälu käitumine, tihendamine, WebSocketid jne. Tavaline protseduur on profiili lähtestamine, profiilikataloogi avamine jaotisest "Veaotsingu teave", Firefoxi sulgemine ja järgmise kleepimine: user.js profiilikaustas ja avage brauser uuesti.

Kuigi kõik see on paralleelne tasakaalustamatuse teemaga, illustreerib see olulist ideed: Linuxi optimeerimine on terviklik protsessSee ei puuduta ainult deemonit või maagilist parameetrit, vaid protsessori, mälu, ketta, võrgu, töölaua ja rakenduste peenhäälestamist, kuni need sobivad masina tegeliku kasutusega.

Kogu paketti vaadates – IRQ eraldamine irqbalance'iga või käsitsi, NAPI ja optimeeritud järjekorrad, õige suurusega TCP puhvrid, kaasaegsed q-kettad nagu fq_codel või fq, BBR-i ummikute kontroll, laiendatud ringpuhvrid, lubatud RSS/RPS, kontrolli all olev swap ja zram, ajutised failid RAM-is ja peenelt häälestatud töölauakeskkond – saab selgeks, et irqbalance on vaid üks tükk üsna suurest puslestSelle roll on ülioluline mitmetuumaliste serverite ja suure liiklusega serverite puhul, see on ebaoluline paljudes lauaarvutites ja kahjulik äärmise latentsusega süsteemides, kus eelistatakse käsitsi seadistamist; selle konteksti hea mõistmine on võtmetähtsusega, et otsustada, kas lasta sellel töötada, seda piirata või lihtsalt keelata.