free neden belleğin dolu olduğunu söylüyor? Linux RAM kullanımı

Saat gece iki. Sunucuda free -h çalıştırıyorsunuz ve şunu görüyorsunuz:

               total        used        free      shared  buff/cache   available
Mem:            15Gi        14Gi       312Mi       180Mi       890Mi        620Mi
Swap:          2.0Gi       1.4Gi       600Mi

free sütunu neredeyse sıfır, swap da yarıya kadar dolmuş. İlk tepki sunucunun yetmediği ve RAM eklenmesi gerektiğidir. Çoğu durumda bu çıkarım yanlıştır, ama her zaman değil. Bu iki durum arasındaki fark, para harcamanız mı yoksa bir ayarı değiştirmeniz mi gerektiğini belirleyen şeydir.

free sütunu yalan söylüyor, available sütununu okuyun

Linux çekirdeği boş belleği sevmez. Okunan her dosya, diskten gelen her blok, bir sonraki sefer diskten okumamak için buff/cache içinde tutulur. Bu bellek "kullanılmış" değildir; serbest bırakılabilir. Bir proses ona ihtiyaç duyduğu anda, çekirdek o saniyenin kesri içinde onu geri alır.

available sütunu tam olarak bunu hesaplar: swap'e gitmeden yeni bir prosese ne kadar belleğin ulaşabileceğini. Yukarıdaki çıktıda free 312 megabayt diyor, ama available 620 megabayt diyor. Önemli olan ikinci sayıdır.

Yani ilk kural: eğer available toplam RAM'in %10 ila %15'inin üzerindeyse ve swap sürekli takas halinde değilse, sunucunuzda bellek sorunu yoktur. O 14 gigabayt used çoğunlukla önbellektir ve işi de budur.

Gerçekten ne zaman yetersizlik yaşıyoruz

Birlikte gerçek sorun anlamına gelen üç işaret:

• available sütunu toplam RAM'in %5'inin altında ve ardışık birkaç örnekte düşüyor.
• vmstat 1 5 çıktısı si ve so sütunlarında istikrarlı ve sıfır olmayan bir sayı gösteriyor. Yani sistem sürekli RAM ile swap arasında yer değiştiriyor.
• dmesg -T | grep -i oom içinde Out of memory: Killed process 2841 (php-fpm) gibi bir satır görülüyor.

Eğer üçü de varsa, tartışma bitmiştir. Eğer sadece birincisi varsa ve swap el değmemişse, muhtemelen anlamsız bir sayıya bakıyorsunuz.

Burada hata yapıyorlar: tüketiciyi bulmak yerine servisi yeniden başlatmak

Gerçekten çok gördüğüm kalıp: site yöneticisi available'ın düşük olduğunu görür, MySQL'i yeniden başlatır, sayı iki saat boyunca iyi olur ve sonra geri döner. Servisin hiçbir sorunu yoktu; siz sadece önbelleği çöpe attınız ve sistemi her şeyi diskten yeniden okumaya zorladınız. O iki saat de tam olarak önbelleğin yeniden dolmakta olduğu zamandır.

İşareti şudur: her yeniden başlatmadan sonra RAM kullanımı neredeyse aynı eğimle yükselir ve belirli bir tavanda sabit kalır. Gerçek tüketiciyi yeniden başlatma ile değil, ps aux --sort=-rss | head -15 ile bulun. Eğer php-fpm veya bir WordPress eklentisi gibi bir proses listenin başındaysa ve sürekli büyüyorsa, orada bellek sızıntınız var ve onu düzeltmeniz gerekir.

buff/cache'i manuel olarak boşaltmayın

sync; echo 3 > /proc/sys/vm/drop_caches komutu çalışır ve cezbedicidir. Üretim sunucusunda bunu yapmayın. Sonucu, diskten, NVMe'den veya ağ depolama servisinden yapılan her sonraki okumanın doğrudan I/O'ya gitmesi ve sitenin TTFB'sinin yükselmesidir. Eğer gerçekten test için buna ihtiyacınız varsa, sadece echo 1 yazın ki yalnızca page cache serbest bırakılsın ve testten sonra kendisi yeniden dolsun.

Daha faydalı ayar vm.swappiness'tir. Birçok dağıtımda varsayılan değer 60'tır ki bu bir web sunucusu için muhafazakâr değildir. 16 gigabayt RAM'e sahip bir sunucuda 10 ila 20 değeri daha mantıklıdır: çekirdek mümkün olduğunca swap'i tutar ve sadece gerçekten gerekli olduğunda ona başvurur. Bunu /etc/sysctl.d/99-swap.conf içine koyun ki yeniden başlatmadan sonra da kalsın:

vm.swappiness = 10
vm.vfs_cache_pressure = 50

Daha düşük vfs_cache_pressure değeri çekirdeğin inode ve dentry cache'i daha geç serbest bırakmasını sağlar. Binlerce küçük dosyaya sahip bir sunucuda bu, I/O yükünde belirgin bir fark yaratır.

Linux RAM kullanımı için hangi aracı alalım

Üç yaygın araç, üç farklı iş:

Eğer smem kurulu değilse, ps_mem iyi bir alternatiftir. top'tan farkları, prosesler arası paylaşılan belleği birden fazla kez saymamalarıdır. 20 php-fpm worker'ına sahip bir sunucuda bu fark birkaç gigabayt hata yaratabilir.

Gerçek tavan, hayali tavan değil

Az söylenen bir nokta: sanal makinede free içindeki total sayısı her zaman size satılan şey değildir. Eğer sunucunun 16 gigabayt RAM'i varsa ama çekirdek mem=14G parametresiyle açılmışsa veya hipervizörün balloon driver'ı bir kısmını ödünç almışsa, total daha az gösterir. Herhangi bir karardan önce dmidecode -t memory | grep -i size çıktısını free çıktısıyla karşılaştırın. Eğer bu ikisi uyuşmuyorsa, sorun kapasite değil yapılandırmadır.

Ve eğer tüm bu incelemelerden sonra gerçekten kapasitenin yetersiz olduğu sonucuna vardıysanız, doğru çözüm swappiness'i kurcalamak değil RAM yükseltmektir. Linux hosting üzerinde çalışan WordPress siteleri için genellikle karar vermeniz gereken nokta tam da burasıdır.

Sık sorulan sorular

free neden belleğin dolu olduğunu söylüyor ama site yavaş değil?

Çünkü o bellek aslında proseslerin gerçek kullanımı değil, buff/cache'dir. Linux çekirdeği dosyaları ve disk bloklarını sonraki okumanın daha hızlı olması için RAM'de tutar ve bu bellek gerekli olduğu her anda serbest bırakılır. available sütununa bakın; eğer toplam RAM'in %10'unun üzerindeyse, sunucunuz sağlıklıdır.

free çıktısında used ile available arasındaki fark nedir?

used sütunu proseslerin ve çekirdeğin işgal ettiği ve kolayca serbest bırakılmayan bellektir. available sütunu çekirdeğin swap'e gitmeden yeni bir prosese ulaşabilecek bellek tahminidir ve serbest bırakılabilir buff/cache kısmını da içerir. Karar vermek için her zaman available'ı temel alın.

OOM Killer'ın prosesimi öldürdüğünü nasıl anlarım?

dmesg -T | grep -i "out of memory" komutunu çalıştırın. Eğer proses adı ve PID içeren bir satır görürseniz, çekirdek gerçek bellek yetersizliği nedeniyle onu kill etmiştir. Bu kesin bir RAM yetersizliği işaretidir ve buff/cache ile karıştırılmaz. Bu durumda /var/log/syslog veya journalctl -k günlüğünde de aynı kayıt vardır.

Üretim sunucusunda buff/cache'i boşaltmak güvenli mi?

Güvenlidir ama önerilmez. echo 3 > /proc/sys/vm/drop_caches komutu hiçbir şeyi bozmaz, ama önbelleği çöpe atar ve disk I/O yükünü geçici olarak yükseltir ki bu doğrudan sitenin yanıt süresini etkiler. Eğer sadece test için gerekliyse, echo 1 yeterlidir ve sistem önbelleği kendisi yeniden doldurur.

Sonraki adım belli: bir kez free -h ve vmstat 1 5 çıktılarını yan yana koyun ve si ile so'nun sıfır olup olmadığına bakın. Eğer sıfırsa, o kırmızı free sayısını görmezden gelin ve siteyi yavaşlatan başka bir şeye yönelin. Eğer sıfır değilse, gerçek tüketiciyi ps aux --sort=-rss ile bulun ve oradan başlayın.