Karşılaştırma · Linux ve Sistem Yönetimi

Cgroup v2 MemoryHigh ve MemoryMax: Baskı ile Sert Limit Farkı

memory.high baskı ve reclaim üzerinden sınırı aşan iş yükünü yavaşlatabilir; tek başına sert bir kullanım tavanı değildir. memory.max sert sınırdır ve reclaim yetmezse cgroup içi OOM…

Teknik gözden geçirme: 2026-10-06

Mimari ve çalışma modeli

İç içe cgroup sınırlarında üst grup daha dar olabilir. Konteyner veya systemd servisi için görünen 8 GiB limit, parent’ın 6 GiB kısıtını aşamaz. Swap sınırını ve kernel sürümünü ayrıca kaydedin; RSS ölçümü tüm charged memory’yi temsil etmez.

Temel ölçüm olmadan düşük MemoryHigh ayarlamak latency’i büyütebilir. memory.events içindeki high, max, oom ve oom_kill sayaçlarını uygulama p95 ve PSI ile ilişkilendirin. Servisin restart politikası OOM döngüsü yaratmamalıdır.

1Bellek tahsisi
2High baskı/reclaim
3Max sert sınır
4Sayaç ve uygulama etkisi

Parent limitleri okuyun.

Tasarım parametreleri

High eşiği: Normal working set üzerinde pilotla belirleyin; sürekli reclaim hedef değildir.
Max sınırı: Hostu korurken iş yükünün kabul edilen taşma ve hata davranışını tanımlayın.
Sayaç: Servis yeniden başlatıldığında sayaç yaşam döngüsünü dikkate alın.

Platformlardaki uygulama karşılıkları

Servis adları teknik karşılıklardır. Kapsam, varsayılanlar, bölge kullanılabilirliği ve işletim koşulları farklıdır; birebir aynı garanti anlamına gelmez.

Kontrol	Davranış	Gözlem
memory.high	Baskı/reclaim; hard cap değil	high + latency/PSI
memory.max	Hard limit, reclaim/OOM	max/oom/oom_kill
Parent limit	Alt grupları da sınırlar	Tüm hiyerarşi

Hesap ve uygulama örneği

Normal 2 GiB, kısa süreli 3 GiB kullanan lab servisinde High=2500M ve Max=4G pilotlanabilir; bu evrensel öneri değildir. Yükte high sayacı ve p95 artıyorsa eşik baskı yaratıyor olabilir. Max’e ulaşan testte hata ve restart davranışını kontrollü ölçün.

Hata teşhisi

Belirti	Olası neden / ayrım	Doğrulama
Limit aşılmadı ama servis yavaş	High reclaim veya parent baskısı.	memory.events, parent ve PSI değerini karşılaştırın.
OOM tekrar ediyor	Max çok düşük veya sızıntı.	Working set eğrisi ve restart olaylarını inceleyin.

Kabul ve doğrulama kontrolleri

Parent limitleri okuyun.
Normal working set’i ölçün.
High etkisini p95 ile sınayın.
Max altında hata davranışını test edin.
Swap politikasını doğrulayın.
OOM restart döngüsünü engelleyin.

İlgili kavramlar

İzolasyon ile sanallaştırma ayrımı

Container ve sanal makine aynı izolasyon sınırını sunmaz. Containerlar host çekirdeğini paylaşırken sanal makineler konuk işletim sistemi çalıştırır. Rootless kullanım, namespace ve capability kısıtları riski azaltabilir; yapılandırma ve host güvenliği yine önemlidir. Image, çalışan container ve kalıcı volume ayrı yaşam döngülerine sahiptir. Image güncellemek veriyi yedeklemez. Testte process izinlerini, mountları, ağ erişimini ve kalıcı verinin yeniden oluşturma sonrasında korunmasını ayrı ayrı doğrulayın.

Kaynak rekabeti

Kaynak rekabeti, birden fazla iş yükünün aynı CPU, bellek, disk veya bağlantıyı paylaşırken birbirini bekletmesidir. Boş görünen toplam kapasite, tek bir sıcak çekirdek veya tek kuyruk üzerindeki darboğazı gizleyebilir. Aynı anda çalışan backup, antivirüs taraması, indeks bakımı ve kullanıcı trafiğini zaman çizelgesinde karşılaştırın. Kaynak eklemeden önce darboğazın yerini doğrulayın. Testte bir işi tek başına ve diğerleriyle birlikte çalıştırarak paylaşılan kaynağın etkisini ayırın; ortalama kullanım kadar yoğun saatlerdeki gecikmeyi de raporlayın.

Kapasite ve kullanılabilir pay

Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.

Servis yaşam döngüsü ve bağımlılıklar

Çalışan bir process, hizmetin kullanıcıya doğru yanıt verdiğini kanıtlamaz. Başlangıç sırası, ağ veya veritabanı bağımlılığı, ortam değişkenleri, dosya erişimi ve sağlık kontrolü birlikte incelenir. Servis yeniden başlatma döngüsü bazen gerçek nedeni gizler. Exit code, son loglar ve kaynak sınırlarını karşılaştırın. Uygulama dışında systemd veya container yönetim katmanının neden yeniden başlatma yaptığını da kaydedin. Kontrollü restart sonrasında oturum, veri yazma ve bağımlı servislerin davranışını doğrulayın.

Gecikme dağılımı

Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci sırası ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.

Telemetri ve zaman eşleştirmesi

Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; log yokluğu, olay yokluğu şeklinde yorumlanmamalıdır.

Birincil teknik dokümantasyon

Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.

Bilgi Merkezi