Bu görüş, bazı gerçek dünya vakalarında çok yanıltıcı olabilir.
Çekirdek şimdi, MemAvailablealandaki kullanılabilir bellek için bir tahmin sağlamaktadır . Bu değer önemli ölçüde farklıdır MemFree + Cached.
/ proc / meminfo: tahmini kullanılabilir bellek sağlar [çekirdek değiştirme açıklaması, 2014]
Birçok yük dengeleme ve iş yükü yerleştirme programı, ne kadar boş hafıza bulunduğunu tahmin etmek için / proc / meminfo'yu kontrol eder. Bunu genellikle on yıl önce iyi olan "bugün" ve "önbelleğe alınmış" ekleyerek yaparlar, ancak bugün yanlış olduğu garanti edilmektedir.
Önbellek yanlıştır, çünkü paylaşılan bellek segmentleri, tmpfs ve ramfs gibi sayfa önbelleği olarak serbest bırakılamayan bellek içerdiği ve çoğunlukla boşta olan sistemlerde sistem belleğinin büyük bir bölümünü kaplayabilen geri kazanılabilir slab belleği içermez. çok sayıda dosya.
Şu anda, sistemi takas etmeye zorlamadan yeni bir iş yükü için kullanılabilir bellek miktarı MemFree, Active (dosya), Aktif Değil (dosya) ve SReclaimable'dan ve / proc / zoneinfo. Bununla birlikte, bu gelecekte değişebilir ve kullanıcı alanından, çekirdek hafızasının, boş hafıza miktarı için bir tahmin bulması beklenmelidir. / Proc / meminfo'da böyle bir tahmin sağlamak daha uygundur. Gelecekte işler değişirse, sadece tek bir yerde değiştirmek zorundayız.
...
Documentation / filesystems / proc.txt:
...
MemAvailable: Yeni uygulamaları başlatmak için takas olmadan ne kadar bellek bulunduğunun tahmini. MemFree, SReclaimable, LRU listelerinin boyutu ve her bölgedeki düşük filigranlardan hesaplanır. Tahmin, sistemin iyi çalışması için bazı sayfa önbelleğine ihtiyaç duyduğunu ve kullanılmakta olan öğeler nedeniyle geri kazanılabilir tüm döşemelerin geri kazanılamayacağını dikkate almaktadır. Bu faktörlerin etkisi sistemden sisteme değişecektir.
1. Mem Mevcut ayrıntılar
Yukarıda söylendiği gibi, tmpfs ve diğer Shmembellekler serbest bırakılamaz, sadece takas için taşındı. Cachediçinde /proc/meminfoçok nedeniyle bu değiştirilebilen dahil etmek, yanıltıcı olabilir Shmembellek. Bir tmpfs içinde çok fazla dosya varsa, belleğinizin çoğunu işgal ediyor olabilir :-). Shmemayrıca çok büyük olabilecek bazı grafik belleği ayırmalarını içerebilir .
MemAvailablekasıtlı olarak değiştirilebilir bellek içermez. Çok fazla takas yapmak uzun gecikmelere neden olabilir. Takas alanı olmadan çalışmayı seçmiş olabilirsiniz veya yalnızca nispeten sınırlı bir miktara izin vermiş olabilirsiniz.
Nasıl MemAvailableçalıştığını iki kez kontrol etmek zorunda kaldım . İlk bakışta, kod bu ayrımdan bahsetmemiştir.
/*
* Not all the page cache can be freed, otherwise the system will
* start swapping. Assume at least half of the page cache, or the
* low watermark worth of cache, needs to stay.
*/
pagecache = pages[LRU_ACTIVE_FILE] + pages[LRU_INACTIVE_FILE];
pagecache -= min(pagecache / 2, wmark_low);
available += pagecache;
Ancak, doğru bir şekilde Shmem"kullanılmış" bellek gibi davranır bulundu . Bir tmpfs içinde birkaç 1GB dosya oluşturdum. Her 1GB artış 1GB Shmemazaltıldı MemAvailable. Dolayısıyla, "LRU listelemeleri dosyası" boyutu paylaşılan belleği veya başka bir değiştirilebilir belleği içermez. (Bu aynı sayfa sayımlarının "kirli sınır" ı hesaplayan kodda da kullanıldığını fark ettim ).
Bu MemAvailablehesaplama, çekirdeğin "düşük filigranına" eşit olmak için en az yeterli dosya önbelleği tutmak istediğinizi varsayar. Veya mevcut önbelleğin yarısı - hangisi daha küçükse. (Geri kazanılabilir levhalar için de aynı varsayımı yapar). Çekirdeğin "düşük filigranı" ayarlanabilir, ancak genellikle sistem RAM'inin yaklaşık% 2'sidir . Yani sadece kaba bir tahmin istiyorsanız, bu kısmı görmezden gelebilirsiniz :-).
firefoxSayfa önbelleğinde eşlenmiş yaklaşık 100MB program kodu ile çalışırken , genellikle bu 100MB'yi RAM'de tutmak istersiniz :-). Aksi halde, en iyi gecikmeler yaşayacaktır, en kötü sistem tüm zaman geçirecek dayak farklı uygulamalar arasında. Bunun MemAvailableiçin RAM'in küçük bir yüzdesine izin veriyor. Yeterince izin vermeyebilir veya aşırı cömert olabilir. "Bu faktörlerin etkisi sistemden sisteme değişecektir".
Birçok bilgisayar iş yükü için, "çok sayıda dosya" ile ilgili nokta ilgili olmayabilir. Buna rağmen, şu anda dizüstü bilgisayarımda 500MB'lık geri kazanılabilir slab belleğim var (8GB RAM'den). Bunun nedeni ext4_inode_cache(300.000'den fazla nesne). Son zamanlarda disk alanımı neyin kullandığını bulmak için tüm dosya sistemini taramak zorunda kaldım çünkü :-). Komutu kullandım df -x / | sort -n, ancak Gnome Disk Usage Analyzer da aynı şeyi yapardı.
2. [değiştir] Kontrol gruplarındaki bellek
Sözde "Linux kaplar" dan inşa edilmiştir namespaces, cgroupsve diğer çeşitli özellikleri :-) zevkine göre. Neredeyse tam bir Linux sistemi gibi bir şeyi çalıştırmak için yeterince ikna edici bir ortam sağlayabilirler. Barındırma hizmetleri bunun gibi kaplar oluşturabilir ve bunları "sanal sunucular" olarak satabilir :-).
Barındırma sunucuları, ana Linux'ta olmayan özellikleri kullanarak "sanal sunucular" da oluşturabilir. OpenVZ kapsayıcıları ana hat gruplarından iki yıl öncesine kadar uzanır ve hafızayı sınırlamak için "beancounters" kullanabilir. Bu nedenle, yalnızca belgeleri okuduğunuzda veya ana Linux çekirdeği hakkında soru sorduğunuzda, bu bellek sınırlarının nasıl çalıştığını tam olarak anlayamazsınız. cat /proc/user_beancountersgeçerli kullanım ve sınırları gösterir. vzubcbiraz daha kolay bir biçimde sunar. Beancounters ana sayfa satır adlarını belgeler.
Kontrol grupları, içlerindeki süreçlerde bellek limitleri belirleme yeteneğini içerir. Uygulamanızı böyle bir grup içinde çalıştırırsanız, sistem belleğinin tamamı uygulama için kullanılamaz :-). Peki, bu durumda kullanılabilir belleği nasıl görebiliriz?
Bunun için arayüz, cgroup-v1 veya cgroup-v2 kullanmanıza bağlı olarak çeşitli şekillerde farklılık gösterir .
Dizüstü bilgisayarımın kurulumu cgroup-v1 kullanıyor. Koşabilirim cat /sys/fs/cgroup/memory/memory.stat. Dosya dahil olmak üzere çeşitli alanlarını gösterir total_rss, total_cache, total_shmem. tmpfs dahil shmem bellek sınırlarına dahil edilir. Sanırım total_rssters bir eşdeğeri olarak bakabilirsiniz MemFree. Ayrıca, memory.kmem.usage_in_byteslevhalar dahil çekirdek belleğini temsil eden dosya da var . (Her ne kadar bu açıkça belgelenmese memory.kmem.de, memory.kmem.tcp.gelecekteki uzantıları da içerir ) Geri kazanılabilir slab belleğini görüntülemek için ayrı sayaçlar yoktur. CGroup-v1 için belge yok bellek sınırlarını isabet diyor değil herhangi levha bellek yeniden hak tetikler. (Belgede ayrıca "umutsuzca modası geçmiş" ve geçerli kaynak kodunu kontrol etmeniz gerektiği konusunda bir feragatname bulunmaktadır).
cgroup-v2 farklıdır. Kök (üst düzey) grubun bellek muhasebesini desteklemediğini düşünüyorum. cgroup-v2 hala bir memory.statdosyaya sahip. Tüm alanlar alt gruplara göre toplanır, bu nedenle total_...alanları aramanıza gerek yoktur . Bir filealan var, bu da aynı şeyin cacheyaptığı anlamına geliyor . Can sıkıcı bir şekilde rssiçeride olduğu gibi genel bir alan görmüyorum memory.stat; Sanırım tek tek alanlar eklemeniz gerekecek. Geri kazanılabilir ve geri alınamaz slab belleği için ayrı istatistikler vardır; Bence bir v2 cgroup bellek azalmaya başladığında slab geri almak için tasarlanmıştır.
Linux grupları otomatik olarak sanallaştırılmaz /proc/meminfo(veya içinde başka bir dosya bulunmaz /proc), böylece tüm makinenin değerlerini gösterir. Bu, VPS müşterilerini karıştırır. Bununla birlikte , belirli kapsayıcı yazılımı tarafından sahte/proc/meminfo bir dosyayla değiştirmek için ad alanlarını kullanmak mümkündür . Sahte değerlerin ne kadar yararlı olduğu, söz konusu yazılımın ne yaptığına bağlı olacaktır.
systemdcgroup-v1'in örneğin kaplara güvenli bir şekilde devredilemeyeceğine inanmaktadır. systemd-nspawnCgroup-v1 sistemimdeki bir kabın içine baktım . İçine yerleştirilmiş grubu ve bununla ilgili bellek muhasebesini görebiliyorum. Öte yandan, içerdiği systemdkaynak muhasebesi için olağan hizmet başına gruplar oluşturmaz. Bellek muhasebesi bu grup içinde etkinleştirilmemişse, kabın etkinleştiremeyeceğini varsayarım.
Bir cgroup-v2 kabının içindeyseniz, gerçek bir cgroup-v2 sisteminin kökünden farklı görüneceğini ve üst düzey grubu için bellek hesaplamasını görebileceğinizi varsayalım. Veya görebileceğiniz grupta bellek hesaplaması etkin değilse, umarım bellek muhasebesinisystemd (veya eşdeğerini) etkinleştirebilmeniz için yetki verileceksiniz .
MemAvailable, 3.14'te eklendi.