Pengoptimuman kernel Linux lanjutan dengan sysctl

Informatec Digital » Sumber » Pengoptimuman kernel Linux lanjutan dengan sysctl

Jika anda telah menguruskan pelayan Linux untuk seketika, lambat laun anda akan mendapati perbezaan antara sistem biasa dan sistem yang lalat di bawah beban berat Semuanya tentang bagaimana anda telah menala kernel anda. Ia bukan sekadar memasang lebih banyak RAM atau CPU yang lebih berkuasa: banyak kesesakan diselesaikan dengan mengubah suai beberapa parameter yang dipilih dengan teliti.

Kernel mendedahkan beratus-ratus pilihan penjadualan rangkaian, memori, sistem fail dan proses yang boleh diubah suai dengan pantas. Dengan alat ini sysctl dan beberapa pelarasan dalam /procAdalah mungkin untuk memanfaatkan sepenuhnya perkakasan dan mencapai latensi yang lebih rendah, daya pemprosesan yang lebih tinggi dan kestabilan yang lebih baik Ini terpakai kepada pelayan web dan pangkalan data, serta persekitaran masa nyata dan Kubernetes. Walau bagaimanapun, adalah penting untuk mengetahui dengan tepat apa yang anda lakukan dan cara mengukurnya.

Apakah sysctl dan bagaimana ia mengatur parameter kernel?

Utiliti sysctl Ia merupakan pintu masuk untuk menukar parameter kernel tanpa perlu mengkompil semula atau but semula, yang membolehkan baca dan ubah suai nilai semasa runtime untuk menguji konfigurasi serta-merta. Parameter ini disusun dalam pokok hierarki rendah /proc/sys/dan setiap satunya mengawal tingkah laku sistem yang tertentu.

Tetapan dikumpulkan ke dalam kategori yang berbeza, menjadikannya mudah untuk menentukan apa yang perlu anda ubah suai apabila anda mempunyai masalah prestasi atau kestabilan yang sangat khusus. Terima kasih kepada struktur ini, anda boleh fokus, contohnya, hanya pada rangkaian (net.*), memori (vm.*) atau sistem fail (fs.*) tanpa tersesat dalam pilihan kernel yang lain.

Kategori utama yang akan anda temui dalam /proc/sys/ Ini termasuk, antara lain:

• inti.*: pilihan kernel umum (penjadual, PID, mesej, NUMA, dll.).
• vm.*: pengurusan memori maya, swap, cache dan dasar overcommit.
• bersih.*: Tindanan rangkaian IPv4/IPv6, penimbal TCP/UDP, giliran, kawalan kesesakan.
• fs.*: had deskriptor, inod, inotify, tingkah laku AIO dan VFS.
• pembangunan*: parameter khusus bagi peranti dan pemacu tertentu.

dengan sysctl -a Anda boleh menyenaraikan semua parameter yang tersedia, dan dengan arahan seperti sysctl vm.swappiness o sysctl net.ipv4.tcp_tw_reuse membaca nilai-nilai tertentu, yang merupakan kunci kepada audit konfigurasi semasa sebelum mengubah apa-apa. Untuk mencari sesuatu yang khusus, adalah perkara biasa untuk menapis dengan grep, sebagai contoh: sysctl -a | grep tcp.

Mengubah suai parameter dengan pantas semudah menggunakan sysctl -w clave=valorWalau bagaimanapun, adalah penting untuk memahami bahawa perubahan ini adalah sementara. Untuk menyimpannya selepas but semula, adalah penting untuk membuat sandaran konfigurasi ke /etc/sysctl.conf atau dalam fail-fail /etc/sysctl.d/, biasanya menggunakan fail bernombor (contohnya 10-network.conf, 20-memory.conf, 99-custom.conf) yang menentukan susunan penggunaannya.

Ukur sebelum anda menyentuh: penanda aras dan garis dasar sistem

Sebelum anda mula memusingkan dail dengan begitu pantas, adalah idea yang baik untuk menetapkan garis dasar prestasi objektifTanpa data terdahulu, mustahil untuk mengetahui sama ada perubahan telah menambah baik atau memburukkan lagi sistem, dan anda akan terikut-ikut dengan tafsiran klasik "nampaknya ia semakin baik", yang tidak berguna untuk membuat keputusan yang serius.

Pada peringkat seluruh sistem, adalah idea yang baik untuk mengumpul statistik CPU, beban, memori, cakera dan rangkaian selama beberapa minit di bawah beban yang representatif. Alatan seperti uptime, mpstat, vmstat, iostat -x o sar -n DEV Ia membolehkan anda melihat bagaimana kernel stok berfungsi, berapa banyak swap yang digunakannya, bagaimana I/O cakera bertindak balas dan sama ada rangkaian tepu atau membuang lebar jalur.

Selain gambaran keseluruhan itu, adalah penting untuk menjalankan penanda aras khusus untuk aplikasi yang ingin anda optimumkan. Pada pelayan web, anda boleh menggunakan ab (Apache Bench) atau alat serupa untuk mengukur permintaan sesaat, purata kependaman dan ralatDalam pangkalan data, utiliti seperti mysqlslap o sysbench Mereka membantu menilai transaksi sesaat dan masa pertanyaan.

Contohnya, dalam senario tanpa penalaan, adalah perkara biasa untuk menemui angka seperti 500 permintaan HTTP/s dengan purata masa tindak balas 200 ms, sekitar 250 pertanyaan SQL/s dengan latensi 40 ms, kelajuan rangkaian kira-kira 500 Mbps dan beban sistem hampir mencapai hadnya di bawah tekanan. Nombor-nombor ini akan digunakan untuk mengesahkan, selepas menggunakan perubahan kernel, sama ada penambahbaikan yang ketara benar-benar dicapai. peningkatan daya pemprosesan yang boleh diukur dan penurunan latensi.

Akhir sekali, dokumentasikan arahan dan hasil yang diperoleh sebelum menyentuh apa-apa. Mempunyai sejarah akan membolehkan anda membandingkan dengan teliti set pelarasan yang berbeza, dan juga berguna untuk Kesan regresi selepas kemas kini kernel atau selepas memperkenalkan profil sysctl baharu ke dalam pengeluaran.

Tetapan memori lanjutan: vm.*

Memori merupakan salah satu subsistem di mana perubahan kernel paling ketara. Pelayan dengan RAM yang banyak, tetapi dikonfigurasikan dengan buruk, boleh menggunakan ruang swap secara tidak perlu, menyebabkan... Lonjakan I/O dan penurunan prestasi yang drastikItulah sebabnya parameter seperti vm.swappinessNisbah halaman kotor atau tingkah laku cache VFS adalah sama pentingnya.

Parameter vm.swappiness Ini mengawal berapa banyak halaman memori yang dihantar oleh kernel untuk ditukar. Dalam banyak pengedaran, ia ditetapkan kepada 60, nilai yang bertujuan untuk persekitaran desktop campuran. Untuk pelayan pangkalan data atau aplikasi latensi rendah, biasanya lebih baik menurunkannya kepada 10 atau kurang, menghasilkan sistem yang lebih cekap. Utamakan penyimpanan data dalam RAM dan kurangkan pertukaranBukan sesuatu yang luar biasa untuk melihat trafik cakera merosot dan aplikasi bertindak balas dengan kurang jitter selepas pelarasan ini.

Satu lagi blok binaan asas ialah vm.dirty_ratio y vm.dirty_background_ratioNilai-nilai ini menentukan peratusan memori yang boleh diisi dengan halaman kotor sebelum kernel mula membuangnya ke cakera. Nilai yang terlalu tinggi boleh menyebabkan letusan penulisan yang besar, dengan latensi yang besar untuk semua aplikasi apabila pembuangan berlaku. Mengurangkan peratusan ini kepada angka seperti 15 dan 5, masing-masing, biasanya mengakibatkan corak I/O yang lebih konsisten dan boleh diramal.

Penetapan daripada vm.vfs_cache_pressure Ini menentukan betapa agresifnya kernel membersihkan cache inode dan direktori. Nilai lalai 100 cenderung untuk membersihkan cache dengan cepat, manakala tetapan sekitar 50 membolehkan metadata dikekalkan lebih lama, meningkatkan kadar hit untuk operasi fail dan meningkatkan prestasi. prestasi sistem fail yang dirasakan, sesuatu yang penting dalam pelayan yang mengendalikan berjuta-juta fail kecil.

Bagi pihaknya, vm.min_free_kbytes Rizabkan jumlah minimum memori kosong untuk memastikan sistem dapat bertindak balas terhadap pecahan peruntukan tanpa mengalami situasi luar kotak (OOB) secara tiba-tiba. Menetapkan saiz ini pada kira-kira 0,5% hingga 1% daripada jumlah RAM biasanya merupakan langkah keselamatan yang berkesan untuk mengelakkan kernel daripada kehabisan ruang di bawah beban yang melampau dan mula membunuh proses kritikal, sekali gus meningkatkan prestasi. kestabilan perumah keseluruhan.

Akhir sekali, dasar overcommit perlu diberi perhatian: parameter seperti vm.overcommit_memory y vm.overcommit_ratio Mereka menentukan berapa banyak memori maya yang diperuntukkan kepada proses berbanding RAM dan swap yang tersedia. Dalam beberapa kes (contohnya, dengan Redis atau pangkalan data tertentu) komitmen berlebihan yang agresif dibenarkan, manakala dalam kes lain, dasar yang lebih konservatif lebih diutamakan untuk menghadkan risiko OOM dan situasi ingatan yang terlalu terjejasUntuk teknik menganalisis dan mendiagnosis kes-kes yang kompleks, rujuk penyahpepijatan memori dalam Linux.

Pengoptimuman rangkaian lanjutan: net.* dan TCP/IP

Susunan rangkaian mungkin merupakan kawasan di mana penalaan paling ketara dalam persekitaran pengeluaran. Perubahan mudah dalam barisan atau penimbal sambungan boleh membuat perbezaan antara pelayan yang tersekat pada 500 Mbps dan pelayan yang Ia mudah menepu gigabit.Parameter di bawah net.core.* y net.ipv4.* Dalam bidang ini, mereka adalah sekutu terbaik anda.

Untuk bermula, saiz penimbal soket secara langsung mempengaruhi daya pemprosesan maksimum sambungan, terutamanya apabila terdapat latensi tinggi atau pautan berkapasiti tinggi. Laraskan net.core.rmem_max y net.core.wmem_max kepada nilai yang murah hati (puluhan atau ratusan megabait) dan tentukan dengan betul net.ipv4.tcp_rmem y net.ipv4.tcp_wmem (minimum, nilai lalai dan maksimum) membolehkan setiap soket mempunyai ruang diperlukan untuk mengurangkan kesesakan lalu lintas tanpa terjebak dalam sekatan buatan yang dikenakan oleh nilai kilang yang sangat konservatif.

Satu lagi perkara penting ialah saiz barisan sambungan. Parameter seperti net.core.somaxconn, net.core.netdev_max_backlog y net.ipv4.tcp_max_syn_backlog Had ini menentukan berapa banyak sambungan tertangguh yang boleh dikendalikan oleh sistem sebelum menjatuhkan paket atau menolak jabat tangan. Pada pelayan web trafik tinggi, peningkatan had ini boleh mengelakkan giliran tepu dan mengurangkan beban secara drastik. ralat sambungan semasa beban puncak.

Tingkah laku sambungan TCP juga boleh diperhalusi dengan pelbagai pilihan: dayakan net.ipv4.tcp_window_scaling Untuk menyokong tetingkap besar pada pautan jalur lebar tinggi, dayakan net.ipv4.tcp_sack y net.ipv4.tcp_timestamps untuk menambah baik pengurusan kehilangan dan penghantaran semula, atau melaraskan net.ipv4.tcp_fin_timeout dan pengurusan TIME_WAIT (net.ipv4.tcp_tw_reuse, net.ipv4.tcp_max_tw_buckets) untuk mengawal penggunaan sumber pada pelayan dengan berjuta-juta sambungan pendek seminit.

Pilihan algoritma kawalan kesesakan juga penting. Walaupun cubic Ia kekal sebagai nilai lalai dalam banyak taburan; berubah kepada bbr dalam kernel moden (4.9 dan kemudian) oleh net.ipv4.tcp_congestion_control y net.core.default_qdisc=fq Ia boleh menggandakan daya pemprosesan TCP dalam persekitaran dengan kehilangan atau latensi yang kompleks, mencapai penambahbaikan antara 2 dan 25 kali ganda berbanding konfigurasi klasik dalam senario tertentu, dengan kos tingkah laku yang agak berbeza dalam rangkaian sesak.

Kita tidak boleh melupakan parameter keselamatan dan kebolehpercayaan seperti net.ipv4.tcp_syncookies, pengendalian pengalihan (net.ipv4.conf.all.accept_redirects, send_redirects) atau penapisan dalam jambatan (net.bridge.bridge-nf-call-iptables dalam persekitaran Kubernetes). Jika dikonfigurasikan dengan betul, ia membolehkan anda melindungi sistem daripada serangan biasa (banjir SYN, spoofing, dll.) tanpa mengorbankan prestasi rangkaian yang kukuhUntuk panduan praktikal tentang peraturan dan pengesanan, lihat Pelaksanaan Netfilter dan Suricata.

Sistem fail, deskriptor dan had global: fs.* dan ulimit

Pada pelayan moden, had deskriptor fail yang rendah adalah cara terpantas untuk merosakkan sistem semasa waktu puncak. Apabila pelayan web, proksi songsang atau pangkalan data menghadapi ralat klasik "terlalu banyak fail terbuka", biasanya kerana... Parameter kernel dan had pengguna tidak didimensikan untuk beban sebenar.

Di peringkat global, fs.file-max Ini menentukan berapa banyak deskriptor yang boleh dibuka oleh kernel secara keseluruhan. Bagi aplikasi dengan beribu-ribu sambungan serentak, adalah perkara biasa untuk meningkatkan nilai ini kepada beberapa juta, berserta peningkatan sebanyak fs.nr_openyang menetapkan had tetap untuk deskriptor setiap proses. Di samping itu, pelarasan diperlukan. /etc/security/limits.conf supaya pengguna (atau perkhidmatan yang diuruskan oleh systemd) mempunyai nilai lembut dan keras selaras dengan konfigurasi kernel.

Subsistem inotify, yang digunakan secara meluas oleh IDE, alat pembangunan web dan sistem pemantauan fail, dikawal oleh parameter seperti fs.inotify.max_user_watches y fs.inotify.max_user_instancesJika anda menghadapi ralat berkaitan dengan pemerhati atau proses yang berhenti memantau perubahan cakera, anda mungkin perlu Tingkatkan had ini untuk mengelakkan kesesakan senyap.

Satu lagi ciri berkaitan ialah I/O tak segerak (AIO), yang maksimum globalnya ditakrifkan dengan fs.aio-max-nrDalam aplikasi yang sangat bergantung pada I/O tak segerak (enjin pangkalan data tertentu, sistem giliran, dll.), peningkatannya menghalang kernel daripada kehabisan slot untuk operasi AIO di bawah beban permintaan yang besar.

Selain parameter ini, prestasi subsistem cakera dipengaruhi oleh Penjadual I/O dikonfigurasikan pada setiap peranti blok. Dalam sistem dengan SSD atau NVMe, biasanya disyorkan untuk menggunakan penjadual ringan seperti none o mq-deadline, manakala pada cakera mekanikal pilihan lain mungkin masuk akal, seperti bfq bergantung pada jenis beban. Laraskan penjadual melalui /sys/block/<disco>/queue/scheduler dan memperhalusi pilihan seperti kedalaman giliran (nr_requests) atau read_ahead_kb boleh membuat perbezaan yang ketara dalam latensi dan daya pemprosesan baca/tulisIa juga penting untuk mempertimbangkan sistem fail dan pemacu yang digunakan; contohnya, artikel tentang NTFSplus pada Linux dan sistem lain boleh membantu semasa mereka bentuk beban heterogen.

Akhir sekali, tidak boleh dilupakan bahawa had kernel ini mesti seiring dengan konfigurasi sistem seperti yang ulimit dan unit sistem, untuk memastikan perkhidmatan benar-benar boleh menggunakan sumber tambahan yang ditakrifkan dan tidak disekat oleh sekatan di lapisan atas.

Kernel umum, NUMA, afiniti CPU dan halaman besar

Selain rangkaian, memori dan sistem fail, kernel itu sendiri menawarkan satu siri pilihan penalaan yang mempengaruhi cara proses dijadualkan, cara beban kerja diagihkan merentasi teras dan nod NUMA dan cara memori diuruskan pada skala. Pada mesin moden dengan banyak teras dan juga berbilang soket, butiran ini sering membuat perbezaan antara pelayan yang seimbang dan pelayan dengan... sesetengah teras tepu manakala yang lain kurang digunakanIa juga berbaloi untuk mencuba kernel alternatif seperti kernel Liquorix dalam persekitaran di mana profil kependaman yang berbeza dicari.

Parameter seperti kernel.pid_max Ia menetapkan julat maksimum ID proses yang boleh diberikan oleh sistem, yang berkaitan untuk nod yang menjalankan sejumlah besar kontena atau proses sementara. Melaraskan pilihan pengelogan kernel (kernel.printk) membantu mengurangkan hingar berlebihan dalam dmesg sambil masih merakam peristiwa kritikal, yang juga secara tidak langsung mempengaruhi keupayaan dan kestabilan diagnostik.

Berkenaan topologi memori, parameter kernel.numa_balancing Ia mengawal sejauh mana kernel secara automatik menggerakkan halaman antara nod NUMA. Melumpuhkannya dalam persekitaran tertentu membolehkan pengurusan proses dan afiniti memori yang lebih eksplisit, menggunakan alat seperti numactl untuk memastikan proses intensif CPU dan RAM kekal pada nod yang sama, sekali gus mengurangkan kependaman yang terhasil daripada akses jauhUntuk lebih memahami interaksi antara perkakasan dan penjadualan teras, adalah juga berguna untuk mengkaji semula teknologi seperti Pengarah Benang Intel.

Halaman-halaman besar (vm.nr_hugepagesIni merupakan satu lagi komponen penting dalam sistem pangkalan data atau beban kerja lain yang mengendalikan kawasan memori bersebelahan yang besar. Menempah bilangan halaman gergasi yang sesuai (2 MB atau 1 GB, bergantung pada seni bina) boleh mengurangkan overhed TLB dan meningkatkan prestasi aplikasi yang berjalan dengan ketara. banyak operasi pada blok memori yang besarAgar ini berkesan, konfigurasi kernel mesti diselaraskan dengan aplikasi itu sendiri, supaya ia menggunakan memori tersebut secara eksplisit.

Dalam bidang latensi dan penjadualan, terdapat parameter penjadual seperti kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns o kernel.sched_migration_cost_nsTetapan ini memperhalusi saiz "ketulan" CPU yang diperuntukkan untuk setiap tugas dan keagresifan kernel dalam menggerakkan proses antara teras. Nilai yang lebih kecil mewakili sistem yang lebih mudah dicegah, yang cenderung menawarkan jawapan terbaik untuk tugasan interaktif dengan kos, kadangkala, sedikit daya pemprosesan mentah.

Dalam sistem di mana memori merupakan sumber yang sensitif, sesetengah pentadbir memilih untuk mengaktifkan mod panik sekiranya berlaku ralat luar kotak (vm.panic_on_oom) dan menubuhkan kernel.panic dengan masa mula semula automatik. Strategi ini, walaupun agak drastik, boleh berguna dalam persekitaran ketersediaan tinggi di mana But semula yang cepat dan terkawal adalah lebih baik daripada hos yang tergantung dan tidak stabil. pada waktu berjam-jam.

Profil khusus: web, pangkalan data, kependaman rendah dan Kubernetes

Daripada menggunakan satu peluru ajaib, adalah lebih berkesan untuk mencipta profil sysctl yang disesuaikan dengan pelbagai jenis beban kerja: pelayan web, pangkalan data, platform kontena atau sistem latensi rendah. Mengedarkan tetapan ini dalam fail seperti 99-webserver.conf, 99-database.conf o 90-kubernetes.conf tolong mengekalkan konfigurasi yang teratur dan mudah diubah suaiAnda juga boleh mempertimbangkan pengedaran dan edisi berorientasikan prestasi seperti Edisi Pelayan CachyOS untuk persekitaran yang sangat spesifik.

Untuk pelayan web (Nginx, Apache, proksi, dll.), perkara penting adalah untuk mengendalikan sejumlah besar sambungan serentak dengan barisan dan masa tindak balas yang besar. FIN_WAIT Dengan penalaan halus, julat port sementara yang diperluas dan had deskriptor yang sangat tinggi, adalah perkara biasa untuk beralih daripada beberapa ratus permintaan HTTP sesaat kepada beberapa ribu, mengurangkan purata latensi dan menghapuskan ralat. barisan tepu atau port penuh.

Di bahagian pangkalan data (MySQL, PostgreSQL dan yang serupa), keutamaan diberikan kepada penggunaan swap yang minimum, penalaan halus penulisan halaman kotor dan tetapan memori kongsi dan semaphore yang sesuai untuk enjin. Parameter seperti kernel.shmmax, kernel.shmall, kernel.sem dan konfigurasi halaman yang besar membuat perbezaan dari segi transaksi sesaat dan masa tindak balas, mendarabkan prestasi dengan dua atau tiga berbanding nilai lalai dalam banyak senario.

Untuk aplikasi latensi yang sangat rendah (perdagangan, permainan dalam talian, pemprosesan masa nyata), tetapan yang lebih khusus ditambah: net.ipv4.tcp_low_latency, penyahaktifan permulaan perlahan selepas tidak aktif, penggunaan tcp_fastopen, parameter tinjauan pendapat sibuk (net.core.busy_poll, busy_read) dan, dalam banyak kes, penyahaktifan halaman besar lutsinar oleh /sys/kernel/mm/transparent_hugepage/enabledSemua ini bertujuan untuk mengurangkan puncak giliran pemprosesan dan kependaman pada persentil yang tinggi, mencapai penambahbaikan yang menakjubkan dalam P99.

Dalam persekitaran kontena dan Kubernetes, susunan rangkaian dan penjejakan sambungan berada di bawah tekanan tertentu. Parameter seperti net.ipv4.ip_forward, net.bridge.bridge-nf-call-iptables, net.netfilter.nf_conntrack_maxPenggunaan port yang dikhaskan untuk NodePort atau pelarasan jadual ARP adalah perkara biasa dalam nod yang mengendalikan ratusan atau ribuan pod. Melaraskannya dengan betul dapat mengelakkan masalah. sambungan terpotong, tamat masa atau ketepuan jadual dengan conntrack.

Selain daripada profil khusus ini, sesetengah organisasi memilih arkib yang berfokus pada prestasi dengan keselamatan yang dipertingkatkan, menggabungkan penimbal rangkaian yang besar dan pertukaran yang dikurangkan dengan langkah-langkah seperti tcp_syncookies atau menyekat pengalihan berbahaya. Matlamatnya adalah untuk mencapai titik keseimbangan antara prestasi agresif dan pengerasan yang munasabah.

Alatan pemprofilan dan pemantauan kernel

Menala kernel tanpa mengukur adalah seperti memainkan pengadun audio dengan mata tertutup. Linux menawarkan pelbagai alat untuk memahami apa yang sebenarnya dilakukan oleh sistem, daripada kaunter mudah hinggalah jejak terperinci fungsi kernel, yang membolehkan anda menghubungkan perubahan konfigurasi dengan kesan yang boleh diukur.

Antara utiliti harian ialah vmstat, iostat, sar, ss, slabtop, htop o pidstatyang memberikan maklumat pantas tentang proses, CPU, I/O, soket dan penggunaan cache. Digabungkan dengan log sistem dan metrik yang dieksport ke Prometheus, Grafana atau yang dikumpulkan, dan dengan sumber seperti monitor sistem canggih untuk LinuxMereka memberikan gambaran yang agak lengkap tentang bagaimana tuan rumah berkelakuan sebelum dan selepas setiap penalaan.

Untuk lebih terperinci, alat-alat seperti perf Ia membenarkan pemprofilan penggunaan CPU pada peringkat fungsi, pengguna dan kernel, merekod peristiwa selama beberapa saat atau minit dan kemudian menyediakan laporan interaktif. Dengan perf stat, perf record y perf report anda boleh lihat di mana masa CPU sebenarnya digunakan dan bahagian mana yang sepadan dengan teras, mengenal pasti, sebagai contoh, ribut gangguan atau penjadual yang diselaraskan dengan buruk.

Jika anda memerlukan lebih banyak butiran, ftrace Subsistem pengesanan kernel menawarkan keupayaan untuk mengaktifkan penjejak tertentu (contohnya, penjejak fungsi) dan memeriksa dalam masa nyata atau selepas kematian panggilan yang berlaku. Mendayakan penjejak yang sesuai dan menganalisis kandungannya /sys/kernel/debug/tracing/trace ia mendedahkan kepada anda titik panas dalam kernel itu sendiriIni sangat berguna apabila metrik peringkat tinggi tidak mencukupi.

Secara selari, adalah dinasihatkan untuk melaksanakan skrip pemantauan automatik yang secara berkala membuang data utama (statistik rangkaian, kaunter memori, bilangan deskriptor fail terbuka, dll.) ke dalam log berputar. Sebaik sahaja ambang tertentu dicapai (contohnya, melebihi bilangan deskriptor fail terbuka yang ditentukan), skrip ini boleh menjana makluman melalui e-mel atau saluran lain, membantu... mengesan trend berbahaya sebelum masalah meletup.

Akhir sekali, dalam fasa ujian tekanan yang berpanjangan (24 jam atau lebih), alat seperti stress-ng digabungkan dengan pengumpulan metrik yang berterusan (melalui vmstat, iostat, sar) membolehkan anda menilai kestabilan sistem dengan konfigurasi kernel baharu, mengesahkan bahawa tiada peristiwa OOM, ranap sistem, mula semula yang tidak dijangka atau penurunan prestasi progresif di bawah beban yang berterusan.

Mengoptimumkan kernel Linux dengan sysctl dan mekanisme lain bukanlah tugas sekali sahaja, tetapi sebaliknya merupakan proses berulang di mana keputusan diukur, parameter diselaraskan dan semuanya didokumenkan dengan teliti. Dengan metodologi yang jelas, profil khusus untuk setiap jenis beban kerja, set alat profil yang baik dan kawalan perubahan yang ketat, adalah mungkin untuk mencapai pelayan yang memanfaatkan sepenuhnya perkakasan mereka, dengan Daya pemprosesan yang lebih tinggi, kependaman yang lebih rendah dan kestabilan yang jauh lebih unggul kepada yang ditawarkan oleh konfigurasi kilang generik.

artikel berkaitan:

Panduan lanjutan untuk mengoptimumkan kernel Linux dan mengurangkan kependaman