systemd ile cgroups v2 kaynak sınırları
11 dakikalık okuma - 3 Haziran 2026

Cgroups v2 ve systemd ile CPU, bellek ve I/O limitlerini ayarlayın. PSI izleme ve dilim izolasyonu ile çok kiracılı Linux ana bilgisayarları için pratik yapılandırma.
systemd ile cgroups v2 kaynak sınırları
cgroups v2, Linux çekirdeğinin birleşik kaynak kontrol çerçevesidir. Parçalanmış v1 hiyerarşisinin yerini, CPU, bellek ve I/O'yu tutarlı bir şekilde yöneten tek bir ağaçla alır ve Docker, Kubernetes ve systemd'de konteyner izolasyonunu destekler. Bu yazıda, cgroups v2'nin nasıl etkinleştirileceği, systemd aracılığıyla sınırların nasıl ayarlanacağı ve bunun gerçek çoklu kiracılı barındırma senaryolarına nasıl uygulanacağı ele alınmaktadır.
cgroups v2'yi etkinleştirme
Modern dağıtımlar, cgroups v2'yi varsayılan olarak etkinleştirilmiş olarak gelir: Ubuntu 21.10+, Debian 11+, Fedora 31+ ve RHEL/Rocky 9+. Eski sistemler hibrit bir hiyerarşi çalıştırabilir veya hala varsayılan olarak v1'i kullanabilir. Şunu kontrol edin:
stat -fc %T /sys/fs/cgroup/
Çıktısı cgroup2fs komutunun çıktısı, v2'nin etkin olduğunu doğrular. tmpfs genellikle v1 anlamına gelir.
Hibrit bir sistemi saf v2'ye geçirmek için /etc/default/grub dosyasını düzenleyin ve GRUB_CMDLINE_LINUX_DEFAULT:
systemd.unified_cgroup_hierarchy=1 cgroup_no_v1=all
Ardından GRUB'u yeniden oluşturun ve sistemi yeniden başlatın:
sudo update-grub
sudo reboot
Üretim ortamında, v2 için cgroup dondurucusunu ve tam cpuset Rocky Linux 8 ve RHEL 8'de, bu satırları /etc/systemd/system.conf:
DefaultCPUAccounting=yes
DefaultMemoryAccounting=yes
DefaultIOAccounting=yes
ile yeniden yükleyin sudo systemctl daemon-reexec. Yeniden başlattıktan sonra, hangi denetleyicilerin kullanılabilir olduğunu doğrulayın:
cat /sys/fs/cgroup/cgroup.controllers
Şunu görmelisiniz cpu, memory, iove pids listelenmiş olmalıdır. Bu denetleyiciler varsayılan olarak alt cgroup'lar için etkin değildir. Bunları etkinleştirmek için kök alt ağacı denetim dosyasına şunu yazın:
echo "+cpu +memory +io" | sudo tee /sys/fs/cgroup/cgroup.subtree_control
v2'nin v1'den dahili olarak nasıl farklı olduğu konusunda kapsamlı bir tur için, Michael Kerrisk'in NDC TechTown konuşması en iyi tek kaynaktır:
systemd'nin cgroup'ları nasıl düzenlediği
systemd, başlattığı her hizmet için birim adını taşıyan bir cgroup oluşturur. nginx.service gets /sys/fs/cgroup/system.slice/nginx.service/ve oluşturduğu her işlem bu cgroup içinde yer alır. Üç birim türü hiyerarşiye doğrudan eşlenir:
| Birim türü | Rol | Açıklama |
|---|---|---|
.slice | İç düğüm | İlgili hizmetleri gruplandırır ve paylaşılan sınırları tanımlar |
.service | Terminal düğümü | Systemd tarafından başlatılan işlemleri yönetir |
.scope | Yaprak düğüm | Dışarıdan başlatılan işlemleri izler (konteyner yükleri, oturum açma oturumları) |
Kutudan çıktığı anda dört varsayılan dilim bulunur: -.slice (root), system.slice, user.sliceve machine.slice. Bir dilime uygulanan herhangi bir sınırlama, otomatik olarak içindeki her hizmete uygulanır.
Hatırlanması gereken bir v2 kuralı: işlemler yalnızca yaprak düğümlerde bulunabilir. Alt cgroup'ları olan bir cgroup, işlemleri doğrudan barındıramaz; bu nedenle systemd, hizmetleri asla bir dilimin gövdesine yerleştirmez.
Sınırları her zaman /sys/fs/cgroup/ . Manuel yazma işlemleri yeniden başlatmalarda kalıcı olmaz ve hiyerarşinin systemd'ye ait olmasıyla çakışır. Tek seferlik değişiklikler ve birim eklemeleri için systemctl set-property dosyasına yazın (systemctl edit nginx.service) kullanın.
CPU sınırları
cgroups v2 size iki CPU kontrolü sunar: bir sabit sınır (cpu.max, CPUQuota ) ve orantılı ağırlık (cpu.weight / CPUWeight).
CPUQuota mutlak bir tavandır. CPUQuota=50% yarım çekirdeğe izin verir; CPUQuota=200% iki tam çekirdek değerinde süreye izin verir. CPU'nun geri kalanı ne kadar boşta olursa olsun, hizmet daha yükseğe çıkmaya çalışırsa kısıtlanır.
CPUWeight sadece çekişme durumunda önemlidir. Aralık 1 ile 10.000 arasındadır, varsayılan değer 100'dür. Ağırlıkları 150, 100 ve 50 olan üç hizmet, hepsi aynı anda CPU zamanı istediğinde, kabaca CPU zamanının %50, %33 ve %17'sini alır. CPU başka bir şekilde boşta olduğunda, ağırlıklar hiçbir şeyi kısıtlamaz.
Gecikmeye duyarlı iş yükleri için, AllowedCPUs=. Bu, bağlam değiştirmeyi azaltır ve çekirdek başına önbelleği aktif tutar:
[Service]
CPUQuota=200%
CPUWeight=150
AllowedCPUs=0-3
Öngörülebilir maliyet gerektiren durumlarda (çoklu kiracı faturalandırma, gürültülü komşu izolasyonu) sabit kota kullanın. Maksimum donanım kullanımı istediğinizde ve sadece yoğunluk anlarında öncelik sıralaması gerektiğinde ağırlıkları kullanın.
cgroups v2 ile bellek sınırları
Bellek iki katmandan oluşur: memory.high (yumuşak, kısıtlama) ve memory.max (sert, OOM). Takas, sayfa geri kazanımı ve çekirdek OOM katili hakkında arka plan bilgisi için, Linux bellek yönetimi hakkındaki ilgili yazımıza bakın.
Ayarlayın memory.high yaklaşık %10 ila %20 memory.max. Bu değer aşıldığında çekirdek sayfaları geri kazanmaya ve memory.high bu eşik aşıldığında sayfaları geri kazanmaya ve tahsisleri kısıtlamaya başlar; bu da genellikle OOM katili devreye girmeden önce iş yükünün toparlanmasına olanak tanır. Kullanım memory.max, çekirdek cgroup içindeki işlemleri sonlandırır.
Tipik bir yapılandırma:
[Service]
MemoryHigh=400M
MemoryMax=512M
MemorySwapMax=0
MemorySwapMax=0 bu cgroup için takas alanını devre dışı bırakır. Takas I/O'sunun kuyruk gecikmesini artıracağı, gecikmeye duyarlı iş yükleri (veritabanları, gerçek zamanlı akış) için yapılmaya değer.
Yetim kalan kardeşleri geride bırakmanın paylaşılan durumu bozacağı işçi havuzları için, 1 cgroup'un memory.oom.group dosyasına yazın. Bir işlem OOM nedeniyle sonlandırıldığında, çekirdek cgroup'taki tüm işlemleri bir arada sonlandırır.
Bir hizmetin ne sıklıkla kısıtlandığını veya OOM nedeniyle sonlandırıldığını görmek için memory.events komutunu kullanarak bir hizmetin ne sıklıkla kısıtlandığını veya OOM nedeniyle sonlandırıldığını kontrol edin:
cat /sys/fs/cgroup/system.slice/nginx.service/memory.events
The high ve oom_kill sayıcıları, sınırlarınızın doğru ayarlanıp ayarlanmadığını gösterir. Sıfırdan farklı değerlerin kalıcı olması, iş yükünün daha fazla boş alana ihtiyaç duyduğu anlamına gelir.
G/Ç sınırları
I/O denetleyicisi aynı iki modlu tasarıma sahiptir: io.max ve io.weight.
Sınırlar, major:minor numaralarıyla tanımlanan blok aygıt başına geçerlidir. Bunları lsblk -o NAME,MAJ:MIN. Tipik bir systemd yapılandırması:
[Service]
IOReadBandwidthMax=/dev/sda 50M
IOWriteBandwidthMax=/dev/sda 30M
IOReadIOPSMax=/dev/sda 1000
IOWriteIOPSMax=/dev/sda 500
io.weight şu şekilde çalışır cpu.weight: aralık 1 ile 10.000 arasındadır, varsayılan değer 100'dür. Müşteriye yönelik bir hizmete 500 ve gece yedeklemesine 50 atamak, yoğun saatlerde yedeklemenin diski doldurmasını engeller, ancak başka hiçbir şeyin ihtiyaç duymadığı zamanlarda tam bant genişliğini kullanmasına izin verir.
I/O sınırları yalnızca doğru aygıtı hedeflediğinizde geçerlidir. Çekirdek, I/O'yu blok aygıtına göre izler, bu nedenle /dev/sda , /dev/nvme0n1. Birden fazla diski olan ana bilgisayarlarda, sınırları aygıt başına ayarlayın.
Dilimlerle çoklu kiracı izolasyonu
Paylaşımlı ortamlar için, her kiracı başına bir dilim tanımlayın. /etc/systemd/system/tenant-a.slice:
[Slice]
CPUQuota=200%
CPUWeight=150
MemoryHigh=3584M
MemoryMax=4096M
MemorySwapMax=0
IOReadBandwidthMax=/dev/sda 200M
TasksMax=512
TasksMax=512 caps, işlem ve iş parçacıklarının toplam sayısını sınırlar; bu sayede bir kiracıda meydana gelen fork bombasının ana bilgisayarı çökertmesi engellenir. Kiracı hizmetlerini bu dilime ( Slice=tenant-a.slice birim dosyalarında) ve her şeyi otomatik olarak devralırlar.
Bu model, gürültülü arka plan işlerini kullanıcıya yönelik hizmetlerden ayırmak için de işe yarar. Yedeklemeleri, günlük rotasyonunu ve toplu işleri background.slice düşük CPUWeight ve io.weight değerleri olan bir dilime yerleştirin. Sistem boşta olduğunda tam kaynaklara sahip olurlar ve üretim trafiği geldiğinde kenara çekilirler.
Docker ve Podman gibi konteyner çalışma zamanları için Delegate=yes . Bu, kök erişimi olmadan kendi alt cgroup'larını yönetmelerine olanak tanır ve üst dilim için belirlenen sınırlar, altındaki her şey için de geçerli olmaya devam eder.
systemd-cgtop ve PSI ile izleme
Cgroup başına CPU, bellek ve I/O'nun canlı top tarzı bir görünümünü elde etmek için şunu çalıştırın:
systemd-cgtop
Statik hiyerarşi ve hangi işlemlerin nerede çalıştığını görmek için şunu kullanın systemd-cgls.
Üretim izleme için en kullanışlı v2 özelliği, Pressure Stall Information (PSI)dır. PSI, bir cgroup'taki görevlerin bir kaynağı beklerken durma süresinin yüzdesini bildirir ve bu bilgi, cgroup başına üç dosyada gösterilir:
cat /sys/fs/cgroup/tenant-a.slice/cpu.pressure
cat /sys/fs/cgroup/tenant-a.slice/memory.pressure
cat /sys/fs/cgroup/tenant-a.slice/io.pressure
%100 kullanım oranına sahip ve %0 basınç değerine sahip bir CPU sağlıklıdır. CPU isteyen her görev, istediğini almaktadır. Aynı CPU'nun %80 kullanım oranına sahip ancak %30 basınç değerine sahip olması, görevlerin çalışma süresi için kuyrukta beklediği anlamına gelir. Kullanım oranına değil, PSI'ye göre uyarı verin: PSI, kullanım metriklerinin tamamen gözden kaçırdığı çekişmeleri yakalar.
Hiçbir şeyi yeniden başlatmadan sınırları canlı olarak ayarlayın:
sudo systemctl set-property tenant-a.slice MemoryMax=6144M
Değişiklik hemen uygulanır ve yeniden başlatmalarda da kalıcıdır. PSI tabanlı uyarılarla birleştirildiğinde, bu özellik yük değişikliklerine, OOM sonlandırmalarına veya kontrolsüz gecikmelere dönüşmeden önce müdahale etmenizi sağlar.
Yüksek yoğunluklu çoklu kiracılı iş yükleri çalıştırıyorsanız ve bu politikaları sorunsuz bir şekilde uygulayabilecek kapasiteye sahip bir ana bilgisayara ihtiyacınız varsa, özel sunucularımız tam da bunun için tasarlanmıştır.
Güçlü ve ölçülmemiş bir VPS'ye sahip olmak neden önemlidir?
Ölçülmemiş bir VPS, sabit bir bağlantı noktası hızında sabit oranlı bant genişliği sağlar. Ölçülü planlardan farkı nedir, ne zaman işe yarar ve satın almadan önce neleri kontrol etmelisiniz.
7 dakikalık okuma - 9 Mayıs 2025
Linux Bellek Yönetimi: Swap, OOM Killer & Cgroups
12 dakikalık okuma - 31 Mayıs 2026

Sorularınız mı var veya özel bir çözüme mi ihtiyacınız var?
Esnek seçenekler
Küresel erişim
Anında dağıtım
Esnek seçenekler
Küresel erişim
Anında dağıtım