Linux bellek yönetimi açıklaması: swap, OOM killer ve cgroups

Linux, belleği çoğu işletim sisteminden farklı bir şekilde yönetir. Yüksek RAM kullanımı her zaman bir sorun değildir — çekirdek, disk okuma hızını artırmak için boş belleği önbellekleme amacıyla aktif olarak kullanır. Ancak gerçek bellek baskısı oluştuğunda, üç mekanizma devreye girer: swap, OOM killer ve cgroups. Her birinin nasıl davrandığını ve nasıl yapılandırılacağını anlamak, yük altında sorunsuz bir şekilde performansını düşüren bir sunucu ile uyarı vermeden çöken bir sunucu arasındaki farkı belirler.

Linux'un bellek sayfalarını yönetme şekli

Her işlem, 64 bit sistemlerde 128 TB'a kadar kendi sanal adres alanında çalışır. Çekirdek, bu sanal adresleri sayfa tabloları aracılığıyla fiziksel RAM'e eşler ve Translation Lookaside Buffer (TLB) son aramaları önbelleğe alır. Bir TLB isabeti yaklaşık 1 nanosaniye sürer; bir ıskalama ise 20–100 nanosaniyeye mal olur ve bu, veritabanları gibi bellek yoğun iş yüklerinde önemli bir süreye denk gelir.

Fiziksel bellek 4 KB'lık sayfalara bölünür ve çekirdek bunları iki kategoriye ayırır:

• Dosya destekli sayfalar — diskteki dosyalara bağlıdır. Çekirdek, temiz olanları atabilir veya kirli olanları takas yapmaya gerek kalmadan boşaltabilir.
• Anonim sayfalar — destek dosyası olmayan yığın ve yığın belleği. Çekirdek bunları serbest bırakmadan önce bunların takas alanına yazılması gerekir.

Bellek talebinin yüksek olduğu sunucularda, anonim sayfaların oranının yüksek olması, takasın erken devreye girmesine neden olur. si (swap in) ve so (swap out) sütunlarını vmstat 1 — sıfırdan farklı kalıcı değerler, sistemin baskı altında olduğuna dair ilk uyarıdır.

İzleme için, iş için doğru aracı kullanın:

Yaygın bir hata: free sütunu izlemek free -h sütununu izlemek ve paniğe kapılmaktır. available sütun önemlidir. Bu sütun, çekirdeğin talep üzerine önbellekten geri kazanabileceği belleği içerir. Yalnızca 512 MB boş ama 5 GB kullanılabilir alan gösteren bir sunucuda sorun yoktur.

Bellek bir eşik değerin altına düştüğünde, çekirdeğin kswapd daemon arka planda sayfaları geri kazanmaya başlar. Bu yeterli olmazsa, çekirdek doğrudan geri kazanım moduna geçer ve sayfalar serbest kalana kadar işlemleri engeller. Gecikme artışlarının kaynağı budur. MemAvailable toplam RAM'in %10–15'inin altına düştüğünde bir uyarı ayarlayın, böylece müdahale etmek için zamanınız olur.

Swap yapılandırma

Swap, RAM dolduğunda çekirdeğin etkin olmayan anonim sayfaları taşıdığı bir disk alanıdır (bir bölüm veya dosya olabilir). Hız farkı önemlidir: DDR4 RAM'in gecikme süresi yaklaşık 100 ns iken, NVMe SSD'lerde bu süre 100.000 ns civarında ve SATA SSD'lerde 500.000 ns'ye yakındır. Takas alanı, ekstra RAM değil, bir güvenlik tamponudur. Sürekli takas alanına güvenen bir sunucuda, daha fazla takas alanı ile çözülemeyecek bir bellek sorunu vardır.

Bölüm yerine bir takas dosyası kullanın. Boyutunu değiştirmek daha kolaydır ve yeniden bölümleme gerektirmez.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Dosyayı /etc/fstab yeniden başlatmalarda kalıcı olması için. chmod 600 adım gereklidir — RAM'den sayfalara ayrılan tüm veriler takas alanından okunabilir, bu nedenle dosya herkes tarafından okunabilir olmamalıdır.

Swap'ı oluşturduktan sonra, vm.swappiness. Varsayılan değer olan 60, agresiftir. Çoğu barındırma iş yükü için çekirdeğin RAM'i tercih etmesini ve takas dosyasını yalnızca son çare olarak kullanmasını istersiniz:

Takas alanı boyutlandırması için: Ara sıra trafik artışları yaşayan 2 GB'lık bir VPS için 1–2 GB yeterlidir. 8 GB veya daha fazla belleğe sahip sistemlerde, genellikle sabit 2–4 GB'lık bir takas alanı yeterlidir. Amaç, toplam adreslenebilir belleği genişletmek değil, çekirdeğe soğuk sayfalar için bir basınç valfi sağlamaktır.

Yeterli CPU'ya sahip ancak RAM'i kısıtlı sunucularda, zram bellekte sıkıştırılmış bir takas alanı oluşturarak disk I/O'sunu tamamen ortadan kaldırır. NVMe'nin kiracılar arasında paylaşıldığı çok kiracılı VPS barındırma hizmetlerinde bu seçeneği dikkate almaya değer. Takas alanı veritabanı dosyalarıyla aynı aygıtta bulunuyorsa I/O çekişmesine dikkat edin — yoğun takas ve yüksek verimli disk yazma işlemleri birbiriyle uyumlu değildir.

OOM killer

Çekirdek RAM ve takas alanını tüketip başka yollarla yeterli bellek geri kazanamadığında, OOM katili devreye girer. oom_badness() işlevi kullanarak süreçleri puanlar:

points = (rss_anon + rss_file + rss_shmem + swapents + pgtables_pages) + (oom_score_adj × totalpages / 1000)

En yüksek puanı alan işlem sonlandırılır. Formül, büyük bellek tüketicilerini öncelikli olarak değerlendirir ve çekirdek, bir işlemin son 5 saniye içinde sonlandırılıp sonlandırılmadığını kontrol ederek, arka arkaya birden fazla işlemi sonlandırmaktan kaçınır.

Günlüklerde iki tür OOM olayı görünür:

• Global OOM — tüm sistemde RAM ve takas alanı tükenmiştir. Günlüklerde Out of memory:
• Cgroup OOM — bir konteyner veya hizmet memory.max sınırına ulaşmıştır. Günlüklerin başında Memory cgroup out of memory:

Geçmiş OOM olaylarını incelemek için:

dmesg -T | grep -i "out of memory"
journalctl -k --grep="oom"

OOM günlüklerindeki order alanına dikkat edin. 0'ın üzerindeki bir değer, belleğin tamamen tükenmesinden ziyade bellek parçalanmasına işaret eder — çekirdek, kullanılabilir boş bellek olmasına rağmen yeterli sayıda bitişik sayfa bulamamıştır.

OOM katilinin hangi işlemleri hedefleyeceğini /proc/<pid>/oom_score_adj. Aralık -1000 (asla sonlandırma) ile +1000 (önce sonlandırma) arasındadır. systemd tarafından yönetilen hizmetler için, bunu birim dosyasında kalıcı olarak ayarlayın:

[Service]
OOMScoreAdjust=-1000

OOM davranışını ayarlamak için ek sysctl parametreleri:

Proaktif izleme için /proc/pressure/memory (Basınç Durması Bilgisi, çekirdek 4.20'den itibaren kullanılabilir). some avg10 değeri izleyin: %5'in altında olması sağlıklıdır, %20'nin üzerinde kalması ise bir OOM olayının muhtemelen yaklaştığı anlamına gelir. Artan allocstall sayaç /proc/vmstat başka bir erken sinyaldir — genellikle OOM sonlandırmalarından önce gelen doğrudan geri kazanım duraklamalarını sayar. systemd-oomd veya earlyoom gibi araçlar, çekirdeğin OOM katili devreye girmeden önce PSI eşiklerine göre harekete geçebilir.

Cgroups ve bellek sınırları

Kontrol grupları (cgroups), işlemleri gruplar halinde düzenlemenizi ve katı kaynak sınırlamaları uygulamanızı sağlar. Linux 2.6.24 sürümünde tanıtılan bu gruplar, Docker, Podman, Kubernetes ve LXC dahil olmak üzere konteyner çalışma zamanlarının temelini oluşturur. Çekirdek, anonim bellek, dosya destekli sayfalar ve çekirdek nesnelerini kapsayan cgroup başına bellek kullanımını izler. Bir cgroup sınırına ulaşırsa, çekirdek o grup içindeki belleği geri kazanır veya cgroup kapsamlı bir OOM kill işlemini tetikler.

Cgroup v1 ve v2, temel olarak yapıları bakımından farklılık gösterir. V1, her denetleyiciyi (bellek, CPU, I/O) ayrı ayrı /sys/fs/cgroup/<controller>/altında ayrı ayrı bağlar, bu da tutarsız kaynak izlemesine yol açar. V2, /sys/fs/cgroup/kullanır. Kubernetes, 1.25 sürümünde varsayılan olarak v2'ye geçti ve 1.31 sürümünde v1 desteğini kaldırdı.

Sisteminizin hangi sürümü kullandığını kontrol etmek için:

stat -fc %T /sys/fs/cgroup/

cgroup2fs v2 anlamına gelir; tmpfs genellikle v1 anlamına gelir.

cgroup v2'deki temel bellek denetimleri:

Pratik bir kural: memory.high %10–20 civarında memory.max ayarlayın, böylece çekirdeğin sert sınıra ulaşmadan önce geri kazanım yapması için yer açılır. memory.max, cgroup bellek toplamlarına dahil edilen sayfa önbelleğini hesaba katmak için uygulamanın en yüksek kullanımının %20–30 üzerinde bir değer ekleyin.

cgroup dosya sistemine doğrudan yazmak yerine, cgroup'ları systemd aracılığıyla yönetin. MemoryMax=, MemoryHigh=ve MemoryMin= kullanarak kalıcı sınırlar belirleyin. Hızlı testler için:

systemd-run --scope -p MemoryMax=512M <command>

Web sunucusu işçi havuzları için memory.oom.group=1 ayarı, bir işçi sınırını aşarsa temiz bir sonlandırma sağlar — geride yetim süreçler kalmaz. Veritabanı motorları için memory.min , sistem genelindeki yük altında tampon havuzunun geri kazanılmasını önler.

Sunucu rolüne göre bellek yapılandırması

Doğru bellek ayarları, sunucunun ne yaptığına bağlıdır. Aynı yapılandırmayı bir veritabanına ve bir PHP web sunucusuna uygulamak, bunlardan birine zarar verecektir.

MySQL ve PostgreSQL için, kullanılabilir RAM'in %50–70'ini innodb_buffer_pool_size, gecikme artışlarını azaltmak için Şeffaf Büyük Sayfaları devre dışı bırakın ve OOMScoreAdjust=-900 ile koruyun.

PHP-FPM için, işçi havuzlarının boyutunu gerçek bellek kullanımına göre ayarlayın. Her işçi genellikle 30–100 MB kullanır. Güvenli bir pm.max_children değer elde etmek için ayrılan RAM'i ortalama işçi boyutuna bölün. Havuzu sınırlamak için memory.max cgroups'ta havuzu sınırlamak için kullanın.

Yazma yoğun iş yükleri için vm.dirty_ratio değerini yaklaşık %10 ve vm.dirty_background_ratio değeri %3 olarak ayarlayın. Bu, kirli sayfaları daha sık boşaltarak büyük I/O duraklamalarını önler.

Parametreleri /etc/sysctl.d/90-memory.conf. Çalışma zamanında uygulanan ayarlar, yeniden başlatma sırasında kaybolur.

Rol bazında önerilen değerlerin özeti için:

Yüksek yoğunluklu iş yükleri çalıştırıyorsanız ve bu ilkeleri düzgün bir şekilde uygulayabilecek kapasiteye sahip bir sunucuya ihtiyacınız varsa, FDC'nin özel sunucularını incelemeye değer.