Memahami penggunaan memori virtual> swap + fisik di Linux

Saya memiliki proses yang melaporkan di 'atas' bahwa ia memiliki 6GB memori penduduk dan 70GB memori virtual yang dialokasikan. Yang aneh adalah bahwa server khusus ini hanya memiliki 8GB fisik dan 35GB ruang swap yang tersedia.

Dari manual 'top':

   o: VIRT  --  Virtual Image (kb)
      The total amount of virtual memory used by the  task.   It  includes
      all  code,  data  and  shared  libraries  plus  pages that have been
      swapped out. (Note: you can define the STATSIZE=1 environment  vari-
      able  and  the VIRT will be calculated from the /proc/#/state VmSize
      field.)

      VIRT = SWAP + RES.

Dengan penjelasan ini, saya berharap alokasi memori virutal untuk suatu proses terbatas pada memori fisik swap + saya.

Menurut 'pmap', kode, pustaka bersama, dan bagian memori bersama dari proses ini semuanya minimal - tidak lebih dari 300 juta.

Jelas, mesin dan prosesnya masih berfungsi dengan benar (walaupun lambat), jadi apa yang saya lewatkan di sini?

Mungkin permintaan nol memori yang tidak di ram fisik, atau di pagefile.

Beberapa sumber daya yang mungkin ingin Anda lihat:

• http://www.gitam.edu/eresource/comp/gvr(os)/13.6.htm
• http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.system/2006-11/msg00176.html

Apakah aplikasi Anda membuat banyak halaman memori kosong? Jika demikian, aplikasi Anda mungkin mendapat manfaat besar dari:

• http://code.google.com/p/compcache/ ( EXPERIMENTAL )

Ini memungkinkan Anda untuk kompres dan dekompresi di halaman memori real-time. Pada gilirannya, Anda dapat menyimpan semuanya dalam RAM daripada menukar ke disk ( sangat lambat ).

Berikut adalah diskusi tentang kebajikan vs memori penduduk:

/programming/561245/virtual-memory-usage-from-java-under-linux-too-much-memory-used

Diskusi mengacu pada proses Java, tetapi berlaku untuk apa pun yang berjalan di Linux. Poin utama sehubungan dengan kebajikan adalah bahwa total mencakup banyak hal yang mungkin tidak pernah digunakan. Virt adalah sesuatu untuk dilihat untuk OS 32-bit (karena proses akan mencapai batas pada ruang addressable), tetapi sebagian besar tidak berguna sebaliknya. Seperti dicatat, hal yang perlu diperhatikan adalah memori penduduk, yang akan terbatas pada RAM fisik yang tersedia dan swap Anda.

Ini kemungkinan karena ruang alamat proses adalah ukuran seperti yang Anda nyatakan, tetapi tidak benar-benar dialokasikan oleh OS.

Dari: http://lwn.net/Articles/428100/

Dalam proses mencoba mencapai tujuan "overhead yang cukup rendah dan tidak ada latensi yang signifikan," para pengembang Go telah membuat beberapa asumsi penyederhanaan, salah satunya adalah bahwa memori yang dikelola untuk aplikasi yang sedang berjalan berasal dari satu, hampir bersebelahan rentang alamat. Asumsi tersebut dapat mengalami masalah yang sama dengan editor Anda - vi - kode lain dapat mengalokasikan bagian di tengah rentang - sehingga pengembang Go mengadopsi solusi yang sama: mereka hanya mengalokasikan semua memori yang mereka pikir mungkin mereka butuhkan (mereka pikir, wajar, bahwa 16GB harus mencukupi pada sistem 64-bit) pada saat startup.

Jadi itulah cara manajemen memori yang tidak sengaja dilakukan kadang-kadang - memiliki ruang alamat yang terus-menerus menyederhanakan pengeluaran memori yang tidak terpakai.

Jawabannya mungkin MMAP - data ada di disk, tetapi "di luar" swap dan tidak dapat dilihat dengan perintah "bebas" atau "atas".

Jika proses java tidak terlalu rumit, Anda dapat mencoba bermain dengan "lsof" untuk menemukan di mana file MMAP berada. Namun jika proses java ini rumit, akan sulit terlihat.

Saya juga terkejut bahwa Linux memungkinkan Anda untuk mengalokasikan lebih banyak memori virtual daripada ada memori fisik + ruang swap, tetapi ternyata itu membantu kinerja dalam situasi tertentu.

Untungnya, ada parameter tuning kernel yang dapat digunakan untuk mengganti mode akuntansi memori. Parameter ini adalah vm.overcommit_memory, dan ini menunjukkan algoritma mana yang digunakan untuk melacak memori yang tersedia. Default (0), menggunakan metode heuristik dan overcommits sistem memori virtual. Jika Anda ingin program Anda menerima kesalahan kehabisan memori yang sesuai pada alokasi alih-alih menjadikan proses Anda sebagai pembunuhan acak, Anda harus mengatur parameter ini menjadi 2.

http://www.linuxjournal.com/article/10678