Uzlabota Linux kodola optimizācija ar sysctl

Informatec Digital » Resursi » Uzlabota Linux kodola optimizācija ar sysctl

Ja jau kādu laiku pārvaldāt Linux serverus, jūs galu galā atklāsiet, ka atšķirība starp viduvēju sistēmu un tādu, kas darbojas ar lielu slodzi, slēpjas kodola noregulēšanas prasmē. Runa nav tikai par lielākas RAM vai jaudīgāka centrālā procesora instalēšanu: daudzas problēmas tiek novērstas, pielāgojot dažus rūpīgi izvēlētus parametrus.

Kodols piedāvā simtiem tīkla, atmiņas, failu sistēmas un procesu plānošanas opciju, kuras var modificēt reāllaikā. Ar rīku sysctl un dažas korekcijas /procIr iespējams maksimāli izmantot aparatūru un sasniegt zemāka latentuma, lielāka caurlaidspēja un labāka stabilitāte Tas attiecas uz tīmekļa serveriem un datubāzēm, kā arī reāllaika vidēm un Kubernetes. Tomēr ir svarīgi precīzi zināt, ko jūs darāt un kā to izmērīt.

Kas ir sysctl un kā tas organizē kodola parametrus?

Lietderība sysctl Tas ir vārti uz kodola parametru mainīšanu bez nepieciešamības atkārtoti kompilēt vai pārstartēt, ļaujot lasīt un modificēt vērtības izpildes laikā lai nekavējoties pārbaudītu konfigurācijas. Šie parametri ir sakārtoti zemā hierarhiskā kokā /proc/sys/un katrs no tiem kontrolē noteiktu sistēmas darbību.

Iestatījumi ir sagrupēti atšķirīgās kategorijās, kas atvieglo precīzu iestatījumu noteikšanu, ja rodas konkrēta veiktspējas vai stabilitātes problēma. Šī struktūra ļauj koncentrēties, piemēram, tikai uz tīklu (net.*), atmiņu (vm.*) vai failu sistēmu (fs.*), neapmaldoties pārējās kodola opcijās.

Galvenās kategorijas, kuras jūs atradīsiet /proc/sys/ Tie cita starpā ietver:

• kodols.*: vispārīgās kodola opcijas (plānotājs, PID, ziņojumi, NUMA utt.).
• vm.*: virtuālās atmiņas pārvaldība, mijmaiņas, kešatmiņas un pārslodzes politikas.
• neto.*IPv4/IPv6 tīkla steks, TCP/UDP buferi, rindas, sastrēgumu kontrole.
• fs.*: deskriptoru, inodu, inotify, AIO un VFS uzvedības ierobežojumi.
• izstrād.*: noteiktu ierīču un draiveru specifiski parametri.

ar sysctl -a Varat uzskaitīt visus pieejamos parametrus, un ar tādām komandām kā sysctl vm.swappiness o sysctl net.ipv4.tcp_tw_reuse konkrētu vērtību lasīšana, kas ir galvenais, lai auditēt pašreizējo konfigurāciju pirms kaut ko mainīt. Lai atrastu kaut ko konkrētu, parasti tiek izmantota filtrēšana ar grepPiemēram: sysctl -a | grep tcp.

Parametra modificēšana acumirklī ir tikpat vienkārša kā sysctl -w clave=valorTomēr ir svarīgi saprast, ka šīs izmaiņas ir īslaicīgas. Lai tās saglabātu pēc pārstartēšanas, ir svarīgi dublēt konfigurāciju uz /etc/sysctl.conf vai failos /etc/sysctl.d/, parasti izmantojot numurētus failus (piemēram, 10-network.conf, 20-memory.conf, 99-custom.conf), kas nosaka to piemērošanas secību.

Izmēriet pirms pieskaršanās: etaloni un sistēmas bāzes līnija

Pirms sākat mainīt iestatījumus, ir ieteicams noteikt objektīvu veiktspējas bāzes līniju . Bez iepriekšējiem datiem nav iespējams zināt, vai izmaiņas ir uzlabojušas vai pasliktinājušas sistēmu, un jūs nonāksit klasiskajā "man šķiet labāk" slazdā, kas ir bezjēdzīgs pamatotu lēmumu pieņemšanai.

Sistēmas līmenī ir ieteicams dažas minūtes apkopot centrālā procesora, slodzes, atmiņas, diska un tīkla statistiku reprezentatīvas slodzes apstākļos. Rīki, piemēram, uptime, mpstat, vmstat, iostat -x o sar -n DEV Tie ļauj redzēt, kā darbojas standarta kodols, cik daudz mijmaiņas apgabala tas izmanto, kā reaģē diska I/O un vai tīkls ir piesātināts vai izšķiež joslas platumu.

Papildus šim pārskatam ir svarīgi veikt konkrētus salīdzinošos testus lietojumprogrammai, kuru vēlaties optimizēt. Tīmekļa serveros varat izmantot ab (Apache Bench) vai līdzīgi mērīšanas instrumenti pieprasījumu skaits sekundē, vidējā latentuma pakāpe un kļūdasDatu bāzēs tādi utilītas kā mysqlslap o sysbench Tie palīdz novērtēt darījumu skaitu sekundē un vaicājumu izpildes laikus.

Piemēram, scenārijā bez regulēšanas ir bieži sastopami tādi skaitļi kā 500 HTTP pieprasījumi/s ar 200 ms vidējo atbildes laiku, aptuveni 250 SQL vaicājumi/s ar 40 ms latentumu, tīkla ātrums aptuveni 500 Mb/s un sistēmas slodze, kas tuvojas robežai stresa apstākļos. Šie skaitļi tiks izmantoti, lai pēc kodola izmaiņu ieviešanas pārbaudītu, vai faktiski tiek panākts izmērāms caurlaidspējas pieaugums un latentuma samazinājums.

Visbeidzot, pirms jebkādu izmaiņu veikšanas dokumentējiet komandas un rezultātus. Vēstures iegūšana ļaus precīzi salīdzināt dažādas korekciju partijas un arī palīdzēs noteikt regresijas pēc kodola atjaunināšanas vai jauna sysctl profila ieviešanas ražošanas vidē.

Papildu atmiņas iestatījumi: vm.*

Atmiņa ir viena no apakšsistēmām, kurā kodola izmaiņas ir vispamanāmākās. Serveris ar lielu operatīvo atmiņu, bet slikti konfigurētu, var nevajadzīgi izmantot mijmaiņas vietu, izraisot... I/O pieaugumi un krasi veiktspējas kritumiTāpēc tādi parametri kā vm.swappinessNetīru lapu attiecības vai VFS kešatmiņas darbība ir tikpat svarīgas.

Parametrs vm.swappiness Tas kontrolē, cik daudz atmiņas lappušu kodols nosūta mijmaiņas darbībai. Daudzās distribūcijās tas ir iestatīts uz 60, kas ir paredzēta jauktām darbvirsmas vidēm. Datu bāzu serveriem vai lietojumprogrammām ar zemu latentumu parasti ir vēlams to samazināt līdz 10 vai pat mazāk, kā rezultātā sistēma būs efektīvāka. prioritāte datu glabāšanai RAM atmiņā un apmaiņas samazināšanaPēc šīs korekcijas nav nekas neparasts novērot diska datplūsmas strauju samazināšanos un lietojumprogrammu reaģēšanu ar daudz mazāku svārstīgumu.

Vēl viens būtisks pamatelements ir vm.dirty_ratio y vm.dirty_background_ratioŠīs vērtības nosaka, cik lielu atmiņas procentuālo daļu var aizpildīt ar netīrām lapām, pirms kodols sāk tās ierakstīt diskā. Pārāk augstas vērtības var izraisīt lielus rakstīšanas apjomus ar milzīgu latentumu visām lietojumprogrammām, kad notiek datu pārsūtīšana. Samazinot šos procentuālos rādītājus attiecīgi līdz 15 un 5, parasti rodas rezultāts. konsekventāks un paredzamāks I/O modelis.

Iestatījums vm.vfs_cache_pressure Tas nosaka, cik agresīvi kodols attīra inode un direktoriju kešatmiņu. Noklusējuma vērtība 100 parasti nodrošina ātru kešatmiņas attīrīšanu, savukārt iestatījumi ap 50 ļauj metadatus saglabāt ilgāk, palielinot failu operāciju trāpījumu līmeni un uzlabojot veiktspēju. failu sistēmas uztvertā veiktspēja, kaut kas svarīgs serveros, kas apstrādā miljoniem mazu failu.

No savas puses, vm.min_free_kbytes Rezervējiet minimālu brīvās atmiņas apjomu, lai nodrošinātu, ka sistēma var reaģēt uz piešķiršanas uzliesmojumiem, neradot pēkšņas sākotnējās darbības (OOB) situācijas. Šīs rezerves daļas rezervēšana aptuveni 0,5–1% apmērā no kopējās RAM apjoma parasti ir efektīvs drošības pasākums, lai novērstu kodola vietas trūkumu ārkārtējas slodzes gadījumā un kritisku procesu apturēšanu, tādējādi uzlabojot veiktspēju. kopējā saimnieka stabilitāte.

Visbeidzot, uzmanība ir pelnījusi pārmērīgas saistības politiku: tādi parametri kā vm.overcommit_memory y vm.overcommit_ratio Tie nosaka, cik daudz virtuālās atmiņas tiek piešķirts procesiem attiecībā pret pieejamo RAM un mijmaiņas atmiņu. Dažos gadījumos (piemēram, ar Redis vai noteiktām datubāzēm) ir atļauta agresīva pārmērīga atvēlēšana, savukārt citos gadījumos priekšroka tiek dota konservatīvākai politikai, lai ierobežotu risku. OOM un pārmērīgi apdraudētas atmiņas situācijasLai uzzinātu par sarežģītu gadījumu analīzes un diagnosticēšanas metodēm, konsultējieties ar atmiņas atkļūdošana operētājsistēmā Linux.

Paplašināta tīkla optimizācija: net.* un TCP/IP

Tīkla steks, iespējams, ir joma, kurā regulēšana ir visievērojamākā ražošanas vidē. Vienkāršas savienojuma rindu vai buferu izmaiņas var būt noteicošās starp serveri, kas aizsērē ar ātrumu 500 Mb/s, un tādu, kas... Tas viegli piesātina gigabitu.Parametri zem net.core.* y net.ipv4.* Šajā jomā viņi ir jūsu labākie sabiedrotie.

Sākumā jāņem vērā, ka ligzdas bufera izmēri tieši ietekmē savienojuma maksimālo caurlaidspēju, īpaši, ja ir augsts latentums vai lielas ietilpības saites. net.core.rmem_max y net.core.wmem_max dāsnām vērtībām (desmitiem vai simtiem megabaitu) un pareizi definēt net.ipv4.tcp_rmem y net.ipv4.tcp_wmem (minimālā, noklusējuma vērtība un maksimālā) ļauj katrai ligzdai telpa, kas nepieciešama satiksmes intensitātes amortizēšanai neiekrītot mākslīgos ierobežojumos, ko uzliek ļoti konservatīvas rūpnīcas vērtības.

Vēl viens svarīgs aspekts ir savienojuma rindu lielums. Parametri, piemēram, net.core.somaxconn, net.core.netdev_max_backlog y net.ipv4.tcp_max_syn_backlog Šie ierobežojumi nosaka, cik daudz gaidošo savienojumu sistēma var apstrādāt, pirms tiek pārtrauktas paketes vai noraidīti saziņas mēģinājumi. Tīmekļa serveros ar lielu datplūsmu šo ierobežojumu palielināšana var novērst rindu pārslodzi un ievērojami samazināt slodzi. savienojuma kļūdas maksimālās slodzes laikā.

TCP savienojumu darbību var arī precīzi noregulēt ar daudzām opcijām: iespējot net.ipv4.tcp_window_scaling Lai atbalstītu lielus logus liela joslas platuma saitēs, iespējojiet net.ipv4.tcp_sack y net.ipv4.tcp_timestamps lai uzlabotu zudumu un retranslācijas pārvaldību vai pielāgotu net.ipv4.tcp_fin_timeout un vadība TIME_WAIT (net.ipv4.tcp_tw_reuse, net.ipv4.tcp_max_tw_buckets), lai kontrolētu resursu patēriņu serveros ar miljoniem īsu savienojumu minūtē.

Svarīga ir arī sastrēgumu kontroles algoritma izvēle. Lai gan cubic Daudzos izplatījumos tā joprojām ir noklusējuma vērtība; mainās uz bbr mūsdienu kodolos (4.9 un jaunākās versijās) net.ipv4.tcp_congestion_control y net.core.default_qdisc=fq Tas var reizināt TCP caurlaidspēju vidēs ar sarežģītiem zudumiem vai latentumiem, panākot uzlabojumus no 2 līdz 25 reizēm salīdzinājumā ar klasiskajām konfigurācijām noteiktos scenārijos, uz rēķina nedaudz atšķirīga uzvedība pārslogotos tīklos.

Mēs nedrīkstam aizmirst par tādiem drošības un uzticamības parametriem kā net.ipv4.tcp_syncookies, pāradresāciju apstrāde (net.ipv4.conf.all.accept_redirects, send_redirects) vai filtrēšana tiltos (net.bridge.bridge-nf-call-iptables Kubernetes vidēs). Pareizi konfigurēti, tie ļauj aizsargāt sistēmu no izplatītiem uzbrukumiem (SYN plūdiem, viltojumiem utt.), neupurējot stabila tīkla veiktspējaLai iegūtu praktisku rokasgrāmatu par noteikumiem un noteikšanu, skatiet Netfilter un Suricata ieviešana.

Failu sistēma, deskriptori un globālie ierobežojumi: fs.* un ulimit

Mūsdienu serveros zems failu deskriptoru ierobežojums ir ātrākais veids, kā uzlauzt sistēmu pīķa stundās. Kad tīmekļa serveris, reversais starpniekserveris vai datubāze saskaras ar klasisko kļūdu "pārāk daudz atvērtu failu", tas parasti ir tāpēc, ka kodola parametri un lietotāju ierobežojumi nebija pielāgoti faktiskajai slodzei.

Globāli, fs.file-max Tas norāda, cik deskriptoru kodolam kopumā var būt atvērti. Lietojumprogrammām ar tūkstošiem vienlaicīgu savienojumu parasti šo vērtību palielina līdz vairākiem miljoniem, kā arī palielina par fs.nr_openkas nosaka stingro deskriptoru maksimālo robežu katram procesam. Turklāt ir nepieciešamas korekcijas. /etc/security/limits.conf lai lietotājiem (vai systemd pārvaldītajiem pakalpojumiem) būtu mīkstās un cietās vērtības atbilst kodola konfigurācijai.

Inotify apakšsistēmu, ko plaši izmanto IDE, tīmekļa izstrādes rīki un failu uzraudzības sistēmas, kontrolē tādi parametri kā fs.inotify.max_user_watches y fs.inotify.max_user_instancesJa rodas kļūdas, kas saistītas ar novērotājiem vai procesiem, kuri pārtrauc diska izmaiņu uzraudzību, jums, iespējams, ir nepieciešams Palieliniet šos ierobežojumus, lai izvairītos no klusām sastrēgumiem.

Vēl viena svarīga funkcija ir asinhronā I/O (AIO), kuras globālais maksimums ir definēts ar fs.aio-max-nrLietojumprogrammās, kas lielā mērā balstās uz asinhronu I/O (daži datubāzu dzinēji, rindu sistēmas utt.), tā palielināšana novērš kodola laika nišu trūkumu AIO operācijām milzīgas pieprasījumu slodzes gadījumā.

Papildus šiem parametriem diska apakšsistēmas veiktspēju ietekmē arī I/O plānotājs konfigurēts katrā bloka ierīcē. Sistēmās ar SSD vai NVMe parasti ieteicams izmantot vieglus plānotājus, piemēram, none o mq-deadline, savukārt mehāniskajos diskos varētu būt jēgpilnākas citas iespējas, piemēram, bfq atkarībā no slodzes veida. Pielāgojiet plānotāju, izmantojot /sys/block/<disco>/queue/scheduler un precizējiet opcijas, piemēram, rindas dziļumu (nr_requests) vai read_ahead_kb var radīt ievērojamas pārmaiņas lasīšanas/rakstīšanas latentums un caurlaidspējaIr svarīgi arī ņemt vērā, kuras failu sistēmas un draiveri tiek izmantoti; piemēram, raksti par NTFSplus operētājsistēmā Linux un citas sistēmas var palīdzēt, projektējot heterogēnas slodzes.

Visbeidzot, nedrīkst aizmirst, ka šiem kodola ierobežojumiem jāiet roku rokā ar sistēmas konfigurācijām, piemēram, ulimit un systemd vienības, lai nodrošinātu, ka pakalpojumi faktiski var izmantot definētos papildu resursus un tos nebloķē ierobežojumi augšējos slāņos.

Kodola vispārīgā informācija, NUMA, CPU afinitāte un lielas lapas

Papildus tīklošanai, atmiņai un failu sistēmām pats kodols piedāvā virkni regulēšanas opciju, kas ietekmē procesu plānošanu, darba slodzes sadalījumu starp kodoliem un NUMA mezgliem, kā arī atmiņas pārvaldību mērogā. Mūsdienu iekārtās ar daudziem kodoliem un pat vairākām ligzdām šīs detaļas bieži vien nosaka, vai serveris ir līdzsvarots, un serveris, kurā daži kodoli ir piesātināti, bet citi ir nepietiekami izmantoti . Ir arī vērts izpētīt alternatīvus kodolus, piemēram, Liquorix kodolu, vidēs, kur vēlams atšķirīgs latentuma profils.

Parametri, piemēram, kernel.pid_max Tie nosaka maksimālo procesa ID diapazonu, ko sistēma var piešķirt, kas ir svarīgi mezgliem, kuros darbojas liels skaits konteineru vai īslaicīgu procesu. Kodola reģistrēšanas opciju pielāgošana (kernel.printk) palīdz samazināt pārmērīgu troksni dmesg, vienlaikus ierakstot kritiskus notikumus, kas arī netieši ietekmē diagnostikas iespējas un stabilitāte.

Attiecībā uz atmiņas topoloģiju parametrs kernel.numa_balancing Tas kontrolē, cik lielā mērā kodols automātiski pārvieto lapas starp NUMA mezgliem. Tā atspējošana noteiktās vidēs ļauj skaidrāk pārvaldīt procesu un atmiņas afinitāti, izmantojot tādus rīkus kā numactl lai nodrošinātu, ka procesora un RAM ietilpīgie procesi paliek vienā mezglā, samazinot latentums, kas rodas attālās piekļuves dēļLai labāk izprastu aparatūras un kodola plānošanas mijiedarbību, ir lietderīgi pārskatīt arī tādas tehnoloģijas kā Intel pavedienu vadītājs.

Milzīgās lapas (vm.nr_hugepagesTās ir vēl viena svarīga sastāvdaļa datubāzu sistēmās vai citās darba slodzēs, kas apstrādā lielus nepārtrauktas atmiņas apgabalus. Atbilstoša skaita milzīgu lapu rezervēšana (2 MB vai pat 1 GB atkarībā no arhitektūras) var samazināt TLB pieskaitāmās izmaksas un ievērojami uzlabot to lietojumprogrammu veiktspēju, kas darbojas. daudzas darbības ar lieliem atmiņas blokiemLai tas būtu efektīvi, kodola konfigurācijai jābūt saskaņotai ar pašu lietojumprogrammu, lai tā tieši izmantotu šo atmiņu.

Latentuma un plānošanas jomā ir plānotāja parametri, piemēram, kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns o kernel.sched_migration_cost_nsŠie iestatījumi precīzi noregulē katram uzdevumam piešķirto centrālā procesora "gabalu" lielumu un agresivitāti, ar kādu kodols pārvieto procesus starp kodoliem. Mazākas vērtības norāda uz sistēmu, kas ir vairāk pakļauta iepriekšējai izmantošanai un parasti piedāvā labākā atbilde interaktīviem uzdevumiem dažreiz uz nelielas neapstrādātas caurlaidspējas rēķina.

Sistēmās, kurās atmiņa ir sensitīvs resurss, daži administratori izvēlas aktivizēt panikas režīmu, ja rodas kļūda pēc instalēšanas (vm.panic_on_oom) un izveido kernel.panic ar automātiskas restartēšanas laiku. Šī stratēģija, lai arī nedaudz drastiska, var būt noderīga augstas pieejamības vidēs, kur Ātra un kontrolēta pārstartēšana ir vēlamāka nekā uzkarināts un nestabils resursdators. stundās.

Specializēti profili: tīmeklis, datubāzes, zema latentuma un Kubernetes

Tā vietā, lai izmantotu vienu brīnumlīdzekli, ir efektīvāk izveidot sysctl profilus, kas pielāgoti dažādiem darba slodžu veidiem: tīmekļa serveriem, datubāzēm, konteineru platformām vai sistēmām ar zemu latentumu. Šo iestatījumu izplatīšana failos, piemēram, 99-webserver.conf, 99-database.conf o 90-kubernetes.conf palīdzēt uzturēt organizētu un viegli versiju veidojamu konfigurācijuVarat apsvērt arī uz veiktspēju orientētus izplatījumus un izdevumus, piemēram, CachyOS servera versija ļoti specifiskām vidēm.

Tīmekļa serveriem (Nginx, Apache, starpniekservera serveriem utt.) būtiskākais ir apstrādāt lielu vienlaicīgu savienojumu apjomu ar lielām rindām un reakcijas laikiem. FIN_WAIT Pateicoties precīzai regulēšanai, paplašinātam īslaicīgo portu diapazonam un ļoti augstiem deskriptoru ierobežojumiem, HTTP pieprasījumu skaits parasti palielinās no dažiem simtiem sekundē līdz vairākiem tūkstošiem, tādējādi samazinot vidējo latentumu un novēršot kļūdas. piesātinātas rindas vai pilnas pieslēgvietas.

Datu bāzes pusē (MySQL, PostgreSQL un tamlīdzīgi) prioritāte tiek piešķirta minimālai mijmaiņas izmantošanai, netīrās lapas rakstīšanas precizēšanai un atbilstošiem koplietojamās atmiņas un semafora iestatījumiem dzinējam. Parametri, piemēram, kernel.shmmax, kernel.shmall, kernel.sem un milzīgā lapu konfigurācija rada atšķirību darījumi sekundē un atbildes laiks, daudzos scenārijos reizinot veiktspēju ar divi vai trīs, salīdzinot ar noklusējuma vērtībām.

Īpaši zemas latentuma lietojumprogrammām (tirdzniecība, tiešsaistes spēles, apstrāde reāllaikā) tiek pievienoti vēl specifiskāki iestatījumi: net.ipv4.tcp_low_latency, lēnas iedarbināšanas deaktivizēšana pēc neaktivitātes, lietošana tcp_fastopen, aizņemtas aptaujas parametri (net.core.busy_poll, busy_read) un daudzos gadījumos caurspīdīgu, milzīgu lapu deaktivizēšana, izmantojot /sys/kernel/mm/transparent_hugepage/enabledTas viss ir vērsts uz to, lai samazinātu apstrādes rindas un latentuma maksimums ir augsts procentīles līmenī, panākot iespaidīgus uzlabojumus P99.

Konteineru un Kubernetes vidēs tīkla steks un savienojumu izsekošana ir īpaši noslogoti. Tādi parametri kā net.ipv4.ip_forward, net.bridge.bridge-nf-call-iptables, net.netfilter.nf_conntrack_maxNodePort rezervēto portu izmantošana vai ARP tabulu pielāgošana ir izplatīta mezglos, kas apstrādā simtiem vai tūkstošiem podu. To pareiza pielāgošana novērš problēmas. saīsināti savienojumi, taimauti vai tabulas piesātinājums, izmantojot conntrack.

Papildus šiem specifiskajiem profiliem dažas organizācijas izvēlas uz veiktspēju orientētu arhīvu ar uzlabotu drošību, apvienojot lielus tīkla buferus un samazinātu maināmību ar tādiem pasākumiem kā tcp_syncookies vai bīstamu pāradresāciju bloķēšanu. Mērķis ir panākt līdzsvara punkts starp agresīvu sniegumu un saprātīgu sacietēšanu.

Kodola profilēšanas un uzraudzības rīki

Kodola pielāgošana bez mērīšanas ir kā audio miksera atskaņošana ar aizsietām acīm. Linux piedāvā rīku arsenālu, lai saprastu, ko sistēma patiesībā dara, sākot no vienkāršiem skaitītājiem līdz detalizētām kodola funkciju izsekošanas metodēm, kas ļauj korelēt konfigurācijas izmaiņas ar izmērāmiem efektiem.

Starp ikdienas lietderībām ir vmstat, iostat, sar, ss, slabtop, htop o pidstatkas sniedz ātru informāciju par procesiem, centrālo procesoru, ievadi/izvadi, ligzdām un kešatmiņas izmantošanu. Apvienojumā ar sistēmas žurnāliem un metrikām, kas eksportētas uz Prometheus, Grafana vai collectd, un ar resursiem, piemēram, uzlabots sistēmas monitors operētājsistēmai LinuxTie sniedz diezgan pilnīgu priekšstatu par to, kā saimnieks uzvedas pirms un pēc katras regulēšanas.

Lai iedziļinātos sīkāk, tādi rīki kā perf Tie ļauj profilēt centrālā procesora (CPU) izmantošanu funkciju līmenī gan lietotāja, gan kodola līmenī, reģistrējot notikumus dažas sekundes vai minūtes un pēc tam sniedzot interaktīvu pārskatu. perf stat, perf record y perf report jūs varat redzēt kur faktiski tiek patērēts centrālā procesora laiks un kāda daļa atbilst kodolam, identificējot, piemēram, pārtraukuma vētru vai slikti pielāgotu plānotāju.

Ja nepieciešama vēl lielāka detalizācija, ftrace Kodola izsekošanas apakšsistēma piedāvā iespēju aktivizēt noteiktus izsekotājus (piemēram, funkciju “tracer”) un reāllaikā vai pēc tam pārbaudīt, kādi izsaukumi notiek. Iespējot atbilstošo izsekotāju un analizēt tā saturu. /sys/kernel/debug/tracing/trace tas tev atklāj karstajiem punktiem pašā kodolāTas ir ļoti noderīgi, ja augsta līmeņa rādītāji nav pietiekami.

Paralēli ieteicams ieviest automatizētus uzraudzības skriptus, kas periodiski izgāž galvenos datus (tīkla statistiku, atmiņas skaitītājus, atvērto failu deskriptoru skaitu utt.) rotējošos žurnālos. Kad tiek sasniegti noteikti sliekšņi (piemēram, pārsniegts noteikts atvērto failu deskriptoru skaits), šie skripti var ģenerēt brīdinājumus pa e-pastu vai citiem kanāliem, palīdzot atklāt bīstamas tendences, pirms problēma saasinās.

Visbeidzot, ilgstošās stresa testēšanas fāzēs (24 stundas vai ilgāk), var izmantot tādus rīkus kā stress-ng apvienojumā ar nepārtrauktu rādītāju vākšanu (izmantojot vmstat, iostat, sar) ļauj novērtēt sistēmas stabilitāti ar jauno kodola konfigurāciju, pārbaudot, vai ilgstošas ​​slodzes laikā nav OOM notikumu, avāriju, negaidītas restartēšanas vai pakāpeniskas veiktspējas degradācijas.

Linux kodola optimizēšana ar sysctl un citiem mehānismiem nav vienreizējs uzdevums, bet gan iteratīvs process, kas ietver rezultātu mērīšanu, parametru pielāgošanu un visu rūpīgu dokumentēšanu. Ar skaidru metodoloģiju, specifiskiem profiliem katram darba slodzes veidam, spēcīgu profilēšanas rīku komplektu un stingru izmaiņu kontroli ir iespējams panākt serverus, kas pilnībā izmanto savu aparatūru, ar palielinātu caurlaidspēju, samazinātu latentumu un ievērojami lielāku stabilitāti nekā vispārējā rūpnīcas konfigurācijā.

Saistītais raksts:

Paplašināta rokasgrāmata Linux kodola optimizēšanai un latentuma samazināšanai