Optimasi kernel Linux tingkat lanjut dengan sysctl

Informatec Digital » Sumber daya » Optimasi kernel Linux tingkat lanjut dengan sysctl

Jika Anda telah mengelola server Linux untuk beberapa waktu, Anda akhirnya akan menemukan bahwa perbedaan antara sistem yang biasa-biasa saja dan sistem yang berkinerja sangat baik di bawah beban berat terletak pada seberapa baik Anda telah menyetel kernel. Ini bukan hanya tentang memasang lebih banyak RAM atau CPU yang lebih kuat: banyak hambatan dapat diatasi dengan menyesuaikan beberapa parameter yang dipilih dengan cermat.

Kernel tersebut mengekspos ratusan opsi jaringan, memori, sistem file, dan penjadwalan proses yang dapat dimodifikasi secara langsung. Dengan alat ini sysctl dan beberapa penyesuaian dalam /procDimungkinkan untuk memaksimalkan kemampuan perangkat keras dan mencapai hasil yang diinginkan. Latensi lebih rendah, throughput lebih tinggi, dan stabilitas lebih baik. Hal ini berlaku untuk server web dan basis data, serta lingkungan waktu nyata dan Kubernetes. Namun, sangat penting untuk mengetahui secara pasti apa yang Anda lakukan dan bagaimana cara mengukurnya.

Apa itu sysctl dan bagaimana cara kerjanya dalam mengatur parameter kernel?

Utilitas sysctl Ini adalah gerbang untuk mengubah parameter kernel tanpa perlu mengkompilasi ulang atau melakukan reboot, sehingga memungkinkan membaca dan memodifikasi nilai pada saat runtime untuk menguji konfigurasi secara instan. Parameter-parameter ini diatur dalam struktur pohon hierarki rendah. /proc/sys/dan masing-masing mengontrol perilaku spesifik dari sistem tersebut.

Pengaturan dikelompokkan ke dalam kategori yang berbeda, sehingga mudah untuk menentukan apa yang perlu Anda sesuaikan ketika Anda mengalami masalah kinerja atau stabilitas tertentu. Struktur ini memungkinkan Anda untuk fokus, misalnya, hanya pada jaringan (net.*), memori (vm.*), atau sistem file (fs.*) tanpa tersesat dalam opsi kernel lainnya.

Kategori utama yang akan Anda temukan di /proc/sys/ Ini termasuk, antara lain:

• inti.*: opsi kernel umum (penjadwal, PID, pesan, NUMA, dll.).
• vm.*: manajemen memori virtual, swap, cache, dan kebijakan overcommit.
• bersih.*: Tumpukan jaringan IPv4/IPv6, buffer TCP/UDP, antrian, kontrol kemacetan.
• fs.*: batasan deskriptor, inode, inotify, AIO, dan perilaku VFS.
• pengembang.*: parameter spesifik dari perangkat dan driver tertentu.

dengan sysctl -a Anda dapat mencantumkan semua parameter yang tersedia, dan dengan perintah seperti sysctl vm.swappiness o sysctl net.ipv4.tcp_tw_reuse membaca nilai-nilai spesifik, yang merupakan kunci untuk periksa konfigurasi saat ini sebelum mengubah apa pun. Untuk menemukan sesuatu yang spesifik, biasanya digunakan filter dengan grep, misalnya: sysctl -a | grep tcp.

Memodifikasi parameter secara langsung semudah menggunakan sysctl -w clave=valorNamun, penting untuk dipahami bahwa perubahan ini bersifat sementara. Untuk menyimpannya setelah melakukan reboot, penting untuk mencadangkan konfigurasi terlebih dahulu. /etc/sysctl.conf atau dalam berkas /etc/sysctl.d/, biasanya menggunakan berkas bernomor (misalnya 10-network.conf, 20-memory.conf, 99-custom.conf) yang menentukan urutan penerapannya.

Ukur sebelum Anda sentuh: tolok ukur dan dasar sistem.

Sebelum Anda mulai mengubah-ubah pengaturan, sebaiknya tetapkan tolok ukur kinerja yang objektif terlebih dahulu . Tanpa data sebelumnya, mustahil untuk mengetahui apakah perubahan tersebut telah memperbaiki atau memperburuk sistem, dan Anda akan terjebak dalam perangkap klasik "menurut saya ini lebih baik", yang tidak berguna untuk membuat keputusan yang tepat.

Pada tingkat sistem secara keseluruhan, ada baiknya mengumpulkan statistik CPU, beban, memori, disk, dan jaringan selama beberapa menit di bawah beban yang representatif. Alat seperti uptime, mpstat, vmstat, iostat -x o sar -n DEV Hal ini memungkinkan Anda untuk melihat bagaimana kernel standar berperilaku, berapa banyak swap yang digunakan, bagaimana respons I/O disk, dan apakah jaringan jenuh atau membuang bandwidth.

Selain gambaran umum tersebut, sangat penting untuk menjalankan benchmark spesifik untuk aplikasi yang ingin Anda optimalkan. Pada server web, Anda dapat menggunakan ab (Apache Bench) atau alat serupa untuk mengukur permintaan per detik, latensi rata-rata, dan kesalahanDalam basis data, utilitas seperti mysqlslap o sysbench Mereka membantu mengevaluasi transaksi per detik dan waktu kueri.

Sebagai contoh, dalam skenario tanpa penyetelan, biasanya ditemukan angka seperti 500 permintaan HTTP/detik dengan waktu respons rata-rata 200 ms, sekitar 250 kueri SQL/detik dengan latensi 40 ms, kecepatan jaringan sekitar 500 Mbps, dan beban sistem yang mendekati batasnya saat tertekan. Angka-angka ini akan digunakan untuk memverifikasi, setelah menerapkan perubahan kernel, apakah peningkatan throughput yang terukur dan pengurangan latensi benar-benar tercapai.

Terakhir, dokumentasikan perintah dan hasilnya sebelum melakukan perubahan apa pun. Memiliki riwayat akan memungkinkan Anda untuk membandingkan berbagai batch penyesuaian secara akurat dan juga akan membantu Anda mendeteksi regresi setelah pembaruan kernel atau setelah memperkenalkan profil sysctl baru di lingkungan produksi.

Pengaturan memori tingkat lanjut: vm.*

Memori adalah salah satu subsistem di mana perubahan kernel paling terlihat. Server dengan RAM yang melimpah, tetapi dikonfigurasi dengan buruk, dapat menyebabkan penggunaan ruang swap yang tidak perlu, sehingga mengakibatkan... lonjakan I/O dan penurunan kinerja yang drastisItulah mengapa parameter seperti vm.swappinessRasio halaman kotor atau perilaku cache VFS sama pentingnya.

Parameter vm.swappiness Ini mengontrol seberapa banyak halaman memori yang dikirim kernel ke swap. Di banyak distribusi, nilainya diatur ke 60, nilai yang ditujukan untuk lingkungan desktop campuran. Untuk server basis data atau aplikasi latensi rendah, biasanya lebih baik menurunkannya menjadi 10 atau bahkan kurang, sehingga menghasilkan sistem yang lebih efisien. Prioritaskan penyimpanan data di RAM dan kurangi swapping.Tidak jarang kita melihat lalu lintas disk menurun drastis dan aplikasi merespons dengan lebih sedikit jitter setelah penyesuaian ini.

Salah satu elemen dasar lainnya adalah vm.dirty_ratio y vm.dirty_background_ratioNilai-nilai ini menentukan persentase memori yang dapat diisi dengan halaman kotor sebelum kernel mulai membersihkannya ke disk. Nilai yang terlalu tinggi dapat menyebabkan lonjakan penulisan yang besar, dengan latensi yang sangat besar untuk semua aplikasi ketika pembersihan terjadi. Mengurangi persentase ini menjadi angka seperti 15 dan 5, biasanya menghasilkan pola I/O yang lebih konsisten dan dapat diprediksi.

Pengaturan dari vm.vfs_cache_pressure Ini menentukan seberapa agresif kernel membersihkan cache inode dan direktori. Nilai default 100 cenderung membersihkan cache dengan cepat, sementara pengaturan sekitar 50 memungkinkan metadata untuk dipertahankan lebih lama, meningkatkan tingkat keberhasilan operasi file dan meningkatkan kinerja. kinerja sistem file yang dirasakan, sesuatu yang sangat penting dalam server yang menangani jutaan file kecil.

Untuk bagiannya, vm.min_free_kbytes Cadangkan sejumlah minimum memori kosong untuk memastikan sistem dapat merespons lonjakan alokasi tanpa mengalami situasi out-of-box (OOB) yang tiba-tiba. Mengalokasikan sekitar 0,5% hingga 1% dari total RAM biasanya merupakan langkah pengamanan yang efektif untuk mencegah kernel kehabisan ruang di bawah beban ekstrem dan mulai menghentikan proses-proses penting, sehingga meningkatkan kinerja. stabilitas host secara keseluruhan.

Terakhir, kebijakan overcommit perlu mendapat perhatian: parameter seperti vm.overcommit_memory y vm.overcommit_ratio Mereka menentukan berapa banyak memori virtual yang dialokasikan ke proses relatif terhadap RAM dan swap yang tersedia. Dalam beberapa kasus (misalnya, dengan Redis atau basis data tertentu) overcommitment yang agresif diperbolehkan, sementara dalam kasus lain kebijakan yang lebih konservatif lebih disukai untuk membatasi risiko OOM dan situasi memori yang sangat terganggu.Untuk teknik menganalisis dan mendiagnosis kasus-kasus kompleks, konsultasikan dengan debugging memori di Linux.

Optimasi jaringan tingkat lanjut: net.* dan TCP/IP

Tumpukan jaringan mungkin merupakan area di mana penyetelan paling terlihat di lingkungan produksi. Perubahan sederhana pada antrian atau buffer koneksi dapat membuat perbedaan antara server yang tersendat pada kecepatan 500 Mbps dan server yang lebih cepat. Ini dengan mudah memenuhi kapasitas gigabit.Parameter di bawah ini net.core.* y net.ipv4.* Dalam hal ini, mereka adalah sekutu terbaik Anda.

Pertama-tama, ukuran buffer soket secara langsung memengaruhi throughput maksimum suatu koneksi, terutama ketika terdapat latensi tinggi atau tautan berkapasitas tinggi. Sesuaikan net.core.rmem_max y net.core.wmem_max ke nilai yang besar (puluhan atau ratusan megabyte) dan definisikan dengan benar. net.ipv4.tcp_rmem y net.ipv4.tcp_wmem (nilai minimum, nilai default, dan nilai maksimum) memungkinkan setiap soket memiliki Ruang yang dibutuhkan untuk meredam lonjakan lalu lintas. tanpa terjebak dalam batasan buatan yang diberlakukan oleh nilai-nilai pabrik yang sangat konservatif.

Poin penting lainnya adalah ukuran antrian koneksi. Parameter seperti net.core.somaxconn, net.core.netdev_max_backlog y net.ipv4.tcp_max_syn_backlog Batasan ini menentukan berapa banyak koneksi tertunda yang dapat ditangani sistem sebelum menjatuhkan paket atau menolak jabat tangan. Pada server web dengan lalu lintas tinggi, meningkatkan batasan ini dapat mencegah antrian jenuh dan mengurangi beban secara drastis. kesalahan koneksi selama beban puncak.

Perilaku koneksi TCP juga dapat disesuaikan dengan berbagai pilihan: aktifkan net.ipv4.tcp_window_scaling Untuk mendukung jendela besar pada tautan bandwidth tinggi, aktifkan net.ipv4.tcp_sack y net.ipv4.tcp_timestamps untuk meningkatkan manajemen kehilangan dan transmisi ulang, atau menyesuaikan net.ipv4.tcp_fin_timeout dan pengelolaan TIME_WAIT (net.ipv4.tcp_tw_reuse, net.ipv4.tcp_max_tw_buckets) untuk mengontrol konsumsi sumber daya pada server dengan jutaan koneksi singkat per menit.

Pemilihan algoritma pengendalian kemacetan juga penting. Meskipun cubic Nilai tersebut tetap menjadi nilai default di banyak distribusi; mengubahnya menjadi bbr pada kernel modern (4.9 dan seterusnya) oleh net.ipv4.tcp_congestion_control y net.core.default_qdisc=fq Hal ini dapat melipatgandakan throughput TCP di lingkungan dengan kehilangan data atau latensi yang kompleks, mencapai peningkatan antara 2 hingga 25 kali lipat dibandingkan dengan konfigurasi klasik dalam skenario tertentu, dengan biaya tertentu. Perilaku yang agak berbeda di jaringan yang padat..

Kita tidak boleh melupakan parameter keselamatan dan keandalan seperti net.ipv4.tcp_syncookies, penanganan pengalihan (net.ipv4.conf.all.accept_redirects, send_redirects) atau penyaringan di jembatan (net.bridge.bridge-nf-call-iptables (di lingkungan Kubernetes). Jika dikonfigurasi dengan benar, fitur ini memungkinkan Anda untuk melindungi sistem dari serangan umum (SYN flood, spoofing, dll.) tanpa mengorbankan kinerja. kinerja jaringan yang solidUntuk panduan praktis tentang aturan dan deteksi, lihat Implementasi Netfilter dan Suricata.

Sistem berkas, deskriptor, dan batasan global: fs.* dan ulimit

Pada server modern, batas deskriptor file yang rendah adalah cara tercepat untuk merusak sistem selama jam sibuk. Ketika server web, reverse proxy, atau basis data mengalami kesalahan klasik "terlalu banyak file yang terbuka", biasanya karena parameter kernel dan batasan pengguna tidak disesuaikan dengan beban aktual.

Secara global, fs.file-max Ini menentukan berapa banyak deskriptor yang dapat dibuka kernel secara total. Untuk aplikasi dengan ribuan koneksi simultan, biasanya nilai ini ditingkatkan menjadi beberapa juta, bersamaan dengan peningkatan fs.nr_openyang menetapkan batasan maksimal untuk deskriptor per proses. Selain itu, penyesuaian juga diperlukan. /etc/security/limits.conf sehingga pengguna (atau layanan yang dikelola oleh systemd) memiliki nilai lunak dan keras yang konsisten dengan konfigurasi kernel.

Subsistem inotify, yang banyak digunakan oleh IDE, alat pengembangan web, dan sistem pemantauan file, dikendalikan oleh parameter seperti fs.inotify.max_user_watches y fs.inotify.max_user_instancesJika Anda menemukan kesalahan yang terkait dengan pengawas atau proses yang berhenti memantau perubahan disk, Anda mungkin perlu Tingkatkan batasan ini untuk menghindari hambatan tersembunyi..

Fitur relevan lainnya adalah I/O asinkron (AIO), yang nilai maksimum globalnya didefinisikan dengan fs.aio-max-nrPada aplikasi yang sangat bergantung pada I/O asinkron (mesin basis data tertentu, sistem antrian, dll.), peningkatan nilai ini mencegah kernel kehabisan slot untuk operasi AIO di bawah beban permintaan yang sangat besar.

Selain parameter-parameter tersebut, kinerja subsistem disk juga dipengaruhi oleh hal-hal berikut: penjadwal I/O dikonfigurasi pada setiap perangkat blok. Pada sistem dengan SSD atau NVMe, biasanya disarankan untuk menggunakan penjadwal ringan seperti none o mq-deadline, sedangkan pada cakram mekanis, opsi lain mungkin lebih masuk akal, seperti bfq tergantung pada jenis beban. Sesuaikan penjadwal melalui /sys/block/<disco>/queue/scheduler dan opsi penyesuaian seperti kedalaman antrian (nr_requests) atau read_ahead_kb dapat membuat perbedaan yang nyata dalam latensi baca/tulis dan throughputPenting juga untuk mempertimbangkan sistem file dan driver apa yang digunakan; misalnya, artikel tentang NTFSplus di Linux dan sistem lain dapat membantu saat mendesain beban heterogen.

Terakhir, jangan sampai terlupakan bahwa batasan kernel ini harus sejalan dengan konfigurasi sistem seperti yang terdapat pada ulimit dan unit systemd, untuk memastikan bahwa layanan benar-benar dapat menggunakan sumber daya tambahan yang telah ditentukan dan tidak terblokir oleh pembatasan di lapisan atas.

Kernel umum, NUMA, afinitas CPU, dan halaman besar.

Selain jaringan, memori, dan sistem file, kernel itu sendiri menawarkan berbagai opsi penyetelan yang memengaruhi bagaimana proses dijadwalkan, bagaimana beban kerja didistribusikan di seluruh inti dan node NUMA, dan bagaimana memori dikelola dalam skala besar. Pada mesin modern dengan banyak inti dan bahkan beberapa soket, detail ini seringkali membuat perbedaan antara server yang seimbang dan server dengan beberapa inti yang jenuh sementara yang lain kurang dimanfaatkan . Ada baiknya juga untuk mengeksplorasi kernel alternatif seperti kernel Liquorix di lingkungan di mana profil latensi yang berbeda diinginkan.

Parameter seperti kernel.pid_max Mereka menetapkan rentang maksimum ID proses yang dapat ditetapkan oleh sistem, yang relevan untuk node yang menjalankan sejumlah besar kontainer atau proses sementara. Menyesuaikan opsi pencatatan kernel (kernel.printk) membantu mengurangi kebisingan berlebihan di dmesg sambil tetap merekam peristiwa penting, yang secara tidak langsung juga memengaruhi kemampuan diagnostik dan stabilitas.

Mengenai topologi memori, parameternya kernel.numa_balancing Ini mengontrol sejauh mana kernel secara otomatis memindahkan halaman antar node NUMA. Menonaktifkannya di lingkungan tertentu memungkinkan pengelolaan afinitas proses dan memori yang lebih eksplisit, menggunakan alat seperti... numactl untuk memastikan bahwa proses yang membutuhkan banyak CPU dan RAM tetap berada di node yang sama, sehingga mengurangi latensi yang diakibatkan oleh akses jarak jauhUntuk lebih memahami interaksi antara perangkat keras dan penjadwalan inti, ada baiknya juga untuk meninjau teknologi seperti Direktur Benang Intel.

Halaman-halaman yang sangat besar (vm.nr_hugepagesIni adalah komponen kunci lain dalam sistem basis data atau beban kerja lain yang menangani wilayah memori yang besar dan berdekatan. Mencadangkan sejumlah halaman raksasa yang sesuai (2 MB atau bahkan 1 GB, tergantung pada arsitektur) dapat mengurangi overhead TLB dan secara signifikan meningkatkan kinerja aplikasi yang berjalan. banyak operasi pada blok memori yang besarAgar hal ini efektif, konfigurasi kernel harus diselaraskan dengan aplikasi itu sendiri, sehingga aplikasi tersebut menggunakan memori tersebut secara eksplisit.

Dalam bidang latensi dan penjadwalan, terdapat parameter penjadwal seperti kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns o kernel.sched_migration_cost_nsPengaturan ini menyempurnakan ukuran "chunk" CPU yang dialokasikan untuk setiap tugas dan agresivitas kernel dalam memindahkan proses antar inti. Nilai yang lebih kecil mewakili sistem yang lebih mudah diinterupsi, yang cenderung menawarkan jawaban terbaik untuk tugas interaktif dengan mengorbankan, terkadang, sedikit kapasitas produksi mentah.

Dalam sistem di mana memori merupakan sumber daya yang sensitif, beberapa administrator memilih untuk mengaktifkan mode panik jika terjadi kesalahan bawaan (out-of-box error).vm.panic_on_oom) dan menetapkan kernel.panic dengan waktu restart otomatis. Strategi ini, meskipun agak drastis, dapat berguna di lingkungan ketersediaan tinggi di mana Reboot yang cepat dan terkontrol lebih baik daripada host yang macet dan tidak stabil. selama berjam-jam.

Profil khusus: web, basis data, latensi rendah, dan Kubernetes

Alih-alih menerapkan satu solusi ajaib, akan lebih efektif untuk membuat profil sysctl yang disesuaikan dengan berbagai jenis beban kerja: server web, basis data, platform kontainer, atau sistem latensi rendah. Mendistribusikan pengaturan ini dalam file seperti... 99-webserver.conf, 99-database.conf o 90-kubernetes.conf bantuan untuk Memelihara konfigurasi yang terorganisir dan mudah dikelola versinya.Anda juga dapat mempertimbangkan distribusi dan edisi yang berorientasi pada kinerja seperti CachyOS Server Edition untuk lingkungan yang sangat spesifik.

Bagi server web (Nginx, Apache, proxy, dll.), hal terpenting adalah menangani volume koneksi simultan yang besar dengan antrian dan waktu respons yang besar. FIN_WAIT Dengan penyempurnaan, perluasan rentang port sementara, dan batasan deskriptor yang sangat tinggi, biasanya jumlah permintaan HTTP per detik dapat meningkat dari beberapa ratus menjadi beberapa ribu, sehingga mengurangi latensi rata-rata dan menghilangkan kesalahan. antrian jenuh atau port penuh.

Di sisi basis data (MySQL, PostgreSQL, dan sejenisnya), prioritas diberikan pada penggunaan swap minimal, penyempurnaan penulisan halaman kotor, dan pengaturan memori bersama dan semaphore yang sesuai untuk mesin tersebut. Parameter seperti kernel.shmmax, kernel.shmall, kernel.sem dan konfigurasi halaman yang besar membuat perbedaan dalam hal transaksi per detik dan waktu respons, meningkatkan kinerja hingga dua atau tiga kali lipat dibandingkan dengan nilai default dalam banyak skenario.

Untuk aplikasi dengan latensi sangat rendah (perdagangan, game online, pemrosesan waktu nyata), pengaturan yang lebih spesifik ditambahkan: net.ipv4.tcp_low_latency, penonaktifan slow start setelah tidak aktif, penggunaan tcp_fastopen, parameter polling sibuk (net.core.busy_poll, busy_read) dan, dalam banyak kasus, penonaktifan halaman besar transparan oleh /sys/kernel/mm/transparent_hugepage/enabledSemua ini bertujuan untuk mengurangi Antrian pemrosesan dan latensi mencapai puncaknya pada persentil tinggi., mencapai peningkatan yang spektakuler di P99.

Dalam lingkungan kontainer dan Kubernetes, tumpukan jaringan dan pelacakan koneksi berada di bawah tekanan yang sangat besar. Parameter seperti net.ipv4.ip_forward, net.bridge.bridge-nf-call-iptables, net.netfilter.nf_conntrack_maxPenggunaan port yang dicadangkan untuk NodePort atau penyesuaian tabel ARP umum dilakukan pada node yang menangani ratusan atau ribuan pod. Menyesuaikannya dengan benar dapat mencegah masalah. koneksi terputus, waktu habis, atau saturasi tabel dengan conntrack.

Selain profil-profil spesifik tersebut, beberapa organisasi memilih arsip yang berfokus pada kinerja dengan keamanan yang ditingkatkan, menggabungkan buffer jaringan yang besar dan pengurangan swappiness dengan langkah-langkah seperti tcp_syncookies atau pemblokiran pengalihan berbahaya. Tujuannya adalah untuk mencapai titik keseimbangan antara performa agresif dan pengerasan yang wajar.

Alat pembuatan profil dan pemantauan kernel

Mengubah kernel tanpa mengukur sama seperti memainkan mixer audio dengan mata tertutup. Linux menawarkan serangkaian alat untuk memahami apa yang sebenarnya dilakukan sistem, mulai dari penghitung sederhana hingga pelacakan detail fungsi kernel, yang memungkinkan Anda untuk menghubungkan perubahan konfigurasi dengan efek yang terukur.

Di antara kebutuhan sehari-hari adalah vmstat, iostat, sar, ss, slabtop, htop o pidstatyang memberikan informasi cepat tentang proses, CPU, I/O, soket, dan penggunaan cache. Dikombinasikan dengan log sistem dan metrik yang diekspor ke Prometheus, Grafana, atau collectd, dan dengan sumber daya seperti monitor sistem canggih untuk LinuxMereka memberikan gambaran yang cukup lengkap tentang bagaimana perilaku host sebelum dan sesudah setiap penyetelan.

Untuk menjelaskan lebih detail, alat-alat seperti... perf Mereka memungkinkan pembuatan profil penggunaan CPU pada tingkat fungsi, baik pengguna maupun kernel, mencatat peristiwa selama beberapa detik atau menit, dan kemudian menyediakan laporan interaktif. Dengan perf stat, perf record y perf report Anda dapat melihat di mana waktu CPU sebenarnya dikonsumsi dan bagian mana yang sesuai dengan inti prosesor., misalnya, mengidentifikasi badai yang menyebabkan gangguan atau penjadwal yang tidak disetel dengan baik.

Jika Anda membutuhkan detail yang lebih rinci lagi, ftrace Subsistem pelacakan kernel menawarkan kemampuan untuk mengaktifkan pelacak spesifik (misalnya, pelacak fungsi) dan memeriksa secara waktu nyata atau pasca-mortem panggilan apa yang terjadi. Mengaktifkan pelacak yang sesuai dan menganalisis isinya. /sys/kernel/debug/tracing/trace itu mengungkapkannya kepada Anda titik panas di dalam kernel itu sendiriIni sangat berguna ketika metrik tingkat tinggi saja tidak cukup.

Secara paralel, disarankan untuk menerapkan skrip pemantauan otomatis yang secara berkala membuang data penting (statistik jaringan, penghitung memori, jumlah deskriptor file terbuka, dll.) ke dalam log yang berputar. Setelah ambang batas tertentu tercapai (misalnya, melebihi jumlah deskriptor file terbuka yang ditentukan), skrip ini dapat menghasilkan peringatan melalui email atau saluran lain, membantu mendeteksi tren berbahaya sebelum masalah meningkat.

Terakhir, dalam fase pengujian stres yang berkepanjangan (24 jam atau lebih), alat-alat seperti stress-ng dikombinasikan dengan pengumpulan metrik secara terus menerus (melalui vmstat, iostat, sar) memungkinkan Anda untuk menilai stabilitas sistem dengan konfigurasi kernel baru, memverifikasi bahwa tidak ada kejadian OOM (Out of Memory), crash, restart yang tidak terduga, atau penurunan kinerja progresif di bawah beban berkelanjutan.

Mengoptimalkan kernel Linux dengan sysctl dan mekanisme lainnya bukanlah tugas sekali jadi, melainkan proses berulang yang melibatkan pengukuran hasil, penyesuaian parameter, dan pendokumentasian segala sesuatu secara teliti. Dengan metodologi yang jelas, profil spesifik untuk setiap jenis beban kerja, serangkaian alat pembuatan profil yang andal, dan kontrol perubahan yang ketat, dimungkinkan untuk mencapai server yang sepenuhnya memanfaatkan perangkat kerasnya, dengan peningkatan throughput, pengurangan latensi, dan stabilitas yang jauh lebih besar daripada konfigurasi pabrik standar.