Kam Linux sistēmā tiek izmantots IRQbalance un kā tas iederas uzlabotajā optimizācijā?

Kad sākat eksperimentēt ar GNU/Linux sistēmas veiktspēju, agrāk vai vēlāk parādās atkārtots galvenais varonis: irqbalance un aparatūras pārtraukumu sadalījums starp centrālajiem procesoriem . Tas tiek apspriests forumos, izplatīšanas dokumentācijā un pamācībās par sistēmas "regulēšanu", lai tā darbotos... taču reti tiek skaidri izskaidrots, ko tā īsti dara, kādos scenārijos tā gūst labumu un kuros jūs neko nepamanīsiet.

Turklāt visa šī IRQ līdzsvarošana ir sajaukta ar citiem sarežģītiem jēdzieniem: NAPI, kodola saņemšanas rindām, NIC buferiem, TCP pārslodzes kontroles algoritmiem, RSS/RPS, BBR, sysctl iestatījumiem, veiktspējas dēmoniem, piemēram, iepriekšēju ielādi, ar zram saspiestu mijmaiņas failu, GTK optimizāciju, pagaidu failiem RAM utt. Ir ļoti viegli apmaldīties starp parametriem, komandām un konfigurācijas failiem, skaidri neizprotot katras lietas darbību.

Kas ir IRQbalance un kam tas īsti tiek izmantots Linux sistēmā?

irqbalance ir lietotāja telpas dēmons, kas sadala aparatūras pārtraukumus (IRQ) starp CPU kodoliem SMP (daudzprocesoru vai daudzkodolu) sistēmās. Tā mērķis nav maģisks: tas vienkārši tiecas novērst, lai visa apkalpojošo ierīču (tīkla, disku, USB utt.) darba slodze nonāktu vienā kodolā.

Kad ierīce ģenerē IRQ, kodols izpilda pārtraukumu apstrādātāju. Ja daudzi no šiem pārtraukumiem ir koncentrēti vienā centrālajā procesorā (CPU), šis centrālais procesors var tikt pārslogots, kamēr pārējie paliek dīkstāvē. irqbalance analizē pārtraukumu skaitu katrā ierīcē un piešķir katru IRQ piemērotam kodolam, lai sadalītu slodzi , vienlaikus cenšoties samazināt kešatmiņas zudumus un ievērot loģiskās afinitātes (piemēram, saglabājot IRQ no vienas tīkla saskarnes saistītus).

Sistēmās ar vienu centrālo procesoru vai kodoliem, kas pilnībā koplieto L2 kešatmiņu , irqbalance pats nosaka, ka tam nav nekā noderīga darāma, un izslēdzas. Tā nav kļūda; vienkārši nav vietas uzlabojumiem. Tomēr serveros ar vairākiem fiziskiem centrālajiem procesoriem vai daudziem kodoliem, īpaši ar lielu tīkla trafiku vai augstu I/O, tas var ietekmēt latentumu un stabilitāti.

Dēmons var darboties fonā (apkalpošanas režīmā) vai pēc nepieciešamības, izmantojot opciju –viens šāviens. Arī ļauj izslēgt konkrētus IRQ pēc izvēles --banirq un neļaut tam izmantot noteiktus kodolus ar CPU masku, kas definēta vides mainīgajā IRQBALANCE_BANNED_CPUSTas viss parasti tiek kontrolēts no jūsu konfigurācijas faila, kas daudzās distribūcijās atrodas /etc/default/irqbalance o /etc/irqbalance.env.

IRQ balansēšana: kodols pret IRQ balansēšanu un kad tas ir pamanāms

Linux jau ir savs iekšējais mehānisms, lai izlemtu, kurš centrālais procesors apstrādā katru IRQ, neizmantojot irqbalance. Kodols var iestatīt pārtraukumu afinitātes un izplatīt tās, izmantojot vienkāršu heiristiku , un daudzos galddatoros ar to ir vairāk nekā pietiekami: vidusmēra lietotājs nepamanīs nekādu atšķirību, iespējojot vai atspējojot irqbalance.

Tāpēc ir samērā bieži, ka kāds savā darbvirsmas distro izmēģina irqbalance un saka: "Es nepamanu nekādus uzlabojumus, bet arī neko sliktu nav ." Tas ir pilnīgi normāli. Klēpjdatorā ar četrkodolu procesoru un vienu tīkla karti bez lielas I/O slodzes Linux plānotājs un iekšējie kodola mehānismi (NAPI, tīkla rindas utt.) jau uztur lietas samērā līdzsvarotas.

Tas ir loģiski vairāku kodolu serveros ar intensīvu datplūsmu : lielās datubāzēs , reversajos starpniekserveros, tīmekļa serveros ar lielu datplūsmu, dublējuma krātuvēs , ļoti noslogotās virtuālajās mašīnās utt. Šādās situācijās daudzu tīkla vai disku IRQ piesaistīšana vienam kodolam var kļūt par sašaurinājumu. To izplatīšana efektīvi samazina rindas, apkalpošanas laikus un latentuma pieaugumus.

Daži lietotāji dod priekšroku izmantot irqbalance, nevis irqbalance parametrizējiet kodolu ar tādām opcijām kā acpi_irq_balance GRUB. Šis parametrs ietekmē to, kā ACPI un kodols piešķir IRQ, taču tas nepiedāvā tādu pašu dinamisko elastību kā irqbalance, kas atkārtoti novērtē piešķiršanu, pamatojoties uz faktisko slodzi. Tās ir dažādas pieejas: pirmā ir statiskāka un zemāka līmeņa; otrā — adaptīvāka.

Īpaši zemas latentuma vidēs (piemēram, noteiktās tirdzniecības platformās vai tīklos ar DPDK) notiek pretējais: irqbalance parasti tiek atspējots, un IRQ tiek manuāli piešķirti konkrētiem kodoliem , kā arī rūpīgi tiek veikta kartēšana starp tīkla karšu rindām un centrālajiem procesoriem. Šādos gadījumos tiek meklēta absolūta kontrole un tiek upurēta daļa automatizācijas.

Pārtraukumi, NAPI un tīkla rindas: kā IRQbalance iederas

Lai labāk izprastu irqbalance lomu, mums jāiet uz leju vēl vienā līmenī un jāaplūko, kā Linux tos apstrādā. tīkla pārtraukumi un pakešu saņemšanaKodola tīkla apakšsistēma apvieno vairākus galvenos komponentus: NAPI, saņemšanas rindas (DMA buferis), parametrus net.core.*, rindu pārvaldības algoritmi (qdisc) un laterālā mērogošana (RSS/RPS).

NAPI (Jaunā API) ir mehānisms, ar kuru kodols samazina pārtraukumu skaitu, kad pienāk liela datplūsma. Tā vietā, lai katrai paketei izsauktu IRQ, tīkla karte ģenerē pārtraukumu, kas norāda, ka "ir gaidāms darbs", un kodols aptaujā saņemšanas rindu, līdz tā ir tukša vai ir izsmelts laika/paketi budžets. Tas samazina svārstības un uzlabo veiktspēju, lai gan var radīt arī zināmas latentuma izmaiņas.

Rindu, kurā paketes nonāk pirms to apstrādes tīkla kaudzē, parasti sauc par kodola saņemšanas rindu vai DMA buferi . Tās ietilpību ierobežo tādi parametri kā:

• net.core.netdev_max_backlog: maksimālais pakešu skaits programmatūras saņemšanas rindā, kad kodols nevar tās apstrādāt ar to ierašanās ātrumu.
• net.core.netdev_budget_usecs: laika “budžets” mikrosekundēs, kas NAPI ir paredzēts rindu iztukšošanai katrā ciklā.
• net.core.dev_weight: katrā saskarnē apstrādāto pakešu skaits katrā kārtā noteiktā budžeta ietvaros.

Si netdev_max_backlog ir ļoti zems un tīkla karte nosūta vairāk pakešu, nekā kodols spēj apstrādāt, mēs sāksim redzēt "atmestās paketes" /proc/net/softnet_statTipisks sākumpunkts precīzai regulēšanai serveros ar lielu datplūsmu ir diapazonā no 4000 iepakojumi, konfigurēts /etc/sysctl.conf ar kaut ko līdzīgu:

tīkls.core.netdev_max_backlog = 4000

Pēc modificēšanas tas tiek lietots ar sysctl -p vai ar sysctl -w punktuāls. Tādā veidā aste labāk absorbē ierašanās maksimumus nezaudējot paketes, ja vien pārējais apstrādes ceļš iztur.

Visā šajā ķēdē irqbalance izlemj, kurš centrālais procesors apstrādā ar tīkla saskarni saistītos IRQ. Ja visus NIC pārtraukumus koncentrēsim vienā kodolā, šis kodols pats izpildīs NAPI rutīnas un iztukšos rindu . Ja IRQ sadalīsim efektīvi un izmantosim tādus mehānismus kā RSS vai RPS, vairāki centrālie procesori var sadarboties, lai apstrādātu paketes, samazinot rindas un pakešu zudumu.

Precīzi noregulējiet rindas, buferus un TCP logu intensīvai datplūsmai

Ja serveris apstrādā lielu datu apjomu (piemēram, dublējumkopijas, FTP trafiku, lielus failus vai replicētas datubāzes), ar irqbalance iespējošanu vien nepietiek. Ir jāsaskaņo vairāki līmeņi: kodola rindas, tīkla saskarnes buferi, TCP logu izmēri un pārslodzes parametri , lai viss darbotos vienā virzienā.

Pirmais regulēšanas bloks atrodas pakešu saņemšanas buferī un TCP logā . Linux sistēmā ir pieejami tādi parametri kā:

• net.ipv4.tcp_rmem: TCP saņemšanas atmiņas triplets (minimums, noklusējuma vērtība, maksimums) katrā ligzdā.
• net.ipv4.tcp_wmem: līdzvērtīgs kuģniecībai.
• net.core.rmem_max y net.core.wmem_max: maksimālā cietā bufera ietilpība, ko lietojumprogramma var pieprasīt.

Praktisks veids, kā pielāgot šos parametrus zema latentuma gigabitu saitei, ir aprēķināt joslas platuma un aizkaves reizinājumu (BDP) un piemērot mērogošanas koeficientu (pateicoties TCP loga mērogošanas opcijai , kas pēc noklusējuma ir iespējota lielākajā daļā mūsdienu kodolu). Praksē daudzi administratori iegūst maksimālās vērtības vairākos megabaitos, piemēram:

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

Šis maksimums ~10,8 MB ir iegūts no īpašiem aprēķiniem 1 Gb/s saitēm ar ļoti zemu RTT (~0,00017 s). Jo lielāka caurlaidspēja vai latentums, jo lielākam jābūt buferim, lai izmantotu joslas platumu, neierobežojot to ar bufera logu.

Ir svarīgi saistīt šo maksimumu ar pakešu saņemšanas rindas lielumu. Ja netdev_max_backlog = 4000 un katra efektīvā pakete ir aptuveni 1480 baiti, šī rinda pārstāv aptuveni 5,9 MB. TCP loga buferim ir jābūt lielākam par rindas ietilpību , pretējā gadījumā mēs zaudēsim paketes, jo buferis piesātināsies pirms rindas.

Lai uzraudzītu zaudējumus , var izmantot šādas komandas:

• cat /sys/class/net/eth0/statistics/rx_dropped: tīkla kartē pazaudētās paketes.
• watch -n 1 -t -d cat /proc/net/softnet_stat: apstrādātās kolonnas, atmestās, laika ziņā ierobežotās kolonnas utt. uz katru centrālo procesoru.
• watch -n 1 -t -d "netstat -s | grep err": tīkla steka kļūdas.

Ja netstat norāda kļūdas, bet /proc/net/softnet_stat to nedara , zudumi, visticamāk, rodas ārpus mūsu resursdatora (pa ceļu, caur starpposma ugunsmūri utt.). Nelieli zudumi vienmēr būs sastrēgumu kontroles algoritmu dēļ, taču tiem vajadzētu būt pārvaldāmiem un korelēt ar datplūsmas pieauguma tempiem.

Rindu pārvaldība (qdisc), QoS un TCP pārslodzes kontrole

Lai gan kodola iekšējās rindas ir kritiski svarīgas, tikpat svarīga ir arī rindu disciplīna (qdisc), kas saistīta ar tīkla saskarnēm . Tā nosaka, kā paketes tiek sakārtotas, grupētas un atmestas izvadē, un var ietekmēt tādu parādību kā bufera uzpūšanās mazināšanu.

Linux piedāvā vairākus atbilstošus qdiskus :

• pfifo_fastvecā noklusējuma disciplīna, FIFO ar trim prioritāšu joslām.
• fq_code: godīgas rindošanas un CoDel kombinācija, lai apkarotu bufera uzpūšanos, ļoti ieteicams maršrutētājiem un vispārējai lietošanai.
• fqVienkārša godīga rindu veidošana, ļoti noderīga serveros ar lielu noslodzi.
• kūka (sch_cake): mūsdienās vismodernākā, taču tai nepieciešama kompilēšana vai moduļa iekļaušana kodolā.

Noklusējuma qdisc izskatās šādi:

sysctl net.core.default_qdisc

Un to var ātri nomainīt ar:

sysctl -w net.core.default_qdisc=fq_codel

Lai nodrošinātu, ka konkrēta saskarne izmanto noteiktu disciplīnu, tiek ķerts pie tc:

sudo tc qdisc aizstāt dev eth0 root fq_codel

Saistībā ar to TCP pārslodzes kontroles algoritms arī ietekmē WAN vides vai tās, kurās ir liela datplūsma. Kodols piedāvā vairākus (cubic, reno utt.), un mūsdienu versijas ietver BBR, ko izstrādājis Google , kas parasti uzlabo ilgstošu caurlaidspēju, būtiski nepalielinot latentumu. Tas tiek aktivizēts ar:

sudo sysctl -w net.ipv4.tcp_congestion_control=bbr

Pieejamo algoritmu sarakstu var pārbaudīt, apskatot moduļus tcp_* en /lib/modules/<versión>/kernel/net/ipv4/. Apvienojiet BBR ar piemērotu qdisc (fq/fq_code) un labu bufera konfigurāciju. Tas nodrošina daudz stabilākas datu plūsmas.

Papildu tīkla kartes iestatījumi: gredzenveida buferi, RSS, RPS un slodzes samazināšana

Arī pašai tīkla kartei ir savs rindu un buferu komplekts: saņemšanas (RX) un pārraides (TX) gredzena buferi . To maksimālais izmērs ir atkarīgs no aparatūras un tiek parādīts šādi:

ethtool -g ethX

Lauki “Iepriekš iestatītie maksimumi” norāda, cik daudz vērtības var palielināt. Ja karte to atļauj, RX un TX var palielināt līdz tādām vērtībām kā 4096, 8192 vai 16384, izmantojot:

ethtool -G ethX rx 4096 tx 4096

Ja parādās kļūda, piemēram, “Nevar iestatīt ierīces zvana parametrus: nederīgs arguments”, šī vērtība pārsniedz tīkla kartes iespējas , un būs jāizmēģina mazāki dalītāji.

Lai viens centrālais procesors (CPU) nevarētu apstrādāt visu saņemšanas darba slodzi , daudzas mūsdienu tīkla kartes (NIC) ievieš saņemšanas puses mērogošanu (RSS) , izveidojot vairākas aparatūras rindas, kas saistītas ar dažādiem kodoliem. Linux sistēmā šo izplatījumu attēlo:

kaķis /proc/pārtraukumi | grep

Kartēs bez RSS kaut ko līdzīgu var "emulēt" ar RPS (Receive Packet Steering — pakešu saņemšanas vadību) , piešķirot centrālos procesorus saskarnes programmatūras rindām:

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

Vērtība ir heksadecimāla maska. Piemēram, f Binārajā formātā (1111) tas norāda uz pirmo četru kodolu izmantošanu. Kodols ir jākompilē ar CONFIG_RPS Lai tas darbotos.

Varat arī spēlēties ar kontrolsummas atslodze un segmentācija lai pārnestu darbu no centrālā procesora uz tīkla kartes procesoru. ethtool -k Aktivizētās iespējas ir redzamas, un var ieslēgt, piemēram, šādas iespējas:

ethtool -K ethX rx ieslēgts (kontrolsummas pārbaude reģistratūrā)
ethtool -K ethX tso ieslēgts (TCP segmentācijas atslodze)

Lai šīs pārmaiņas būtu ilgstošas, parasti tiek ievietoti tīkla skriptos (/etc/network/interfaces Debian/Ubuntu vidē, /etc/sysconfig/network-scripts/ifcfg-ethX Red Hat) vai udev noteikumos.

Manuāli precīzi noregulējiet IRQ afinitāti un dzīvojiet ar IRQbalance

Vecākos kodolos vai gadījumos, kad nepieciešama precīza kontrole, tas ir iespējams. Manuāli piešķiriet, kurš centrālais procesors apstrādā konkrētu IRQ.Visa informācija ir iekšā /proc/irq y /proc/interruptsTipiska plūsma būtu šāda:

• Skatīt pārtraukumus: cat / proc / pārtrauc un atrodiet tīkla saskarnes līniju (piemēram, IRQ 25 priekš enp0s8).
• Pārbaudiet pašreizējo afinitāti: kaķis /proc/irq/25/smp_affinity (heksadecimāldaļas maska: 02 = CPU1, 01 = CPU0, 04 = CPU2 utt.).
• Mainiet to: atbalss 1 > /proc/irq/25/smp_affinity lai to pārvietotu uz CPU0.

Tādā veidā jūs varat, piemēram, atbrīvot no slodzes piesātinātu centrālo procesoru , pārvietojot IRQ uz mazāk noslogotu kodolu. Ja jums ir instalēts un iespējots irqbalance, ir svarīgi norādīt tam, lai tas nepieskaras šim konkrētajam pārtraukumam, pievienojot šādu opciju:

IESPĒJAS="--banirq=25"

en /etc/default/irqbalancevai izmantojot opciju --banirq=25 Kad dēmons sāk darboties. Tā. Jūs to izslēdzat no automātiskās izplatīšanas loģikas. un jūs cienāt savu manuālo uzdevumu.

Tātad tas mainās šādi echo 1 > /proc/irq/25/smp_affinity pārdzīvot pārstartēšanasTie parasti tiek pievienoti klasiskajam ēdienam. /etc/rc.local (ja iespējots) vai konkrētām systemd vienībām.

Citi saistītie veiktspējas iestatījumi: swap, zram, pagaidu faili, iepriekšēja ielāde

Visu šo tīkla reakcijas un IRQ sadalījuma uzlabošanas darbu parasti pavada cita sistēmas regulēšana , kas, lai gan nav tieši saistīta ar irqbalance, papildina veiktspējas ainu.

Atmiņas jomā daudzi administratori samazina agresīva mijmaiņas izmantošana modificēšana /etc/sysctl.conf ar tādiem parametriem kā:

• vm.swapiness: cik lielā mērā kodols dod priekšroku mijmaiņas izmantošanai (0–100, pēc noklusējuma 60). Zemas vērtības (1–10) piešķir prioritāti RAM.
• vm.vfs_cache_pressureNoslodze uz inodu un dentry kešatmiņu. Tās samazināšana palīdz saglabāt metadatus RAM atmiņā.
• vm.dirty_writeback_centisecs y vm.dirty_expire_centisecs: netīru lapu rakstīšanas diskā biežums un derīguma termiņš.
• vm.dirty_ratio y vm.dirty_background_ratio: atmiņas procentuālā daļa, ko var aizpildīt ar netīriem datiem pirms piespiedu rakstīšanas.

Ar atbilstošām vērtībām (piemēram, vm.swappiness=1 , vm.vfs_cache_pressure=50 utt.) sistēmu var panākt, lai tā izmantotu vairāk RAM pirms lapošanas sākšanas , kas ir vēlams serveros ar lielu atmiņas apjomu.

Vēl viens klasisks rādītājs ir pārvietot pagaidu direktorijus uz RAM uzstādot tos kā 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

Tas ļauj veikt īslaicīgas piekļuves (kompilācijām, lietojumprogrammu darba failiem utt.) ar RAM ātrumu , samazinot SSD disku nodilumu.

Vidēs ar zemu resursu patēriņu ir arī ierasts aktivizēt zram-swapSaspiesta mijmaiņas ierīce RAM atmiņā. Tā tiek instalēta no repozitorija (piemēram, izmantojot Git, klonējot). zram-swap un izpildot savu install.sh) un izveido saspiestu bloka ierīci, kurā sistēma veic apmaiņu, pirms, ja iespējams, ķeras pie disku apmaiņas. Jūs iegūstat efektīvu atmiņu par nedaudz lielāka centrālā procesora (CPU) rēķina.kas kompensē daudzas slodzes.

Visbeidzot, tādi dēmoni kā iepriekšēja ielāde analizē, kuras lietojumprogrammas darbojas visbiežāk, un iepriekš ielādē to bināros failus un bibliotēkas RAM atmiņā, paātrinot to startēšanu, bet patērējot atmiņu. Tas ir lietderīgi galddatoros ar lielu RAM apjomu; serveros ar ļoti ierobežotiem resursiem tas parasti tiek izlaists.

GTK, GRUB, Firefox un citi “dzīves kvalitātes” uzlabojumi

Papildus tīrai servera veiktspējai daudzās pamācībās ir iekļautas garas sadaļas par darbvirsmas pieredzes optimizēšanu : GTK izvēlnes reakcijas laiki, fonti, tumšās tēmas, skaņa, peles darbība utt. Lai gan tie tieši neietekmē IRQ līdzsvaru vai tīkla trafiku, tie veicina atsaucīgāku sistēmu.

GTK2, GTK3 un GTK4 versijās var veikt pielāgojumus. desmitiem parametru failos, piemēram ~/.gtkrc-2.0, ~/.config/gtk-3.0/settings.ini o ~/.config/gtk-4.0/settings.iniAnimācijas, dubultklikšķa laiks, kursora izmērs, virsrakstjoslas dizains, tumšo tēmu izmantošana, rīkjoslas darbība, fonta antialiasing utt. Šie faili tiek rediģēti manuāli (ar nano) vai pievienojot līnijas caur echo >> no termināls.

Versijas parasti tiek arī pielāgotas. "globāls" no šiem parametriem /etc/gtk-2.0/gtkrc, /etc/gtk-3.0/settings.ini y /etc/gtk-4.0/settings.ini, lai tie attiektos uz visiem lietotājiem, vienmēr ņemot vērā, ka šādos gadījumos jums ir jābūt root lietotājam (izmantojot su - o sudo).

El vadītāja gaidīšanas laiks zābaks GRUB Rediģējot, tas kļūst īsāks. /etc/default/grub un modificējot GRUB_TIMEOUT (piemēram, no 10 līdz 3 sekundēm) un pievienojot kodolam parametrus, piemēram, noresume o acpi_irq_balance en GRUB_CMDLINE_LINUX_DEFAULTTad tas tiek izpildīts. update-grub (Debian/Ubuntu) vai grub-mkconfig -o /boot/grub/grub.cfg (Arhīvi un atvasinājumi).

Pārlūkprogrammas gadījumā ir tādi faili kā user.js par Firefox Šie iestatījumi ļauj lietot vairākas preferences, kuru mērķis ir paātrināt pārlūkošanu: savienojumu skaits, kešatmiņas darbība, saspiešana, WebSockets utt. Parasti atiestata profilu, atver profila direktoriju sadaļā "Informācija par problēmu novēršanu", aizver Firefox un ielīmē šo: user.js profila mapē un atkārtoti atveriet pārlūkprogrammu.

Lai gan tas viss ir saistīts ar irqbalance tēmu, tas ilustrē svarīgu ideju: Linux optimizācija ir holistisks process . Tā nav tikai dēmona vai maģiska parametra izmantošana, bet gan centrālā procesora, atmiņas, diska, tīkla, darbvirsmas un lietojumprogrammu precīza noregulēšana, līdz tā atbilst faktiskajai datora lietošanai.

Aplūkojot visu ainu — IRQ piešķiršanu ar irqbalance vai manuālu konfigurāciju, optimizētu NAPI un rindas, atbilstoša izmēra TCP buferus, modernus qdiskus, piemēram, fq_codel vai fq, BBR pārslodzes kontroli, paplašinātus gredzenu buferus, iespējotu RSS/RPS, kontrolētu mijmaiņas un zram darbību, pagaidu RAM un precīzi noregulētu darbvirsmas vidi —, kļūst skaidrs, ka irqbalance ir tikai viena daļa no diezgan lielas puzles . Tās loma ir vitāli svarīga daudzkodolu serveros ar lielu datplūsmu, nav būtiska daudzos darbvirsmās un ir neproduktīva sistēmās ar ārkārtīgi latentumu, kur priekšroka tiek dota manuālai afinitātes iestatīšanai. Šī konteksta izpratne ir būtiska, lai izlemtu, vai ļaut tam darboties, ierobežot tā lietošanu vai pilnībā atspējot to.