Zram kullanırken vm.swappiness'in uygun değeri nedir?


13

Sıkıştırılmış RAM destekli takas olarak bilgisayarımda zram kullanıyorum. Sistemin bir şeyi çıkarması gerektiğinde, dosyayı zram destekli bir takas dosyasına takas etmek, yer açmak için bellekteki verileri sıkıştırmakla hemen hemen eşdeğerdir. Bu, disk destekli değişime göre çoğu zaman çok hızlı bir şekilde değiştirmeyi sağlar. Bu nedenle, sistemi kullanılmayan şeyleri daha agresif bir şekilde değiştirmeye teşvik ederek kazanılacak bir performans olup olmadığını merak ediyorum, çünkü diske gerçekten çarpmadan bunu yapabilir mi?

Diyelim ki, vm.swappinesszram kullanırken 100'e ayarlanan var mı? Bu arzu edilir mi?

sysctl -w vm.swappiness=100

2
Bu mükemmel bir soru ve ben fikirleri kaldırmak ve gerçeklere ulaşmak için bazı kıyaslama olduğunu düşünüyorum ...
Elder Geek

İyi fikir ve zram, son kullandığım 2012'den beri iyileşmiş olabilir :-)
Huygens

Küçük bir test yaptım ve anladığım kadarıyla bellek zram için "ayrılmış" hala önbellek olarak kullanılıyor. Bu onaylanırsa, CPU döngülerini önlemek için swappiness'i düşük tutmanın mantıklı olabileceğini düşünüyorum?
Vitor

Yanıtlar:


2

Ben gerçekten swappiness daha yüksek koymak için tavsiye etmem. Çekirdekte yaygın bir mekanizma, diğer çalışan görevler için biraz bellek boşaltmak için sayfaları (bellek yığını) takas haline getirmesidir.

Çekirdek n sayfanın serbest bırakılmasını istediğinde ilk "sorun", m (m <n ile m, n tutmak için gerekli sıkıştırılmış sayfa sayısıdır) RAM'de yeni oluşturulduğundan emin değilim, çekirdeği rahatsız edebilir mi yoksa değil.

Her neyse, takasta sayfalarınız olduğunda, uygulamayı daha sonra takastaki bazı sayfalarıyla birlikte kullanmak mümkündür. Çekirdek ne yaparsa, bu sayfaları fiziksel belleğe geri getirmektir, ancak bunları takastan çıkarmaz (standart takas ile önbellekleme olarak görülebilir , bu nedenle uygulama arka planda geri döndüğünde, çekirdeğin bu sayfaları geri yazmak zorunda kalmaz yavaş takas içine). Ancak zram ile bu belki akıllıca bir hile değildir, çünkü daha sonra hafızada mram zram + n geri belleğe n sayfa var!

Çekirdeğin normalde işini yapmak için kullanabileceği bir "toplam belleği" vardır. Zram eklediğinizde, yalnızca "takas" belleğinde, herhangi bir disk tabanlı takasta olduğu gibi sayılır, ancak gerçek "toplam belleği" azaltır ve bu çekirdek tarafından beklenmez / beklenmez. Bazen bu yüzden garip olabilir ve istemediğiniz davranışlar olabilir!

Zram ile, bellek baskısı altındayken çekirdeğin bu alana çok fazla takas yapmaması iyi olur. Ve her zaman gerçek bir sabit disk takas bölümünüzün en az zram maksimum boyutunuzdan daha büyük olması gerekir, böylece sistem OOM almaz, aynı zamanda rapor edildiği gibi bol miktarda boş alan görürsünüz free!


zram RAM blok cihazları sağlar. Bu blok cihazlara yazılan her şey sıkıştırılır. Eğer zram blok cihazları takas olarak kullanılırsa, sistem bellek parçalarını takas etmek için hareket ettirmeye çalıştığında, belleğe RAM'in bir kısmından diğerine etkili bir şekilde taşınır, ancak veriler hedefe kopyalanmadan önce sıkıştırılır. Bu, sınırlı miktarda belleğe sahip sistemlerde yanıt hızını artırmak için ucuz bir bellek sıkıştırma mekanizması olarak etkili bir şekilde çalışır. ... Zram Linux 2.6.33'ten beri sahne alıyor. 3.14'te zram evrelemeden sürücüler / blok / zram'a taşındı.
Elder Geek

1
@ElderGeek tam olarak! Ve bunun neden mükemmel olmadığını göstermek için bir örnek alacağım. Çekirdek 64MB RAM'i çıkarmaya çalışacak, onları zram takasına sokacak. Sıkıştırılmış 64MB yığın şimdi 32MB. Sonuç olarak, bellek 64 MB değil, 32 MB azaltıldı. Şimdi uygulama belleğe 64MB geri ihtiyaç duyduğunda ne olur, çekirdek kopyayı belleğe kopyalar (ve taşımaz). Artık RAM'de 64MB + zram'da 32MB var. Neden kopyalanmalı? Çünkü çekirdek cevabımda açıkladığım gibi sayfaları önbelleğe alıyor. Her iki davranış da ideal değildir. Ve bellek iyi sıkıştırılamadığında, bu daha da kötüdür.
Huygens

Hala test aşamasında. Sıkıştırılmamış RAM'e geri kopyalandığında sıkıştırılmış sayfayı boşaltmak için zram'ın kullandığı önbellek algoritmasını ayarlamanın bir yolu olması gerektiğini düşünürdüm.
Elder Geek

2012'ye kadar birkaç kez denedim. O zaman bilgisayarım 1GB RAM ile sınırlıydı ve internette gezinirken acı verici bir şekilde yavaştı (genellikle 10-50 sekme açtım). Ama o zamandan beri bir daha asla kullanmadım. Artık takas kullanmadığımdan fazla RAM var. O zamanlar Firefox ile zram kullanırken, sahip olduğum küçük RAM göz önüne alındığında hızlı bir şekilde "değiştirmeye" başladım. Ve çabucak birçok çökme ile yanıt vermeyen sistemlerim oldu. Zram olmadan ağrılı yavaştı ama en azından kararlıydı. Benim sorunum muhtemelen sürekli sıkıştırma / sıkıştırma bellek sayfaları oldu.
Huygens

Evet, sonuçlarım biraz benzerdi, 8GB'lık bir sistemde bir kodlama işi sırasında birkaç VM başlatarak bir OOM'yi zorlayabildim. Zswap ile ilgili bir deneyiminiz var mı? Okuduğum şeye göre uygun bir alternatif gibi görünüyor.
Elder Geek

2

Kısa cevap: vm.swappiness=100olup uygun değeri zram için (Linux 4.9 ile Debian Stretch En azından ben böyle iyi bir değer olduğuna inanıyoruz)

Zaten vm.swappiness=100beni test ediyorum .

Hangi değerin sizin için en iyi olduğundan emin olmak için basit bir test yapabileceğinizi düşünüyorum .

Ayrıca bu soruyu test etmek için basit bir program daha yaptım . x Makinemde çok düşük bir vm.swappinessdeğer (örneğin vm.swappiness=1) belirgin yanıt verme sorununa neden olacaktır.

Hakkında SwapCachediçinde /proc/meminfo:

İlk olarak, deneyin vm.page-cluster=0, bu belki takastan yararsız bazılarını azaltabilir SwapCached.

SwapCached, zram'ı zram olmayan takas cihazıyla aynı şekilde hızlandırabilir

SwapCached gerektiğinde tekrar kullanılabilir (ücretsiz):

./linux-4.9/mm$ grep -rn delete_from_swap_cache
memory-failure.c:715:   delete_from_swap_cache(p);
shmem.c:1115:       delete_from_swap_cache(*pagep);
shmem.c:1645:            * unaccounting, now delete_from_swap_cache() will do
shmem.c:1652:               delete_from_swap_cache(page);
shmem.c:1668:       delete_from_swap_cache(page);
vmscan.c:673:       __delete_from_swap_cache(page);
swap_state.c:137:void __delete_from_swap_cache(struct page *page)
swap_state.c:218:void delete_from_swap_cache(struct page *page)
swap_state.c:227:   __delete_from_swap_cache(page);
swapfile.c:947:         delete_from_swap_cache(page);
swapfile.c:987: delete_from_swap_cache(page);
swapfile.c:1023:            delete_from_swap_cache(page);
swapfile.c:1571:            delete_from_swap_cache(page);
./linux-4.9/mm$ 

0

Bellek dolduğunda sayfaların çıkarılması (diske) alınması gerekir. Bellek dolduğunda sayfaları değiştirmek için yer oluşturmak için bellek kullanıyorsanız, sıkıştırma fark yaratıyorsa (ve sonra belleği doğrudan yerine sıkıştırmak doğal olur) takas). Bilgisayarlar bellek hızına kıyasla giderek daha hızlı sıkıştırma ve açma işleminde olduğu için tahmin etmek gerekir.


Sistemin belleği azaldığında zram destekli takasın oldukça yardımcı olduğunu gördüm. Cehennemi takas etmek ve yeniden başlatmak zorunda kaldım. Sadece vm.swappinessdeğerin disk destekli takas için ayarlanıp ayarlanmadığını ve çoğunlukla zram destekli takas kullanacaksam değiştirmem gerektiğini merak ediyorum .
Ryan

1
"giderek daha hızlı"? Sinek sıkıştırma Açık (- noktası değil onun asla bellek erişimi daha hızlı olacak) Son on yılı aşkın süredir G / Ç doğrudan diske göre daha iyi performans gösteren
symcbean

symcbean, "bellek hızıyla karşılaştırıldığında" unuttun. Anlaşmazlık nerede?
Alexander

Symcbean'nın amacı sıkıştırılmış bellek destekli sayfaların (zram) amacının fiziksel ortama değiştirmektir. "Belleği doğrudan sıkıştırmanın doğal olmasının" nedeni, uygulamaların belleğinin hangi bölümlerinin ne zaman sıkıştırılabileceğini belirlemesi gerektiğinden karmaşıklıkla dolmasıdır; VM alt sistemi bunu uygulamak için çok daha kolay bir yerdir. Zram'dan yararlanan iş yükleri, çalışma kümesinde olmayan ve kolayca sıkıştırılabilen sayfalara sahiptir.
Daniel Papasian
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.