Sanal bellek kullanımını anlama> Linux'ta takas + fiziksel

6GB yerleşik belleğe ve 70GB sanal belleğe sahip olduğunu bildiren bir işlemim var. Garip olan şey, bu belirli sunucunun sadece 8GB fiziksel ve 35GB takas alanına sahip olmasıdır.

'Üst' kılavuzdan:

   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.

Bu açıklama göz önüne alındığında, bir işlem için virütal bellek tahsisinin takasım + mevcut fiziksel bellek ile sınırlı olmasını beklerdim.

'Pmap' e göre, bu işlemin kodu, paylaşılan kitaplığı ve paylaşılan bellek bölümlerinin tümü minimumdur - en fazla 300M.

Açıkçası, makine ve süreç hala doğru çalışıyor (yavaş da olsa), burada ne eksik?

Fiziksel koçta veya sayfa dosyasında olmayan sıfır bellek talep edilebilir.

Bakmak isteyebileceğiniz bazı kaynaklar:

• 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

Uygulamanız çok fazla boş bellek sayfası oluşturuyor mu? Öyleyse, başvurunuz aşağıdakilerden büyük fayda sağlayabilir:

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

Gerçek zamanlı bellek sayfalarında sıkıştırmanıza ve sıkıştırmasını açmanıza olanak tanır. Buna karşılık, diske takas etmek yerine her şeyi RAM'de tutabilirsiniz ( çok yavaş ).

İşte virt ve yerleşik belleğe ilişkin bir tartışma:

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

Tartışma Java işlemleriyle ilgilidir, ancak Linux altında çalışan her şey için geçerlidir. Erdem ile ilgili ana nokta, toplamın asla kullanılmayacak bir sürü şey içermesidir. Virt, 32 bit işletim sistemlerine bakılması gereken bir şeydir (işlemler adreslenebilir alandaki sınırlara ulaşacağından), ancak aksi takdirde büyük ölçüde yararlı değildir. Belirtildiği gibi, dikkat edilmesi gereken şey, mevcut fiziksel RAM ve takasınızla sınırlı olacak yerleşik hafızadır.

Bunun nedeni, işlemin adres alanının belirttiğiniz boyutta olması, ancak işletim sistemi tarafından gerçekten ayrılmamış olmasıdır.

Gönderen: http://lwn.net/Articles/428100/

"Yeterince düşük ek yük ve önemli gecikme yok" hedefine ulaşma sürecinde, Go geliştiricileri bazı basitleştirici varsayımlar yaptılar, bunlardan biri çalışan bir uygulama için yönetilen belleğin tek, neredeyse bitişik adres aralığı. Bu tür varsayımlar, editörünüzün vi ile isabet ettiği aynı sorunla karşılaşabilir - diğer kodlar aralığın ortasında parçalar tahsis edebilir - böylece Go geliştiricileri aynı çözümü benimser: sadece ihtiyaç duyduklarını düşündükleri tüm belleği tahsis ederler ( makul olarak, bu 16GB 64 bit sistemde yeterli olmalıdır).

Bu, bellek yönetiminin bazen yapılmasının uygunsuz yolu - sürekli bir adres alanına sahip olmak, kullanılmayan belleği bırakmayı basitleştirir.

Cevap muhtemelen MMAP - veriler diskte, ancak takasın "dışında" ve "serbest" veya "üst" komutuyla görülemiyor.

Java işlemi çok karmaşık değilse, MMAP dosyasının nerede olduğunu bulmak için "lsof" ile oynatmayı deneyebilirsiniz. Ancak bu java süreci karmaşıksa, görülmesi zor olacaktır.

Linux'un fiziksel bellek + takas alanı olduğundan daha fazla sanal bellek ayırmanıza izin verdiğine şaşırdım, ancak görünüşe göre tipik durumlarda performansa yardımcı oluyor.

Neyse ki, bellek muhasebe modunu değiştirmek için kullanılabilecek bir çekirdek ayarlama parametresi var. Bu parametre vm.overcommit_memory şeklindedir ve kullanılabilir belleği izlemek için hangi algoritmanın kullanıldığını gösterir. Varsayılan (0), sezgisel yöntemi kullanır ve sanal bellek sistemini aşar. Programlarınızın, işlemlerinizi rastgele öldürmelere maruz bırakmak yerine, ayırma sırasında uygun bellek yetersiz hataları almasını istiyorsanız, bu parametreyi 2 olarak ayarlamanız gerekir.

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