Tutorial lengkap tentang kebocoran memori dalam Linux

Jika anda pernah mengalami kebocoran paip sinki dapur yang perlahan-lahan, anda tahu betapa berbahayanya kebocoran: pada mulanya ia kelihatan tidak banyak, tetapi lama-kelamaan ia boleh menyebabkan masalah yang sebenar. Kebocoran memori dalam Linux adalah sama sahaja.Ia bermula sebagai titisan yang hampir tidak dapat dilihat dan akhirnya menjatuhkan perkhidmatan, perkhidmatan mikro kritikal atau keseluruhan pelayan.

Dalam sistem yang mesti sentiasa tersedia (pelayan, bekas pengeluaran, peranti terbenam, dll.), kebocoran memori yang tiada siapa yang memantau adalah seperti bom jangka yang sedang berdetik. Jika anda tidak memantau, anda tidak mengesan dan anda tidak membetulkanJika tidak, anda akan berhadapan dengan proses yang dimatikan oleh OOM Killer, ranap sistem secara rawak dan pengguna yang marah yang tidak begitu memahami apa yang berlaku. Dalam tutorial ini, kita akan melihat secara terperinci, tetapi menggunakan bahasa yang mudah difahami, cara mengesan dan menganalisis kebocoran memori dalam Linux menggunakan alat asas seperti atas/htop malah pengprofil lanjutan seperti Valgrind, memleax atau gdb, sebagai tambahan kepada utiliti seperti /proc, pmap atau smem.

Apakah kebocoran memori dalam Linux dan mengapa ia begitu berbahaya?

Kebocoran memori berlaku apabila program Ia menyimpan memori sistem (timbunan, struktur, penimbal, dll.) dan tidak pernah melepaskannya. apabila ia tidak lagi diperlukan. Dalam bahasa seperti C atau C++, ini biasanya diterjemahkan kepada panggilan ke malloc, calloc, new yang tidak disertakan dengan yang sepadan free o deleteatau dalam rujukan yang tersekat dan menjadikannya mustahil untuk menggunakan semula memori tersebut.

Dalam praktiknya, proses tersebut berjalan seperti biasa, tetapi Penggunaan memorinya meningkat secara beransur-ansur Dengan setiap permintaan, setiap kitaran kerja atau setiap tugasan baharu, pertumbuhan ini boleh menjadi sangat perlahan (dengan purata beberapa KB atau MB sehari), menjadikannya amat sukar untuk dikesan sepintas lalu tanpa pemantauan yang baik.

Akibat daripada mengabaikan masalah ini adalah jelas: penurunan prestasi, pertukaran berterusan, latensi yang besarDan pada satu ketika, sistem kehabisan memori yang tersedia. Di situlah Pembunuh OOM Kernel Linux, yang membunuh proses yang menggunakan paling banyak memori (atau proses yang dianggap paling boleh dibuang oleh algoritma) untuk mengelakkan seluruh sistem daripada ranap.

Tingkah laku ini biasanya paling baik dilihat dalam graf pemantauan: memori RSS bagi sesuatu proses Ia meningkat secara beransur-ansur selama beberapa hari Sehingga, tiba-tiba, ia merudum sebaik sahaja OOM Killer menamatkannya dan perkhidmatan dimulakan semula. Jika tiada sesiapa yang menganalisis peristiwa ini, kebocoran akan kekal dan kitaran itu akan berulang.

Itulah sebabnya penting untuk memahami bahawa Kebocoran memori bukan sekadar masalah kodtetapi juga operasi dan kebolehcerapan: adalah perlu untuk mengetahui cara mengesannya dalam pengeluaran, mengaitkannya dengan peristiwa sistem dan mempunyai alat untuk menganalisisnya dalam proses yang sudah berjalan dan dalam persekitaran ujian.

Punca biasa dan gejala kebocoran ingatan yang jelas

Dari perspektif perkembangan, punca-punca yang paling biasa bagi kehilangan ingatan biasanya ralat pengaturcaraan dan amalan pengurusan sumber yang lemahAntara sebab yang paling biasa ialah: lupa untuk mengosongkan memori, mengekalkan struktur memori yang tidak pernah dipangkas, tidak menutup deskriptor yang mempunyai penimbal yang berkaitan atau menggunakan pustaka pihak ketiga dengan pepijat dalaman.

Dalam aplikasi yang berjalan lama, seperti daemon, perkhidmatan web atau proses kelompok yang tidak pernah dimulakan semula, masalahnya menjadi lebih teruk kerana Sebarang kebocoran kecil akan terkumpul dari semasa ke semasaWalaupun pepijat yang jarang berlaku yang hanya berlaku dalam kes tepi tertentu boleh memakan RAM jika proses itu kekal aktif selama berbulan-bulan.

Simptom-simptom yang sepatutnya memberi amaran kepada anda agak mudah dikenali jika anda tahu apa yang perlu dicari. Yang paling jelas ialah melihat bagaimana Ingatan sesuatu proses (RES/RSS) berkembang secara berterusan walaupun beban kerja kekal stabil. Ia seperti melihat tolok bahan api menurun di dalam kereta yang diletakkan.

Satu lagi kesan tipikal ialah kemerosotan prestasi progresifSistem mula menggunakan swap, latensi meningkat mendadak, pertanyaan atau permintaan yang sebelum ini pantas menjadi tidak berkesudahan, dan proses hos yang lain juga terjejas, walaupun mereka bukan penyebab langsung.

Akhirnya, gejala yang paling dramatik muncul: kegagalan proses atau sistem yang tidak dijangkaKernel, tanpa memori untuk diperuntukkan, mengaktifkan Pembunuh Kehabisan Memori dan menamatkan proses. Jika proses yang ranap adalah perkhidmatan mikro terpencil, ia masih merupakan isu kecil, tetapi jika proses yang mati adalah, sebagai contoh, pangkalan data atau pengurus giliran, kesannya boleh menjadi sangat serius.

Satu cara yang sangat berkesan untuk mengenal pasti kes-kes ini dalam pengeluaran adalah dengan menggabungkan graf memori dengan pengumpulan peristiwa sistemtermasuk yang dijana oleh OOM Killer. Jika anda melihat corak penggunaan memori pada papan pemuka anda yang meningkat secara perlahan-lahan, kemudian tiba-tiba menurun, dan pada saat yang sama anda mempunyai satu atau lebih peristiwa OOM Killer, anda hampir pasti menghadapi kebocoran memori dalam proses tersebut.

Pemantauan asas dengan bahagian atas dan htop

Untuk pendekatan pertama, tidak perlu merumitkan perkara: alat seperti bahagian dan di atas semua, htop Ia sesuai untuk melihat dalam masa nyata proses mana yang menggunakan memori anda. Ia seperti panel kawalan pantas untuk mengenal pasti puncanya.

Dalam kebanyakan pengedaran, anda boleh memasang htop Mudah dengan pengurus pakej. Pada sistem berasaskan Debian, perkara seperti ini sudah memadai:

sudo apt install htop

Setelah dipasang, apabila anda menjalankan htop Anda akan melihat paparan interaktif proses dengan warna, bar CPU dan memori serta lajur yang berbeza. Lajur utama untuk mengesan kebocoran Mereka adalah memori pemastautin dan memori maya proses tersebut:

- RES / RSS (Saiz Set Residen): memori fizikal yang terdapat dalam RAM pada masa ini dalam proses tersebut.
- VIRT (Memori Maya): jumlah memori maya yang telah diperuntukkan oleh proses (termasuk memori yang dipetakan dan berpotensi ditukar).
- %MEM: peratusan RAM fizikal yang digunakan oleh proses daripada jumlah RAM sistem.

Jika anda memesan melalui RES atau %MEM Dan jika anda membiarkan htop terbuka untuk seketika, anda boleh melihat bagaimana prosesnya berkembang. Jika salah satu daripadanya Ia terus mendaki tiang-tiang ini secara perlahan-lahan tanpa pernah turun semula.Ia menunjukkan kehilangan ingatan atau, sekurang-kurangnya, penggunaannya yang tidak sihat.

top, walaupun lebih bersahaja, juga membolehkan anda melihat nilai-nilai ini dan memantaunya dalam tempoh masa tertentu, tetapi htop menjadikan pemerhatian dan penapisan yang berpanjangan terhadap proses tertentu yang menarik minat anda lebih mudah.

Menyelidiki lebih mendalam tentang sistem fail /proc

Untuk beralih daripada pandangan dangkal kepada analisis yang lebih halus, Linux mendedahkan maklumat terperinci tentang setiap proses dalam sistem fail pseudo /procSetiap PID mempunyai direktorinya sendiri di dalamnya /procDan di sana anda boleh menyemak semua jenis metrik, termasuk yang berkaitan dengan ingatan.

Titik masuk klasik ialah fail /proc//status, di mana anda akan menemui medan seperti VmRSS, VmSize atau VmDataAnda boleh melihatnya dengan cara yang mudah:

cat /proc/<pid>/status

Dalam output tersebut, medan yang paling menarik untuk mengesan kebocoran memori ialah:

- VmRSS: memori pemastautin (dalam KB) yang terdapat dalam RAM pada masa itu oleh proses tersebut.
- Saiz Vm: jumlah memori maya yang berkaitan dengan proses (termasuk semua yang telah dipetakan).
- VmData: memori segmen data, tempat struktur dan timbunan dinamik biasanya berada, kawasan yang sangat terdedah kepada kebocoran memori.

Idea praktikalnya adalah untuk terus menyemak nilai-nilai ini. pada selang masa yang tetap (sama ada secara manual atau melalui skrip) dan perhatikan sama ada ia mengikuti trend menaik yang konsisten. Jika anda melihat VmRSS dan, terutamanya, VmData meningkat tanpa menurun semasa tempoh beban rendah, ia merupakan petunjuk yang agak kuat bahawa aplikasi tersebut membocorkan memori.

Plus statusdalam /proc/ Anda mempunyai fail menarik lain untuk menganalisis peta memori, seperti maps o smaps, walaupun ia lebih berjela-jela dan sering digunakan bersama-sama dengan alat lain seperti pmap untuk menjadikan maklumat lebih mudah dibaca.

Analisis peta memori proses menggunakan pmap

Utiliti pmap Ia merupakan arahan yang sangat berguna untuk mendapatkan pandangan teratur bagi peta memori proses tertentu. Pada asasnya, ia menunjukkan julat alamat yang telah dipetakan oleh proses, saiz setiap julat, kebenarannya dan fail, pustaka atau jenis memori yang sepadan dengannya.

Untuk menggunakannya, cuma lancarkan:

pmap

Dalam output, anda akan melihat baris dengan alamat permulaan, saiz, kebenaran (baca, tulis, laksanakan), dan asal (contohnya, fail boleh laku utama, pustaka kongsi seperti libckawasan tanpa nama, longgokan, dsb.). Kawasan memori tanpa nama dan zon timbunan Inilah yang biasanya memberi petunjuk apabila terdapat kebocoran memori.

Cara praktikal untuk mengesan kemajuan adalah dengan mengulang. pmap sekali-sekala dan semak sama ada segmen tertentu (terutamanya yang tanpa nama berkaitan dengan timbunan) mereka tidak berhenti tumbuhAnda juga boleh menapis atau meringkaskan output, contohnya:

pmap <pid> | grep total

Ini akan memberi anda ringkasan jumlah memori yang dipetakan oleh proses tersebut. Jika nombor itu terus meningkat dan meningkat selama beberapa jam dan tidak stabil atau berkurangan apabila sepatutnya, syak wasangka sekali lagi menunjukkan kebocoran memori atau pengurusan penimbal dalaman yang tidak cekap.

smem: membezakan memori kongsi dan penggunaan sebenar setiap proses

Alat seperti top, htop atau pmap mengira semua memori yang dirujuk oleh proses, tetapi ia tidak memisahkan memori yang benar-benar eksklusif untuk proses tersebut daripada memori yang dikongsi dengan orang lain dengan jelas (contohnya, perpustakaan kongsi). Di situlah [perkara berikut memainkan peranan]. smem, utiliti khusus untuk memberikan pandangan yang lebih tepat.

Kelebihan besar smem ialah ia mengira metrik seperti USS (Saiz Set Unik), PSS (Saiz Set Berkadar) dan RSSyang membolehkan pemahaman yang lebih baik tentang penggunaan memori sebenar setiap proses: berapa banyak memori yang dimilikinya sendiri dan berapa banyak yang dikongsi dengan proses lain yang memuatkan pustaka yang sama atau berkongsi halaman.

Antara metrik paling relevan yang akan anda lihat dalam output smem ialah:

- USS (Saiz Set Unik): memori yang hanya digunakan oleh proses tersebut; jika proses tersebut hilang, bahagian memori tersebut akan dibebaskan sepenuhnya.
- PSS (Saiz Set Berkadaran): mengagihkan memori kongsi antara semua proses yang menggunakannya, menawarkan pandangan berkadaran yang agak adil tentang jejak sebenar.
- RSS (Saiz Set Residen): Memori residen, seperti dalam alat lain, tetapi dibentangkan bersama-sama dengan yang di atas untuk perbandingan.

Apabila menjalankan sesuatu seperti smem -k Anda akan mendapat jadual dengan PID, pengguna, arahan dan lajur penggunaan memori ini. Perkara yang menarik, dari segi kebocoran memori, adalah untuk memberi tumpuan terutamanya pada USSkerana ia mencerminkan memori aplikasi itu sendiri, di mana kebocoran paling serius biasanya muncul.

Jika anda membiarkan smem berjalan secara berkala (atau mengintegrasikannya ke dalam skrip pemantauan) dan anda melihat bahawa USS proses tertentu Ia terus meningkat dari semasa ke semasaWalaupun bebannya tidak bertambah, tingkah laku itu sangat menunjukkan kebocoran memori dalam bahagian memori tunggal proses tersebut.

memleax: pengesanan kebocoran automatik dalam proses yang sedang berjalan

Sebaik sahaja anda mengenal pasti proses yang nampaknya membocorkan memori dan anda ingin mengambil langkah lebih jauh tanpa memulakannya semula, alat yang sangat berguna ialah... memleaxKekuatan terbesarnya ialah Ia membolehkan anda mengesan kebocoran memori dalam masa nyata pada proses yang sedang berjalan., tanpa perlu mengkompil semula atau melancarkannya semula dengan arahan khas.

memleax terutamanya diedarkan dalam bentuk pakej. .rpm y .debIa tersedia dalam beberapa repositori, seperti yang terdapat untuk Arch Linux dan FreeBSD. Pada sistem berasaskan Debian, cara biasa untuk memasangnya adalah dengan memuat turun pakej daripada repositori GitHub rasminya dan kemudian menggunakan dpkg Untuk memasangnya, selesaikan kebergantungan dengan pengurus pakej anda.

Setelah dipasang, anda boleh melampirkan memleax pada proses dengan:

sudo memleax -p

Dari saat itu, memleax memintas panggilan peruntukan memori (seperti malloc) dan merekodkan alamat dan saiz yang disimpan oleh proses tersebut. Apabila ia mengesan bahawa peruntukan tidak dikeluarkan dengan betul, secara eksplisit menandakannya sebagai kebocoran memori, menunjukkan saiz blok dan alamat yang bertanggungjawab.

Output biasa menunjukkan baris gaya malloc(128) = 0x... diikuti, apabila terdapat masalah, dengan mesej yang menunjukkan sesuatu seperti kebocoran memori dikesan untuk blok tertentu. Maklumat ini sangat berguna kerana ia memberitahu anda bahawa, walaupun proses masih aktif dan berfungsi, terdapat blok yang menjadi yatim piatu.

memleax amat menarik untuk persekitaran pengeluaran atau pra-pengeluaran di mana Anda tidak mampu untuk memulakan semula perkhidmatan dengan penyahpepijat atau dengan Valgrind dari awal, tetapi anda perlu memahami apa yang berlaku di dalam dari segi pengurusan memori dinamik.

Menggunakan gdb untuk memeriksa memori proses secara mendalam

Jika anda memerlukan tahap perincian yang lebih tinggi dan mampu melakukan penyahpepijatan yang lebih mengganggu, Penyahpepijat GNU (gdb) Ia sekutu anda. Ia alat yang sangat berkuasa yang membolehkan anda sertai proses sedia adaperiksa pembolehubah, panggil tindanan, dan sudah tentu, keadaan timbunan.

Untuk bermula, anda memasang gdb daripada repositori pengedaran anda (contohnya, dengan sudo apt install gdb (pada Debian/Ubuntu) dan kemudian lampirkannya pada proses dengan:

sudo gdb -p

Sebaik sahaja berada di dalam sesi gdb, anda boleh menggunakan pelbagai arahan berkaitan heap. Dalam sesetengah persekitaran, arahan tersebut tersedia secara langsung. heap (atau sambungan yang menyediakannya) untuk menyenaraikan blok memori dinamik yang sedang digunakan, dengan alamat dan saiznya. Output menunjukkan sesuatu seperti senarai ketulan memori, setiap satunya dengan alamat dan saiz, ditanda sebagai sedang digunakan.

Tambahan pula, dari gdb anda boleh menggunakan fungsi libc seperti malloc_stats() melalui:

(gdb) call malloc_stats()

Panggilan jenis ini memberi anda ringkasan keadaan pengagih memori: berapa banyak memori yang telah diperuntukkan, bagaimana timbunan dibahagikan, dsb. Ia merupakan cara yang agak cepat untuk melihat sama ada memori yang diperuntukkan oleh proses tersebut berkembang secara tidak terkawal.

Satu lagi pendekatan yang ampuh adalah dengan meletakkan titik putus dalam fungsi seperti malloc o free untuk memerhati dalam masa nyata bagaimana kod tersebut bertindak: berapa kali ia disimpan, pada ketika mana ia dikeluarkan, laluan kod yang mana membuat banyak peruntukan tetapi sedikit yang bebas… Walaupun ini memerlukan lebih banyak kepakaran penyahpepijatan, ia adalah cara langsung untuk mencari sumber kebocoran yang tepat.

Valgrind: profiler memori klasik dalam Linux

Jika kita bercakap tentang pengesanan kebocoran memori dalam persekitaran Linux, mustahil untuk tidak menyebutnya valgrindLebih daripada sekadar alat, Valgrind ialah rangka kerja penyahpepijatan dan pemprofilan yang merangkumi beberapa modul, yang paling terkenal dan digunakan ialah Memcheck, direka khusus untuk mengesan masalah ingatan.

Memcheck berfungsi dengan menjalankan program anda di dalam sejenis mesin maya yang Ia memintas dan memantau semua operasi berkaitan memori.: peruntukan, keluaran, akses alamat, dsb. Di samping itu, ia menggantikan peruntukan memori standard C dengan peruntukannya sendiri, yang memperkenalkan perlindungan tambahan di sekitar blok yang dikhaskan untuk mengesan akses di luar julat.

Antara jenis ralat yang boleh dikesan oleh Memcheck ialah: Penggunaan memori yang tidak dimulakan, membaca/menulis selepas pembebasan memori, akses haram ke kawasan memori yang bukan milik program dan, sudah tentu, kebocoran memori daripada pelbagai jenis (blok pasti hilang, mungkin hilang, masih boleh dicapai, dsb.).

Penggunaan asasnya agak mudah. ​​Anda mengkompil program anda dengan simbol penyahpepijatan (contohnya, dengan -g o -gstabs) dan kemudian anda menjalankannya di bawah Valgrind dengan sesuatu seperti:

valgrind --tool=memcheck --leak-check=full -v ./tu_programa

Dalam program yang mengurus memori dengan baik, output Memcheck akan menunjukkan ringkasan ralat dengan insiden sifarIaitu, tiada bacaan haram, tiada penulisan di luar julat dan tiada bait timbunan digunakan apabila program keluar. Itu biasanya langkah pertama: mengesahkan kes "bersih" untuk melihat bagaimana pelaksanaan yang bersih.

Jika anda sengaja memperkenalkan malloc tanpa percuma yang sepadanatau sebarang corak kebocoran lain, dan anda menjalankan binari sekali lagi dengan Valgrind, anda akan melihat dalam output a RINGKASAN TIMBANG menunjukkan berapa banyak memori yang masih "digunakan" selepas aplikasi ditutup. Di bawah bahagian RINGKASAN KEBOCORAN Baris seperti "pasti hilang" akan muncul dengan bait dan blok yang belum dikeluarkan.

Di samping itu, Memcheck akan memberitahu anda dengan tepat di mana peruntukan yang menyebabkan kebocoran berlakuAnda akan melihat jejak panggilan dengan fungsi, fail sumber dan nombor baris. Contohnya, ia mungkin menunjukkan bahawa malloc pada baris tertentu fail anda .c Ia telah mewujudkan satu blok yang tidak pernah dikeluarkan, serta-merta menjelaskan punca masalahnya.

Valgrind juga sangat berkesan dalam mengesan ralat klasik yang lain: contohnya, tulisan haram dalam ingatan (seperti menulis ke alamat 0 atau di luar batas tatasusunan), penggunaan pembolehubah yang tidak diinisialisasi (memaparkan mesej seperti “Lompatan atau pergerakan bersyarat bergantung pada nilai yang tidak diinisialisasi”) atau keluaran yang salah (bagaimana untuk melakukannya free pada penunjuk yang tidak datang dari malloc, atau lepaskan blok yang sama dua kali).

Dalam semua kes ini, laporan Memcheck memperincikan di mana akses yang salah atau akses percuma haram berlaku, fungsi mana yang memulakannya, dan di bahagian kod mana pembolehubah itu dicipta atau memori itu dikhaskan, menjadikannya alat yang hampir tidak boleh diketepikan untuk untuk menyahpepijat pengurusan memori secara menyeluruh dalam C dan C++.

Profiler memori lain: gperftools, Massif dan lain-lain

Walaupun Valgrind-Memcheck sering menjadi pilihan pertama, terdapat alat pemprofilan lain yang melengkapi analisis kebocoran memori dan corak penggunaan dengan sangat baik. Salah satunya ialah gperftools (dahulunya Alat Prestasi Google), yang merangkumi profil timbunan mampu merekodkan penggunaan memori dari semasa ke semasa dan menjana laporan visual (contohnya, dengan pprof) yang menunjukkan bahagian kod mana yang menyimpan lebih banyak memori.

Satu lagi alat daripada keluarga Valgrind ialah Besar-besaran, tertumpu khusus kepada profil memori timbunanDaripada hanya menumpukan pada ralat, Massif mengukur saiz timbunan sepanjang pelaksanaan dan menghasilkan data yang kemudiannya boleh anda visualisasikan untuk memahami fasa memori program anda yang paling banyak berkembang dan struktur atau fungsi yang bertanggungjawab.

Secara amnya, profiler ini berfungsi dengan memintas operasi memori dengan cara yang serupa dengan Valgrind atau melalui perpustakaan instrumentasi, dan Mereka merekodkan statistik terperinci tentang peruntukan dan pelepasanAkhir sekali, mereka menyediakan laporan yang merangkumi bilangan peruntukan, jumlah saiz yang dikhaskan, lokasi tertentu dalam kod tempat tempahan paling berat dibuat, dan sudah tentu, blok yang tidak pernah dikeluarkan.

Aliran kerja biasa terdiri daripada jalankan program di bawah profiler (Dalam persekitaran yang sedekat mungkin dengan pengeluaran, tetapi terkawal), hasilkan semula beban kerja atau kes penggunaan yang anda syak menyebabkan kebocoran dan kemudian analisis laporan yang dijana menggunakan alat grafik atau baris arahan. Dengan cara ini, anda dapat melihat sepintas lalu laluan kod mana yang menyebabkan penggunaan memori yang tidak terkawal.

Strategi proaktif: ujian beban, had dan amalan terbaik

Semua perkara di atas membantu mengesan masalah sebaik sahaja ia wujud, tetapi strategi yang ideal adalah mencegah kebocoran daripada sampai ke pengeluaran Atau sekurang-kurangnya tangkap mereka secepat mungkin. Untuk melakukan ini, adalah dinasihatkan untuk menggabungkan beberapa taktik yang berkaitan dengan pengujian, konfigurasi sistem dan kualiti kod.

Pertama sekali, ia sangat masuk akal untuk dilakukan ujian beban dan tekanan dalam persekitaran pra-pengeluaran yang serealistik mungkin. Alat seperti JMeter Apache, Locust, stress Alatan yang serupa membolehkan anda mensimulasikan pengguna serentak, permintaan intensif atau senario yang berpanjangan. Semasa ujian ini, anda harus memantau metrik memori (RSS, heap, dll.) dengan teliti untuk melihat sama ada terdapat sebarang masalah. pertumbuhan yang perlahan tetapi berterusan.

Secara selari, adalah dinasihatkan untuk memantau bukan sahaja metrik mentah, tetapi juga peristiwa sistem seperti OOM KillerPlatform pemantauan dan kebolehcerapan log boleh mengagregatkan maklumat ini dan memaklumkan anda apabila, contohnya, peristiwa OOM terkumpul pada hos tertentu, yang biasanya menunjukkan proses yang tidak berfungsi atau kekurangan sumber.

Pada peringkat konfigurasi sistem, Linux menawarkan mekanisme untuk hadkan impak proses yang "keluar dari kawalan". Sebagai contoh, dengan ulimit Anda boleh mengenakan had memori pada proses yang dilancarkan oleh pengguna tertentu, mengehadkan saiz memori maya mereka. Sesuatu seperti ulimit -v <kilobytes> Ini akan menghalang satu perkhidmatan daripada menggunakan semua RAM hos.

Untuk senario yang lebih maju, kumpulan c (kumpulan kawalan) Ia membolehkan anda mengasingkan dan menyekat penggunaan sumber (CPU, memori, I/O, dll.) mengikut kumpulan proses. Anda boleh mencipta cgroup dengan had memori tertentu dan menetapkan perkhidmatan kepadanya, supaya jika terdapat kebocoran memori, kerosakan dapat dikawal. terkandung dalam kumpulan itu dan tidak menjejaskan keseluruhan sistem.

Akhirnya, dari segi pembangunan, pertahanan terbaik kekal Tulis kod yang mengurus memori dengan baik dari awal.Dalam C/C++, ini bermaksud bersikap teliti dengan setiap malloc/new dan yang sesuai free/delete, gunakan corak RAII, penunjuk pintar (seperti std::shared_ptr, std::unique_ptrdan elakkan menyimpan rujukan yang tidak perlu. Anda juga boleh berunding dengan Tutorial karat Untuk alternatif yang selamat untuk memori. Dalam bahasa dengan pengumpul sampah (Java, C#, Go, Python, JavaScript, dll.), ia juga mudah menyebabkan kebocoran pseudo jika anda menyimpan rujukan langsung kepada objek yang tidak lagi anda perlukan.

Alat dari analisis statik seperti cppcheck, SonarQube Alat dan kaedah ini membantu mengesan corak kod yang mencurigakan semasa pembangunan. Selain itu, semakan kod yang teliti, ujian unit yang mengesahkan tingkah laku di bawah beban dan pengendalian Valgrind atau profiler lain secara berkala dalam persekitaran CI akan mengurangkan kemungkinan kerentanan serius yang sampai ke pengeluaran.

Akhirnya, mengawal kebocoran memori dalam Linux melibatkan penggabungan pemantauan berterusan, alat diagnostik yang berkuasa dan amalan pengaturcaraan yang baikDengan top, htop, /proc, pmap dan smem, anda boleh mencari proses yang mencurigakan; dengan memleax dan gdb anda boleh melakukan pemeriksaan langsung; dengan Valgrind, gperftools atau Massif anda boleh menyahpepijat dan membuat profil secara menyeluruh; dan dengan pengujian beban, had sistem dan kod yang ditulis dengan baik, anda boleh mengelakkan masalah daripada meletup pada saat yang paling teruk.