- Ang advanced kernel tuning gamit ang sysctl ay nagbibigay-daan sa iyong isaayos ang network, memory, mga file, at scheduler upang ma-maximize ang performance at stability.
- Mahalagang sukatin ang bago at pagkatapos ng pagbabago gamit ang mga benchmark at pagsubaybay upang mapatunayan ang tunay na epekto ng bawat pagbabago.
- Ang mga partikular na profile (web, mga database, mababang latency, Kubernetes) ay nakakamit ng mas mahusay na mga resulta kaysa sa isang generic na configuration lamang.
- Ang mga kagamitang gaya ng perf, ftrace, vmstat, at iostat ay nagpapadali sa paulit-ulit, ligtas, at obhetibong pag-optimize na batay sa datos.
Kung matagal ka nang namamahala ng mga Linux server, matutuklasan mo kalaunan na ang pagkakaiba sa pagitan ng isang pangkaraniwang sistema at ng isang sistemang tumatakbo sa ilalim ng mabigat na karga ay nasa kung gaano kahusay mong na-tune ang kernel. Hindi lamang ito tungkol sa pag-install ng mas maraming RAM o mas malakas na CPU: maraming bottleneck ang nareresolba sa pamamagitan ng pagsasaayos ng ilang maingat na piniling mga parameter.
Inilalantad ng kernel ang daan-daang opsyon sa network, memory, file system, at process scheduling na maaaring baguhin agad-agad. Gamit ang tool sysctl at ilang pagsasaayos sa /procPosibleng masulit ang hardware at makamit ang mas mababang latency, mas mataas na throughput, at mas mahusay na katatagan Nalalapat ito sa mga web server at database, pati na rin sa mga real-time na kapaligiran at Kubernetes. Gayunpaman, mahalagang malaman nang eksakto kung ano ang iyong ginagawa at kung paano ito susukatin.
Ano ang sysctl at paano nito inaayos ang mga parameter ng kernel?
Kagamitan sysctl Ito ang daan patungo sa pagbabago ng mga parameter ng kernel nang hindi kinakailangang i-recompile o i-reboot, na nagpapahintulot basahin at baguhin ang mga halaga sa oras ng pagpapatakbo para agad na subukan ang mga configuration. Ang mga parameter na ito ay nakaayos sa isang mababang hierarchical tree /proc/sys/at bawat isa ay kumokontrol sa isang partikular na pag-uugali ng sistema.
Ang mga setting ay nakagrupo sa magkakahiwalay na kategorya, na ginagawang madaling matukoy kung ano ang kailangan mong isaayos kapag nakakaranas ka ng isang partikular na isyu sa pagganap o katatagan. Ang istrukturang ito ay nagbibigay-daan sa iyong mag-focus, halimbawa, lamang sa network (net.*), memorya (vm.*), o file system (fs.*) nang hindi naliligaw sa iba pang mga opsyon sa kernel.
Ang mga pangunahing kategorya na makikita mo sa /proc/sys/ Kabilang dito, bukod sa iba pa:
- kernel.*: pangkalahatang mga opsyon sa kernel (scheduler, PID, messages, NUMA, atbp.).
- vm.*: pamamahala ng virtual memory, swap, mga cache at mga patakaran sa overcommit.
- lambat.*: IPv4/IPv6 network stack, mga TCP/UDP buffer, mga pila, pagkontrol ng congestion.
- fs.*: mga limitasyon ng mga deskriptor, inode, inotify, AIO at VFS na pag-uugali.
- pag-unlad*: mga partikular na parameter ng ilang partikular na device at driver.
may sysctl -a Maaari mong ilista ang lahat ng magagamit na mga parameter, at gamit ang mga utos tulad ng sysctl vm.swappiness o sysctl net.ipv4.tcp_tw_reuse pagbabasa ng mga partikular na halaga, na mahalaga sa suriin ang kasalukuyang configuration bago baguhin ang kahit ano. Para mahanap ang isang partikular na bagay, karaniwan ang pag-filter gamit ang grep, halimbawa: sysctl -a | grep tcp.
Ang pagbabago ng isang parameter nang mabilisan ay kasing simple ng paggamit ng sysctl -w clave=valorGayunpaman, mahalagang maunawaan na ang mga pagbabagong ito ay pansamantala lamang. Upang mai-save ang mga ito pagkatapos ng pag-reboot, mahalagang i-back up ang configuration sa /etc/sysctl.conf o sa mga file ng /etc/sysctl.d/, karaniwang gumagamit ng mga file na may numero (halimbawa 10-network.conf, 20-memory.conf, 99-custom.conf) na tumutukoy sa pagkakasunud-sunod kung paano inilalapat ang mga ito.
Sukatin bago ka humawak: mga benchmark at baseline ng sistema
Bago ka magsimulang mag-isip ng mga dial, makabubuting magtakda ng isang obhetibong baseline ng pagganap . Kung walang naunang datos, imposibleng malaman kung ang mga pagbabago ay nagpabuti o nagpalala sa sistema, at mahuhulog ka sa klasikong patibong na "mas mabuti na ito para sa akin," na walang silbi sa paggawa ng matalinong mga desisyon.
Sa antas ng buong sistema, mainam na kolektahin ang mga istatistika ng CPU, load, memory, disk, at network sa loob ng ilang minuto sa ilalim ng isang representatibong load. Mga kagamitan tulad ng uptime, mpstat, vmstat, iostat -x o sar -n DEV Pinapayagan ka nitong makita kung paano kumikilos ang stock kernel, kung gaano karaming swap ang ginagamit nito, kung paano tumutugon ang disk I/O, at kung ang network ay saturated o nagsasayang ng bandwidth.
Bukod sa pangkalahatang-ideya na iyon, mahalagang magpatakbo ng mga partikular na benchmark para sa application na gusto mong i-optimize. Sa mga web server, maaari mong gamitin ang ab (Apache Bench) o mga katulad na kagamitan para sa pagsukat mga kahilingan kada segundo, average na latency, at mga errorSa mga database, ang mga utility tulad ng mysqlslap o sysbench Nakakatulong ang mga ito sa pagsusuri ng mga transaksyon kada segundo at mga oras ng pagtatanong.
Halimbawa, sa isang senaryo na walang pag-tune, karaniwan na makahanap ng mga numero tulad ng 500 HTTP request/s na may average na oras ng pagtugon na 200 ms, humigit-kumulang 250 SQL query/s na may 40 ms latency, bilis ng network na humigit-kumulang 500 Mbps, at isang system load na malapit sa limitasyon nito sa ilalim ng stress. Ang mga numerong ito ay gagamitin upang mapatunayan, pagkatapos ilapat ang mga pagbabago sa kernel, kung ang isang masusukat na pagtaas sa throughput at pagbawas sa latency ay talagang nakakamit.
Panghuli, idokumento ang mga utos at resulta bago gumawa ng anumang pagbabago. Ang pagkakaroon ng history ay magbibigay-daan sa iyo na tumpak na ihambing ang iba't ibang batch ng mga pagsasaayos at makakatulong din sa iyo na matukoy ang mga regresyon pagkatapos ng pag-update ng kernel o pagkatapos magpakilala ng bagong sysctl profile sa produksyon.
Mga advanced na setting ng memorya: vm.*
Ang memorya ay isa sa mga subsystem kung saan pinakamapansin ang mga pagbabago sa kernel. Ang isang server na may maraming RAM, ngunit hindi maayos ang pagkaka-configure, ay maaaring hindi kinakailangang gumamit ng swap space, na nagiging sanhi... Mga pagtaas ng I/O at matinding pagbaba ng performanceKaya naman ang mga parameter tulad ng vm.swappinessAng mga dirty page ratio o ang pag-uugali ng VFS cache ay kasinghalaga rin.
Parameter vm.swappiness Kinokontrol nito kung gaano karaming mga pahina ng memorya ang ipinapadala ng kernel upang ipagpalit. Sa maraming distribusyon, nakatakda ito sa 60, isang halagang inilaan para sa magkahalong desktop environment. Para sa mga database server o mga low-latency na application, karaniwang mas mainam na ibaba ito sa 10 o mas mababa pa, na nagreresulta sa isang mas mahusay na sistema. unahin ang pagpapanatili ng data sa RAM at bawasan ang pagpapalitHindi pangkaraniwan na makakita ng pagbaba ng trapiko sa disk at mas kaunting jitter ang tumutugon sa mga application pagkatapos ng pagsasaayos na ito.
Ang isa pang pangunahing bloke ng gusali ay vm.dirty_ratio y vm.dirty_background_ratioAng mga halagang ito ang nagtatakda kung anong porsyento ng memorya ang maaaring mapuno ng mga maruruming pahina bago simulan ng kernel na i-flush ang mga ito sa disk. Ang mga labis na mataas na halaga ay maaaring humantong sa malalaking pagsabog ng mga write, na may malalaking latency para sa lahat ng aplikasyon kapag naganap ang flush. Ang pagbabawas ng mga porsyentong ito sa mga numerong tulad ng 15 at 5, ayon sa pagkakabanggit, ay karaniwang nagreresulta sa isang mas pare-pareho at nahuhulaang padron ng I/O.
Ang setting ng vm.vfs_cache_pressure Tinutukoy nito kung gaano kaagresibo ang pagpupurga ng kernel sa mga inode at directory cache. Ang default na halaga na 100 ay may posibilidad na mabilis na magpurga ng cache, habang ang mga setting na nasa bandang 50 ay nagbibigay-daan sa metadata na mapanatili nang mas matagal, na nagpapataas ng hit rate para sa mga operasyon ng file at nagpapabuti ng pagganap. ang nakikitang pagganap ng file system, isang bagay na susi sa mga server na humahawak ng milyun-milyong maliliit na file.
Para sa bahagi nito, vm.min_free_kbytes Maglaan ng kaunting libreng memorya upang matiyak na makakatugon ang sistema sa mga biglaang pag-allocate nang hindi nakakaranas ng mga biglaang out-of-box (OOB) na sitwasyon. Ang paglalagay nito sa humigit-kumulang 0,5% hanggang 1% ng kabuuang RAM ay karaniwang isang epektibong hakbang sa kaligtasan upang maiwasan ang pagkaubusan ng espasyo sa kernel sa ilalim ng matinding load at pagsisimulang pumatay sa mga kritikal na proseso, sa gayon ay mapapabuti ang pagganap. pangkalahatang katatagan ng host.
Panghuli, ang patakaran sa overcommit ay nararapat bigyan ng pansin: mga parametro tulad ng vm.overcommit_memory y vm.overcommit_ratio Tinutukoy nila kung gaano karaming virtual memory ang inilalaan sa mga proseso kaugnay ng magagamit na RAM at swap. Sa ilang mga kaso (halimbawa, sa Redis o ilang mga database) pinapayagan ang agresibong labis na pangako, habang sa iba ay mas mainam ang isang mas konserbatibong patakaran upang limitahan ang panganib ng OOM at mga sitwasyon ng labis na nakompromisong memoryaPara sa mga pamamaraan para sa pagsusuri at pag-diagnose ng mga kumplikadong kaso, kumonsulta sa pag-debug ng memorya sa Linux.
Mas mataas na pag-optimize ng network: net.* at TCP/IP
Ang network stack marahil ang lugar kung saan ang pag-tune ay pinakakapansin-pansin sa mga kapaligiran ng produksyon. Ang isang simpleng pagbabago sa mga pila ng koneksyon o mga buffer ay maaaring gumawa ng pagkakaiba sa pagitan ng isang server na nag-choke sa 500 Mbps at isa na Madali nitong nababad ang gigabit.Ang mga parametro sa ilalim net.core.* y net.ipv4.* Sa aspetong ito, sila ang iyong pinakamahuhusay na kakampi.
Bilang panimula, ang laki ng socket buffer ay direktang nakakaimpluwensya sa maximum throughput ng isang koneksyon, lalo na kapag may mataas na latency o mga link na may mataas na kapasidad. net.core.rmem_max y net.core.wmem_max sa mga mapagbigay na halaga (sampu o daan-daang megabyte) at tukuyin nang tama net.ipv4.tcp_rmem y net.ipv4.tcp_wmem (minimum, default na halaga at maximum) ay nagbibigay-daan sa bawat socket na magkaroon ng espasyong kailangan para mabawasan ang pagsisikip ng trapiko nang hindi nahuhulog sa mga artipisyal na paghihigpit na ipinataw ng mga napaka-konserbatibong halaga ng pabrika.
Isa pang mahalagang punto ay ang laki ng mga pila ng koneksyon. Mga parameter tulad ng net.core.somaxconn, net.core.netdev_max_backlog y net.ipv4.tcp_max_syn_backlog Tinutukoy ng mga limitasyong ito kung gaano karaming nakabinbing koneksyon ang kayang hawakan ng system bago mag-drop ng mga packet o tanggihan ang mga handshake. Sa mga web server na may mataas na trapiko, ang pagtaas ng mga limitasyong ito ay maaaring maiwasan ang saturated queues at lubos na mabawasan ang load. mga error sa koneksyon sa panahon ng peak load.
Maaari ring i-fine-tune ang kilos ng mga koneksyon ng TCP gamit ang maraming opsyon: paganahin net.ipv4.tcp_window_scaling Para suportahan ang malalaking window sa mga high-bandwidth link, paganahin ang net.ipv4.tcp_sack y net.ipv4.tcp_timestamps upang mapabuti ang pamamahala ng pagkawala at muling paghahatid, o ayusin net.ipv4.tcp_fin_timeout at ang pamamahala ng TIME_WAIT (net.ipv4.tcp_tw_reuse, net.ipv4.tcp_max_tw_buckets) upang makontrol ang pagkonsumo ng mapagkukunan sa mga server na may milyun-milyong maiikling koneksyon kada minuto.
Mahalaga rin ang pagpili ng algorithm para sa pagkontrol ng pagsisikip. Bagama't cubic Ito ay nananatiling default na halaga sa maraming distribusyon; nagbabago sa bbr sa mga modernong kernel (4.9 at mas bago) ni net.ipv4.tcp_congestion_control y net.core.default_qdisc=fq Kaya nitong paramihin ang TCP throughput sa mga kapaligirang may mga kumplikadong pagkalugi o latency, na nakakamit ng mga pagpapabuti sa pagitan ng 2 at 25 beses kumpara sa mga klasikong configuration sa ilang partikular na sitwasyon, sa halaga ng medyo kakaibang pag-uugali sa mga siksik na network.
Hindi natin dapat kalimutan ang mga parametro ng kaligtasan at pagiging maaasahan tulad ng net.ipv4.tcp_syncookies, ang paghawak ng mga pag-redirect (net.ipv4.conf.all.accept_redirects, send_redirects) o pag-filter sa mga tulay (net.bridge.bridge-nf-call-iptables sa mga kapaligirang Kubernetes). Kapag maayos na na-configure, pinapayagan ka nitong protektahan ang sistema mula sa mga karaniwang pag-atake (SYN flood, spoofing, atbp.) nang hindi isinasakripisyo ang isang matatag na pagganap ng networkPara sa praktikal na gabay sa mga patakaran at pagtuklas, tingnan ang Implementasyon ng Netfilter at Suricata.
Sistema ng file, mga deskriptor, at mga pandaigdigang limitasyon: fs.* at ulimit
Sa mga modernong server, ang mababang limitasyon sa deskriptor ng file ang pinakamabilis na paraan upang masira ang isang sistema sa mga oras na peak hours. Kapag ang isang web server, reverse proxy, o database ay nakatagpo ng klasikong error na "too many open files", kadalasan ito ay dahil ang mga parameter ng kernel at mga limitasyon ng user ay hindi na-scale para sa aktwal na load.
Sa isang pandaigdigang antas, fs.file-max Tinutukoy nito kung gaano karaming descriptor ang maaaring buksan ng kernel sa kabuuan. Para sa mga aplikasyon na may libu-libong sabay-sabay na koneksyon, karaniwan na tataas ang halagang ito sa ilang milyon, kasama ang pagtaas ng fs.nr_openna siyang nagtatakda ng mahigpit na limitasyon para sa mga deskriptor bawat proseso. Bukod pa rito, kailangan ang mga pagsasaayos. /etc/security/limits.conf upang ang mga gumagamit (o mga serbisyong pinamamahalaan ng systemd) ay magkaroon malambot at matigas na mga halaga na naaayon sa pagsasaayos ng kernel.
Ang inotify subsystem, na malawakang ginagamit ng mga IDE, mga tool sa pagbuo ng web, at mga sistema ng pagsubaybay sa file, ay kinokontrol ng mga parameter tulad ng fs.inotify.max_user_watches y fs.inotify.max_user_instancesKung makakaranas ka ng mga error na may kaugnayan sa mga watcher o mga prosesong humihinto sa pagsubaybay sa mga pagbabago sa disk, malamang na kailangan mo Taasan ang mga limitasyong ito upang maiwasan ang mga tahimik na bottleneck.
Ang isa pang mahalagang katangian ay ang asynchronous I/O (AIO), na ang pandaigdigang pinakamataas ay tinukoy gamit ang fs.aio-max-nrSa mga aplikasyon na lubos na umaasa sa asynchronous I/O (ilang partikular na database engine, queuing system, atbp.), ang pagpapataas nito ay pumipigil sa kernel na maubusan ng mga slot para sa mga operasyon ng AIO sa ilalim ng isang napakalaking request load.
Bukod sa mga parameter na ito, ang pagganap ng disk subsystem ay apektado ng Taga-iskedyul ng I/O naka-configure sa bawat block device. Sa mga system na may SSD o NVMe, karaniwang inirerekomenda na gumamit ng mga magaan na scheduler tulad ng none o mq-deadline, habang sa mga mechanical disc, maaaring may katuturan ang iba pang mga opsyon, tulad ng bfq depende sa uri ng load. Ayusin ang scheduler sa pamamagitan ng /sys/block/<disco>/queue/scheduler at pinuhin ang mga opsyon tulad ng lalim ng pila (nr_requests) o ang read_ahead_kb maaaring makagawa ng kapansin-pansing pagkakaiba sa latency at throughput ng pagbasa/pagsulatMahalaga ring isaalang-alang kung aling mga file system at driver ang ginagamit; halimbawa, mga artikulo tungkol sa NTFSplus sa Linux at iba pang mga sistema ay makakatulong kapag nagdidisenyo ng mga heterogeneous na load.
Panghuli, hindi dapat kalimutan na ang mga limitasyong ito ng kernel ay dapat na kasabay ng mga konpigurasyon ng sistema tulad ng sa ulimit at mga systemd unit, upang matiyak na magagamit talaga ng mga serbisyo ang tinukoy na karagdagang mga mapagkukunan at hindi naharangan ng mga paghihigpit sa itaas na mga layer.
Pangkalahatan ng Kernel, NUMA, CPU affinity, at malalaking pahina
Higit pa sa networking, memorya, at mga file system, ang kernel mismo ay nag-aalok ng iba't ibang opsyon sa pag-tune na nakakaimpluwensya sa kung paano naka-iskedyul ang mga proseso, kung paano ipinamamahagi ang mga workload sa mga core at NUMA node, at kung paano pinamamahalaan ang memorya nang malawakan. Sa mga modernong makina na may maraming core at maging maraming socket, ang mga detalyeng ito ay kadalasang gumagawa ng pagkakaiba sa pagitan ng isang balanseng server at isa na may ilang core na saturated habang ang iba ay hindi gaanong nagagamit . Sulit ding tuklasin ang mga alternatibong kernel tulad ng Liquorix kernel sa mga kapaligiran kung saan ninanais ang ibang latency profile.
Mga parameter tulad ng kernel.pid_max Itinatakda nila ang pinakamataas na saklaw ng mga process ID na maaaring italaga ng sistema, na mahalaga para sa mga node na nagpapatakbo ng maraming bilang ng mga container o mga panandaliang proseso. Pagsasaayos ng mga opsyon sa pag-log ng kernel (kernel.printk) nakakatulong na mabawasan ang labis na ingay sa dmesg habang nire-record pa rin ang mga kritikal na kaganapan, na hindi rin direktang nakakaimpluwensya sa kakayahan at katatagan sa pag-diagnose.
Tungkol sa topolohiya ng memorya, ang parameter kernel.numa_balancing Kinokontrol nito ang lawak kung saan awtomatikong inililipat ng kernel ang mga pahina sa pagitan ng mga NUMA node. Ang pag-disable nito sa ilang partikular na kapaligiran ay nagbibigay-daan para sa mas tahasang pamamahala ng proseso at pagkakaugnay ng memorya, gamit ang mga tool tulad ng numactl upang matiyak na ang mga prosesong masinsinang gumagamit ng CPU at RAM ay mananatili sa iisang node, na binabawasan ang latency na nagreresulta mula sa malayuang pag-accessUpang mas maunawaan ang interaksyon sa pagitan ng hardware at core scheduling, makakatulong din na suriin ang mga teknolohiya tulad ng Direktor ng Intel Thread.
Ang malalaking pahina (vm.nr_hugepagesIto ay isa pang mahalagang bahagi sa mga sistema ng database o iba pang mga workload na humahawak sa malalaking rehiyon ng magkakasunod na memorya. Ang pagrereserba ng angkop na bilang ng malalaking pahina (2 MB o kahit 1 GB, depende sa arkitektura) ay maaaring makabawas sa TLB overhead at makabuluhang mapabuti ang pagganap ng mga application na tumatakbo. maraming operasyon sa malalaking bloke ng memoryaPara maging epektibo ito, ang configuration ng kernel ay dapat na ikoordina sa mismong aplikasyon, upang magamit nito nang malinaw ang memoryang iyon.
Sa larangan ng latency at scheduling, may mga parameter ng scheduler tulad ng kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns o kernel.sched_migration_cost_nsPinupino ng mga setting na ito ang laki ng mga "chunk" ng CPU na inilaan sa bawat gawain at ang agresibong paggamit ng kernel sa paglipat ng mga proseso sa pagitan ng mga core. Ang mas maliliit na halaga ay kumakatawan sa isang mas madaling maunahan na sistema, na may posibilidad na mag-alok pinakamahusay na sagot para sa mga interactive na gawain sa halaga, minsan, ng kaunting raw throughput.
Sa mga sistema kung saan ang memorya ay isang sensitibong mapagkukunan, pinipili ng ilang administrador na i-activate ang panic mode kung sakaling magkaroon ng out-of-box error (vm.panic_on_oom) at maitaguyod kernel.panic na may awtomatikong oras ng pag-restart. Ang estratehiyang ito, bagama't medyo matindi, ay maaaring maging kapaki-pakinabang sa mga kapaligirang may mataas na availability kung saan Mas mainam ang mabilis at kontroladong pag-reboot kaysa sa isang hung at unstable na host. sa mga oras.
Mga espesyalisadong profile: web, mga database, mababang latency at Kubernetes
Sa halip na gumamit ng iisang magic bullet, mas epektibo ang paglikha ng mga sysctl profile na iniayon sa iba't ibang uri ng workload: mga web server, database, container platform, o mga low-latency system. Ipinamamahagi ang mga setting na ito sa mga file tulad ng 99-webserver.conf, 99-database.conf o 90-kubernetes.conf tumulong sa mapanatili ang isang organisado at madaling bersyong configurationMaaari mo ring isaalang-alang ang mga distribusyon at edisyon na nakatuon sa pagganap tulad ng Edisyon ng CachyOS Server para sa mga napaka-espesipikong kapaligiran.
Para sa mga web server (Nginx, Apache, mga proxy, atbp.), ang mahalagang bagay ay ang paghawak ng malalaking volume ng sabay-sabay na koneksyon na may mahahabang pila at oras ng pagtugon. FIN_WAIT Sa pamamagitan ng fine-tuning, pinalawak na panandaliang saklaw ng port, at napakataas na mga limitasyon sa descriptor, karaniwan nang lumipat mula sa ilang daang kahilingan ng HTTP bawat segundo patungo sa ilang libo, na binabawasan ang average na latency at inaalis ang mga error. mga punong pila o mga punong port.
Sa panig ng database (MySQL, PostgreSQL, at mga katulad nito), binibigyang-prayoridad ang minimal na paggamit ng swap, pag-aayos ng maruming pagsulat ng pahina, at angkop na mga setting ng shared memory at semaphore para sa engine. Mga parameter tulad ng kernel.shmmax, kernel.shmall, kernel.sem at ang malaking konpigurasyon ng mga pahina ay nakakagawa ng pagkakaiba sa mga tuntunin ng mga transaksyon bawat segundo at oras ng pagtugon, pinararami ang pagganap ng dalawa o tatlo kumpara sa mga default na halaga sa maraming sitwasyon.
Para sa mga aplikasyon na may napakababang latency (trading, online gaming, real-time processing), mas tiyak na mga setting ang idinaragdag: net.ipv4.tcp_low_latency, pag-deactivate ng mabagal na pagsisimula pagkatapos ng kawalan ng aktibidad, paggamit ng tcp_fastopen, abalang mga parameter ng botohan (net.core.busy_poll, busy_read) at, sa maraming pagkakataon, ang pag-deactivate ng mga transparent na malalaking pahina sa pamamagitan ng /sys/kernel/mm/transparent_hugepage/enabledAng lahat ng ito ay naglalayong bawasan ang mga peak ng processing queue at latency sa matataas na percentile, na nakakamit ng mga kahanga-hangang pagpapabuti sa P99.
Sa mga kapaligirang container at Kubernetes, ang network stack at connection tracking ay nasa ilalim ng partikular na stress. Ang mga parameter tulad ng net.ipv4.ip_forward, net.bridge.bridge-nf-call-iptables, net.netfilter.nf_conntrack_maxAng paggamit ng mga nakareserbang port para sa NodePort o ang pagsasaayos ng mga ARP table ay karaniwan sa mga node na humahawak ng daan-daan o libu-libong pod. Ang wastong pagsasaayos ng mga ito ay nakakaiwas sa mga problema. mga pinutol na koneksyon, mga timeout, o saturation ng talahanayan gamit ang conntrack.
Bukod sa mga partikular na profile na ito, ang ilang organisasyon ay pumipili ng isang archive na nakatuon sa pagganap na may pinahusay na seguridad, na pinagsasama ang malalaking network buffer at nabawasang swappiness na may mga hakbang tulad ng tcp_syncookies o ang pagharang sa mga mapanganib na pag-redirect. Ang layunin ay makamit ang isang punto ng balanse sa pagitan ng agresibong pagganap at makatwirang pagpapatigas.
Mga tool sa pag-profile at pagsubaybay sa kernel
Ang pag-aayos ng kernel nang hindi sinusukat ay parang pagpapatugtog ng audio mixer nang nakapiring. Nag-aalok ang Linux ng maraming kagamitan upang maunawaan kung ano talaga ang ginagawa ng system, mula sa mga simpleng counter hanggang sa detalyadong bakas ng mga function ng kernel, na nagbibigay-daan sa iyong iugnay ang mga pagbabago sa configuration sa mga nasusukat na epekto.
Kabilang sa mga pang-araw-araw na kagamitan ay vmstat, iostat, sar, ss, slabtop, htop o pidstatna nagbibigay ng mabilis na impormasyon tungkol sa mga proseso, CPU, I/O, mga socket, at paggamit ng cache. Kasama ang mga system log at metric na na-export sa Prometheus, Grafana, o nakolekta, at sa mga resources tulad ng advanced na monitor ng sistema para sa LinuxNagbibigay ang mga ito ng kumpletong larawan kung paano kumikilos ang host bago at pagkatapos ng bawat pag-tune.
Para sa mas detalyadong pagtalakay, ang mga kagamitan tulad ng perf Pinapayagan nila ang pag-profile ng paggamit ng CPU sa antas ng function, kapwa user at kernel, pag-log ng mga kaganapan sa loob ng ilang segundo o minuto at pagkatapos ay pagbibigay ng isang interactive na ulat. perf stat, perf record y perf report maaari mong makita ang kung saan ang oras ng CPU ay aktwal na nauubos at kung anong bahagi ang tumutugma sa core, pagtukoy, halimbawa, ng isang bagyo ng pagkaantala o isang hindi maayos na naayos na scheduler.
Kung kailangan mo ng mas detalyadong impormasyon, ftrace Ang tracing subsystem ng kernel ay nag-aalok ng kakayahang i-activate ang mga partikular na tracer (halimbawa, ang function tracer) at suriin sa real time o post-mortem kung anong mga tawag ang nagaganap. Pag-enable sa naaangkop na tracer at pagsusuri sa mga nilalaman nito /sys/kernel/debug/tracing/trace isiniwalat nito sa iyo mga hotspot sa loob mismo ng kernelIto ay lubhang kapaki-pakinabang kapag ang mga sukatan na may mataas na antas ay hindi sapat.
Kasabay nito, ipinapayong ipatupad ang mga automated monitoring script na pana-panahong naglalagay ng mga pangunahing datos (mga istatistika ng network, mga memory counter, bilang ng mga bukas na file descriptor, atbp.) sa mga umiikot na log. Kapag naabot na ang ilang partikular na limitasyon (halimbawa, paglampas sa isang tinukoy na bilang ng mga bukas na file descriptor), maaaring makabuo ang mga script na ito ng mga alerto sa pamamagitan ng email o iba pang mga channel, na makakatulong upang matukoy ang mga mapanganib na trend bago lumala ang isang problema.
Panghuli, sa matagalang mga yugto ng stress testing (24 oras o higit pa), ang mga kagamitan tulad ng stress-ng sinamahan ng patuloy na pangongolekta ng mga sukatan (sa pamamagitan ng vmstat, iostat, sar) ay nagbibigay-daan sa iyong masuri ang katatagan ng sistema gamit ang bagong configuration ng kernel, na nagpapatunay na walang mga kaganapan sa OOM, pag-crash, hindi inaasahang pag-restart o progresibong pagbaba ng pagganap sa ilalim ng patuloy na load.
Ang pag-optimize ng Linux kernel gamit ang sysctl at iba pang mga mekanismo ay hindi isang minsanang gawain, kundi isang paulit-ulit na proseso na kinasasangkutan ng pagsukat ng mga resulta, pagsasaayos ng mga parameter, at maingat na pagdodokumento ng lahat. Gamit ang isang malinaw na metodolohiya, mga partikular na profile para sa bawat uri ng workload, isang mahusay na hanay ng mga tool sa pag-profile, at mahigpit na kontrol sa pagbabago, posible na makamit ang mga server na ganap na gumagamit ng kanilang hardware, na may mas mataas na throughput, nabawasang latency, at mas mataas na katatagan kaysa sa generic factory configuration.
