Bagaimana saya bisa mengalokasikan memori di Linux tanpa melakukan overcommit
Itu adalah pertanyaan yang dimuat, atau setidaknya pertanyaan yang salah. Pertanyaan tersebut didasarkan pada asumsi yang salah, yang membuat menjawab pertanyaan yang disebutkan menjadi tidak relevan, dan paling buruk menyesatkan.
Overcommitment memori adalah kebijakan seluruh sistem -- karena ini menentukan berapa banyak memori virtual yang tersedia untuk proses --, dan bukan sesuatu yang dapat diputuskan sendiri oleh proses.
Terserah administrator sistem untuk menentukan apakah memori overcommitted atau tidak. Di Linux, kebijakannya cukup dapat disesuaikan (lihat misalnya /proc/sys/vm/overcommit_memory dalam man 5 proc. Tidak ada proses yang dapat dilakukan selama alokasi yang akan memengaruhi kebijakan overcommit memori .
OP juga tampaknya tertarik untuk membuat prosesnya kebal terhadap out-of-memory killer (OOM killer) di Linux. (Pembunuh OOM di Linux adalah teknik yang digunakan untuk mengurangi tekanan memori, dengan menghentikan proses, dan dengan demikian melepaskan sumber dayanya kembali ke sistem.)
Ini juga merupakan pendekatan yang salah, karena pembunuh OOM adalah proses heuristik, yang tujuannya bukan untuk "menghukum atau membunuh proses yang berperilaku buruk", tetapi untuk menjaga agar sistem tetap beroperasi. Fasilitas ini juga cukup merdu di Linux, dan admin sistem bahkan dapat menyetel kemungkinan setiap proses dimatikan dalam situasi tekanan memori tinggi. Selain jumlah memori yang digunakan oleh suatu proses, tidak tergantung pada proses untuk memengaruhi apakah pembunuh OOM akan membunuhnya selama situasi kehabisan memori; itu juga merupakan masalah kebijakan yang dikelola oleh administrator sistem, dan bukan proses itu sendiri.
Saya berasumsi bahwa pertanyaan sebenarnya yang coba dipecahkan oleh OP, adalah bagaimana menulis aplikasi atau layanan Linux yang dapat secara dinamis merespons tekanan memori, selain hanya mati (karena SIGSEGV atau oleh pembunuh OOM). Jawabannya adalah kamu tidak -- Anda membiarkan administrator sistem khawatir tentang apa yang penting bagi mereka, sebagai gantinya, dalam beban kerja yang mereka miliki --, kecuali aplikasi atau layanan Anda adalah salah satu yang menggunakan banyak dan banyak memori, dan oleh karena itu cenderung mati secara tidak adil selama memori tinggi tekanan. (Terutama jika set data cukup besar sehingga memerlukan pengaktifan swap dalam jumlah yang jauh lebih besar daripada yang seharusnya diaktifkan, menyebabkan risiko badai swap yang lebih tinggi dan OOM killer yang terlambat tetapi terlalu kuat.)
Solusinya, atau setidaknya pendekatan yang berhasil, adalah mengunci bagian penting (atau bahkan seluruh aplikasi/layanan, jika bekerja pada data sensitif yang tidak boleh ditukar ke disk), atau menggunakan peta memori dengan file pendukung khusus. (Untuk yang terakhir, berikut adalah contoh yang saya tulis pada tahun 2011, yang memanipulasi kumpulan data berukuran terabyte.)
Pembunuh OOM masih dapat mematikan proses, dan SIGSEGV masih terjadi (karena alokasi internal oleh fungsi pustaka yang gagal disediakan oleh kernel untuk dukungan RAM), kecuali semua aplikasi dikunci ke RAM, tetapi setidaknya layanan/proses tidak lagi tidak adil ditargetkan, hanya karena menggunakan banyak memori.
Dimungkinkan untuk menangkap sinyal SIGSEGV (yang terjadi ketika tidak ada memori yang tersedia untuk mendukung memori virtual), tetapi sejauh ini saya belum melihat kasus penggunaan yang menjamin kerumitan kode dan upaya pemeliharaan yang diperlukan.
Singkatnya, jawaban yang tepat untuk pertanyaan tersebut adalah tidak, jangan lakukan itu .