Memory ballooning di OS


13

Beberapa hypervisor mengoptimalkan penggunaan memori menggunakan metode yang disebut ballooning (setidaknya itulah yang disebut KVM), metode ini mendupuplikasi memori antara VM dan menetapkan halaman umum menjadi hanya-baca dengan copy on write.
Ini adalah kebalikan dari panggilan fork.

Apakah layak untuk diterapkan pada tingkat OS untuk proses (saya terutama memikirkan untuk duplikasi memori saat menjelajah dengan Chromium dengan banyak tab di situs yang sama), apakah sudah diterapkan?

Jawaban:


14

Sebenarnya, apa yang Anda gambarkan membingungkan balon dan 'penggabungan halaman yang sama'. Saya akan mencoba menguraikan keduanya untuk membuat perbedaan menjadi jelas.

Balon memori

Ini adalah trik untuk memastikan bahwa sebagian memori yang dialokasikan untuk mesin virtual tamu tetap dapat digunakan oleh tamu lain atau tuan rumah itu sendiri (cache, dll). Ini dilakukan dengan cara berikut:

Kernel tamu disuntikkan dengan driver, yang memonitor penggunaan memori tamu, dan 'mencuri' beberapa memori yang tidak digunakan (mengalokasikannya sendiri di ruang memori tamu, sehingga memastikan tidak ada pada tamu ini dapat menyentuh kisaran itu).

Kemudian ia memberi tahu kernel host, bahwa ia sebenarnya dapat menghapus halaman memori ini dari inti, bahwa mereka tidak akan digunakan dalam tamu (sampai tamu mengalami beberapa tekanan memori, pada titik mana balon akan mengempis, dan menggunakan rentang ini lagi).

Pada akhirnya, kernel dapat mengalokasikan memori yang sama persis untuk tamu lain, dan membuat seluruh penggunaan memori jauh lebih efisien jika para tamu berjalan dengan banyak memori bebas.

Penggabungan Halaman yang Sama

Teknik ini mengidentifikasi halaman memori yang identik, yang karena alasan tertentu belum ditandai 'semu-baca-saja' dengan copy-on-write, dan menandainya seperti itu.

Sekarang, di level OS, ada kebutuhan terbatas untuk jenis trik ini. Cukup sederhana, sebagian besar waktu ketika Anda memiliki halaman memori yang identik, mereka sudah read-only (kadang-kadang bahkan tanpa Kontrak Karya), karena ini sebagian besar kode aplikasi, perpustakaan dll. Mereka dibuka secara asli melalui Memory Map, dan dengan demikian kernel dapat menyimpan hanya satu salinan dari mereka dalam inti (jika ada sama sekali, itu juga dapat benar-benar mengeluarkannya, dan memungkinkannya untuk dijadikan paging dari toko utama sesuai kebutuhan).

Pada level OS tervirtualisasi, prinsip yang sama diterapkan dengan benar dalam setiap subsistem tamu. Namun, kernel host, tidak tahu apakah dua tamu menjalankan sebagian besar kode yang sama, dan dengan demikian berbagi memori yang sama - para tamu tidak berkomunikasi untuk mengoordinasikan itu.

Itulah sebabnya kadang-kadang dapat memindai seluruh sistem untuk halaman memori yang identik - sebagian besar waktu, mereka akan identik di OS tamu, tidak di dalam masing-masing - kernel tamu membuat pekerjaan yang layak menjaga memori tetap rapi dalam kisaran itu. Dengan demikian, dalam lingkungan VM yang khas, di mana satu host kernel menangani 50+ tamu, penghematan memori bisa sangat besar.

Keduanya sekaligus

Ballooning dan Same-Page-Penggabungan dapat hidup berdampingan dengan sangat baik, mencapai overcommit memori yang cukup besar untuk sistem yang identik.


Untuk menjawab pertanyaan Anda - Penggabungan Halaman yang Sama dan terkadang diaktifkan pada tingkat OS. Ini ada hubungannya dengan berbagi halaman yang ditafsirkan, dan dengan demikian bisa berakhir menjadi identik tanpa memiliki file dukungan yang sama.

Dalam contoh Chromium Anda - biner proses itu sendiri sudah didupuplikasi melalui peta startup hanya baca - mereka memiliki ruang memori yang sama persis. Tembolok halaman (isi tab) biasanya juga dibagi antara proses (read-only copy-on-write) karena cara cache disk dikelola - file pada disk yang sama dapat dibuka secara bersamaan antara berbagai proses di VM rasa-optimal.

Keuntungannya akan paling jelas dengan keadaan bersama mesin Javascript yang berbeda - tapi saya tidak yakin apakah mereka dialokasikan dalam tata letak memori yang sama persis, memastikan bahwa seluruh halaman memori identik.

Ini berbeda pada sistem seluler. Android, misalnya, secara luas mempekerjakan KSM untuk menduplikasi kode identik antara aplikasi yang berbeda.

Dalam kedua kasus tersebut, Anda dapat mengaktifkannya sendiri di Linux (Penggabungan Kernel SamePage). Pengemudi mengekspor berbagai statistik yang, setelah membaca jawaban ini, Anda harus dapat menafsirkan, dan membuat keputusan sendiri apakah itu cocok untuk tujuan Anda.

https://www.kernel.org/doc/Documentation/vm/ksm.txt


3
Penggabungan halaman yang sama juga disebut sebagai 'memori transenden', tergantung pada hypervisor (dan usia itu).
Tim Post

Terima kasih, saya melihat bahwa KSM mengharuskan aplikasi untuk menyadarinya, dan dari pencarian (cepat), Chromium tidak mendukungnya seperti yang sekarang. Saya sadar bahwa binari-binari itu diduplikasi, tetapi kebanyakan saya merujuk pada keluaran JIT dan skrip mentah yang membuat RAM saya sangat berat ...

Skrip mentah di Chromium juga dideduplikasi - mereka mendarat di cache disk seperti halnya semua objek web lainnya, dan cache disk dipetakan, tidak dibaca.
qdot

Skrip baku dipetakan, tetapi bahkan skrip umum (seperti jQuery dan Angular.js) direplikasi dalam cache dan tidak cocok satu sama lain karena ada banyak penggunaan CDN dan replika file skrip yang tepat pada berbagai server situs.

Ini mungkin seharusnya berakhir dalam obrolan, tetapi saya ingin melihat statistik Anda dari KSM Linux.
qdot
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.