Linux Sunucularda cgroups ile Kaynak Sınırlandırma Rehberi

Son Güncelleme: Haziran 2026

cgroups, Linux sunucularda işlem gruplarının CPU, bellek, disk I/O ve süreç sayısı gibi kaynak tüketimini kontrol etmeyi sağlayan güçlü bir çekirdek teknolojisidir. Özellikle VPS, VDS, paylaşımlı hosting, uygulama sunucuları ve çok kiracılı sistemlerde kaynak sınırlandırma, performans kararlılığı ve güvenlik açısından kritik öneme sahiptir.

Bu rehberde cgroups kavramını, cgroups v1 ve v2 farklarını, systemd üzerinden kaynak limitlerini, pratik komutları, izleme yöntemlerini ve üretim ortamlarında dikkat edilmesi gereken en iyi uygulamaları adım adım ele alacağız.

İçindekiler

• cgroups Nedir?
• Neden Kaynak Sınırlandırma Gerekir?
• cgroups v1 ve v2 Farkları
• systemd ile cgroups Yönetimi
• CPU, Bellek ve I/O Limitleri
• Uygulama Senaryoları
• İzleme ve Sorun Giderme
• En İyi Uygulamalar
• Sıkça Sorulan Sorular
• Sonuç

cgroups Nedir?

cgroups, açılımı ile control groups yani kontrol grupları, Linux çekirdeği tarafından sağlanan bir kaynak yönetimi mekanizmasıdır. Bu mekanizma sayesinde bir veya birden fazla işlem, belirli bir grup altında toplanabilir ve bu grubun kullanabileceği sistem kaynakları sınırlandırılabilir, önceliklendirilebilir veya izlenebilir.

Geleneksel Linux süreç yönetiminde her işlem sistem kaynaklarını işletim sistemi zamanlayıcısına göre kullanır. Ancak modern sunucu ortamlarında tek bir makine üzerinde birden fazla web sitesi, API servisi, veritabanı, kuyruk işleyici, konteyner veya müşteri hesabı çalışabilir. Bu durumda bir işlemin aşırı kaynak tüketmesi, diğer servislerin yavaşlamasına veya tamamen kesintiye uğramasına neden olabilir. cgroups tam olarak bu problemi çözmek için kullanılır.

cgroups ile yönetilebilen başlıca kaynaklar şunlardır:

• CPU: İşlemci kullanım oranı, çekirdek zamanı ve işlemci payı sınırlandırılabilir.
• Bellek: RAM kullanımı ve bazı yapılarda swap kullanımı kontrol edilebilir.
• Disk I/O: Disk okuma ve yazma işlemleri için bant genişliği veya ağırlık ayarlanabilir.
• PIDs: Bir grubun oluşturabileceği maksimum süreç sayısı belirlenebilir.
• Cihaz erişimi: Belirli cihazlara erişim izinleri yönetilebilir.

Bu yapı, Docker, Kubernetes, LXC, systemd ve birçok sanallaştırma teknolojisinin temelinde yer alır. Örneğin bir konteyner için 2 GB RAM ve yüzde 50 CPU limiti tanımlandığında, arka planda bu sınırlamaların önemli bir bölümü cgroups ile uygulanır.

Corelux üzerinde Sanal Sunucu veya Kiralık Sunucu kullanan sistem yöneticileri, cgroups sayesinde aynı sunucu üzerinde çalışan servisleri daha kontrollü ve tahmin edilebilir hale getirebilir.

Neden Kaynak Sınırlandırma Gerekir?

Kaynak sınırlandırma yalnızca performans optimizasyonu için değil, aynı zamanda güvenlik, hizmet sürekliliği ve maliyet kontrolü için de gereklidir. Bir web uygulaması hatalı bir döngüye girdiğinde, bir PHP worker beklenenden fazla bellek tükettiğinde veya bir yedekleme işlemi diski yoğun kullandığında tüm sunucu etkilenebilir. cgroups bu tür durumlarda hasarı belirli bir servis veya süreç grubu ile sınırlandırmaya yardımcı olur.

Performans Kararlılığı

Sunucuda çalışan kritik servislerin kaynak ihtiyacı her zaman aynı değildir. Yoğun trafik saatlerinde web sunucusu daha fazla CPU kullanırken, gece saatlerinde yedekleme işlemleri disk I/O tüketebilir. Eğer bu işlemler kontrolsüz şekilde çalışırsa, veritabanı gecikmeleri, web sayfası açılış sürelerinde artış ve kullanıcı deneyiminde bozulma yaşanabilir.

• Öngörülebilir performans: Servislerin maksimum kaynak tüketimi tanımlandığı için ani dalgalanmalar daha kolay yönetilir.
• Kritik servis koruması: Veritabanı, web sunucusu veya ödeme altyapısı gibi servisler diğer işlemlerden izole edilebilir.
• Kaynak adaleti: Çok kullanıcılı sistemlerde tek bir hesabın tüm kaynakları tüketmesi engellenir.

Güvenlik ve İzolasyon

cgroups doğrudan bir güvenlik duvarı değildir; ancak kaynak tüketimi üzerinden gerçekleşen hizmet dışı bırakma risklerini azaltır. Örneğin saldırgan bir işlem binlerce alt süreç oluşturmaya çalışırsa, PIDs sınırı sayesinde sistemin süreç tablosu tüketilmeden işlem durdurulabilir. Benzer şekilde bellek limiti, hatalı veya kötü amaçlı bir uygulamanın tüm RAM alanını kullanarak sistemi kararsız hale getirmesini önler.

Maliyet ve Kapasite Yönetimi

Kaynak tüketimini ölçmeden kapasite planlaması yapmak zordur. cgroups ile her servis için belirli limitler tanımlandığında, hangi uygulamanın ne kadar CPU, RAM veya disk I/O kullandığı daha net görülebilir. Bu veriler, sunucu yükseltme, ölçeklendirme veya servis ayrıştırma kararlarında değerli bir temel oluşturur.

cgroups v1 ve v2 Farkları

Linux ekosisteminde iki ana cgroups nesli bulunur: cgroups v1 ve cgroups v2. cgroups v1 uzun yıllar boyunca farklı kontrolcülerin ayrı hiyerarşilerde çalıştığı bir model sundu. cgroups v2 ise daha tutarlı, birleşik ve modern bir hiyerarşi yaklaşımı getirir.

Sunucunuzda hangi cgroups sürümünün kullanıldığını kontrol etmek için aşağıdaki komutlar kullanılabilir:

stat -fc %T /sys/fs/cgroup

Eğer çıktı cgroup2fs ise sistem cgroups v2 kullanıyor demektir. Daha ayrıntılı inceleme için şu komut da yararlıdır:

mount | grep cgroup

Üretim ortamlarında doğrudan cgroups dosya sistemi üzerinde elle işlem yapmak yerine çoğu zaman systemd üzerinden yönetim tercih edilir. Çünkü systemd servisleri, kullanıcı oturumlarını ve slice yapılarını cgroups ile entegre şekilde yönetir.

systemd ile cgroups Yönetimi

Modern Linux dağıtımlarında servis yönetimi büyük ölçüde systemd üzerinden yapılır. systemd, her servis için otomatik olarak bir cgroup oluşturur ve kaynak limitlerini unit dosyaları üzerinden tanımlamaya izin verir. Bu yaklaşım, doğrudan çekirdek cgroup dosyalarıyla çalışmaya göre daha güvenli, okunabilir ve sürdürülebilirdir.

Servis Kaynak Kullanımını Görüntüleme

Çalışan servislerin cgroups tabanlı kaynak tüketimini görmek için systemd-cgtop komutu kullanılabilir:

systemd-cgtop

Bu komut, servis gruplarını CPU, bellek ve görev sayısına göre listeler. Yoğun kaynak tüketen servisleri hızlıca belirlemek için pratik bir araçtır. Ayrıca belirli bir servisin durumunu görmek için:

systemctl status nginx

Komut çıktısında servis süreçleri, ana PID bilgisi ve bazı sistem durumları görüntülenir. Servisin hangi cgroup altında çalıştığını görmek için:

systemctl show nginx -p ControlGroup

Drop-in Dosyası ile Limit Tanımlama

systemd servis dosyalarını doğrudan düzenlemek yerine drop-in yapılandırma dosyası oluşturmak önerilir. Örneğin nginx servisine kaynak limiti tanımlamak için şu komut kullanılır:

systemctl edit nginx

Açılan editöre aşağıdaki örnek yapılandırma eklenebilir:

[Service]
CPUQuota=50%
MemoryMax=512M
TasksMax=300

Değişikliklerden sonra systemd yapılandırması yeniden yüklenmeli ve servis yeniden başlatılmalıdır:

systemctl daemon-reload
systemctl restart nginx

Bu örnekte nginx servisi için CPU kullanımı yüzde 50 ile, bellek kullanımı 512 MB ile ve maksimum süreç sayısı 300 ile sınırlandırılmıştır. Üretim ortamında bu değerler uygulama ihtiyacına, trafik yoğunluğuna ve sunucu kaynaklarına göre dikkatli belirlenmelidir.

CPU, Bellek ve I/O Limitleri

cgroups ile kaynak kontrolü yapılırken en sık kullanılan limitler CPU, bellek ve disk I/O limitleridir. Bu limitlerin her biri farklı davranışa sahiptir. Yanlış yapılandırılan bir CPU limiti performansı gereksiz yere düşürebilir; yanlış belirlenen bellek limiti ise servislerin beklenmedik şekilde sonlanmasına yol açabilir.

CPU Limiti

CPUQuota, bir servisin kullanabileceği işlemci zamanını yüzde olarak sınırlandırır. Örneğin tek çekirdekli bir sistemde CPUQuota=50%, servisin maksimum yarım çekirdek kapasitesi kadar çalışmasına izin verir. Çok çekirdekli sistemlerde yüzde değeri çekirdek sayısına göre yorumlanabilir. Örneğin 4 çekirdekli bir sistemde CPUQuota=200%, yaklaşık iki tam çekirdek kullanımına denk gelir.

[Service]
CPUQuota=200%

CPU limiti belirlerken web sunucusu, veritabanı ve arka plan işleyicileri için ayrı kaynak profilleri oluşturmak faydalıdır. CPU yoğun çalışan raporlama veya medya dönüştürme işlemleri, kritik web servislerinden daha düşük önceliğe alınabilir.

Bellek Limiti

MemoryMax, bir servisin kullanabileceği maksimum bellek miktarını belirler. Bellek limiti aşılırsa çekirdek, ilgili cgroup içindeki süreçlere müdahale edebilir ve bazı süreçleri sonlandırabilir. Bu nedenle bellek limiti belirlenirken uygulamanın normal, yoğun ve tepe kullanım değerleri izlenmelidir.

[Service]
MemoryMax=1G
MemoryHigh=800M

MemoryHigh, sert limitten önce baskı oluşturmak için kullanılabilir. Bu değer aşıldığında sistem ilgili cgroup üzerinde bellek geri kazanımı için daha agresif davranabilir. MemoryMax ise daha kesin bir üst sınırdır.

Disk I/O Limiti

Disk I/O limiti özellikle yedekleme, log işleme, büyük dosya aktarımı, medya işleme ve yoğun veritabanı işlemleri için önemlidir. Bir yedekleme sürecinin tüm disk bant genişliğini kullanması, aynı disk üzerinde çalışan web sitesi veya veritabanı performansını ciddi şekilde etkileyebilir.

[Service]
IOWeight=100

IOWeight, servisin disk I/O önceliğini ağırlık temelli ayarlamak için kullanılabilir. Daha gelişmiş senaryolarda belirli disk cihazları için okuma ve yazma sınırları tanımlanabilir. Ancak cihaz isimleri, disk düzeni ve çekirdek desteği dikkatle kontrol edilmelidir.

Süreç Sayısı Limiti

TasksMax, bir servis veya kullanıcı oturumu altında oluşturulabilecek maksimum görev sayısını sınırlar. Fork bomb yani kendini sürekli kopyalayan süreç saldırıları veya hatalı çalışan uygulamalar için etkili bir koruma katmanı sağlar.

[Service]
TasksMax=500

Bu değer çok düşük belirlenirse web worker, PHP-FPM process, Node.js cluster veya arka plan job işleyicileri beklenmedik şekilde çalışamayabilir. Bu nedenle canlıya almadan önce test ortamında denenmelidir.

Uygulama Senaryoları

cgroups kullanımını daha iyi anlamak için farklı hosting ve sunucu senaryolarını incelemek faydalıdır. Aşağıdaki örnekler, gerçek üretim ortamlarında karşılaşılabilecek yaygın ihtiyaçlara göre hazırlanmıştır.

Senaryo 1: Web Sunucusunu Sınırlandırma

Bir Linux Hosting ortamında Nginx veya Apache gibi web sunucuları, yoğun trafik altında yüksek CPU tüketebilir. Bu durumda web sunucusunun tüm sistemi kilitlemesini önlemek için CPU ve süreç sayısı limiti tanımlanabilir.

systemctl edit nginx

[Service]
CPUQuota=150%
MemoryMax=768M
TasksMax=400

Bu yapılandırma, web servisinin belirlenen sınırlar içinde çalışmasını sağlar. Ancak trafik hacmi yüksekse bu limitler çok düşük kalabilir. Bu nedenle ayarlardan sonra uygulama yanıt süreleri, hata logları ve bellek kullanımı takip edilmelidir.

Senaryo 2: Yedekleme Servisinin Disk Etkisini Azaltma

Yedekleme işlemleri sunucu güvenliği için vazgeçilmezdir; ancak yanlış zamanda ve sınırsız kaynakla çalıştırılan yedekleme süreçleri disk performansını düşürebilir. Corelux Yedekleme Hizmeti gibi çözümlerle birlikte yerel yedekleme scriptleri kullanılıyorsa, bu scriptleri systemd servis veya timer yapısına almak ve I/O ağırlığı tanımlamak yararlı olabilir.

[Service]
CPUQuota=50%
IOWeight=50
MemoryMax=512M

Bu ayar, yedekleme işleminin sistemdeki diğer kritik servisleri daha az etkilemesini sağlar. Özellikle aynı disk üzerinde veritabanı ve kullanıcı dosyaları barındırılıyorsa I/O kontrolü önem kazanır.

Senaryo 3: Arka Plan İş Kuyruklarını Kontrol Etme

Laravel, Node.js veya Python tabanlı uygulamalarda arka plan işleyicileri yoğun CPU ve bellek kullanabilir. E-posta gönderimi, rapor üretimi, görsel işleme ve veri senkronizasyonu gibi işlemler kuyruk üzerinden çalıştırıldığında, worker sayısı ve kaynak limitleri dikkatli yönetilmelidir.

[Service]
CPUQuota=100%
MemoryMax=1G
TasksMax=200

Bu tür uygulamalar için Corelux Uygulama Sunucuları çözümleri, servisleri ayrıştırmak ve kaynakları daha verimli kullanmak isteyen ekipler için uygun bir altyapı yaklaşımı sunabilir.

Senaryo 4: Çok Kiracılı Sunucularda Kullanıcı Bazlı Limit

Birden fazla müşteri veya proje barındıran sistemlerde kullanıcı bazlı kaynak sınırları önemli hale gelir. systemd kullanıcı slice yapıları üzerinden belirli kullanıcı grupları için limit tanımlanabilir. Örneğin belirli bir kullanıcı slice için kaynak sınırı oluşturmak mümkündür.

systemctl edit user-1001.slice

[Slice]
CPUQuota=100%
MemoryMax=2G
TasksMax=600

Bu yaklaşım, özellikle bayi hosting, ajans sunucuları ve proje bazlı izolasyon gerektiren yapılarda yararlıdır. Ancak kullanıcı ID değerleri ve oturum yönetimi dikkatle doğrulanmalıdır.

İzleme ve Sorun Giderme

Kaynak limiti tanımlamak tek başına yeterli değildir. Limitlerin gerçek iş yükü üzerindeki etkisi düzenli olarak izlenmeli, uygulama logları incelenmeli ve gerektiğinde değerler güncellenmelidir. Aksi halde iyi niyetle tanımlanan limitler, uygulama performansını gereksiz yere düşürebilir.

systemd-cgtop ile Anlık İzleme

systemd-cgtop

Bu komut, cgroup bazlı anlık kaynak kullanımını gösterir. Özellikle CPU veya bellek tüketimi beklenenden yüksek olan servisleri tespit etmek için hızlı bir başlangıç noktasıdır.

Servis Özelliklerini Kontrol Etme

Bir servise uygulanan limitleri görmek için systemctl show komutu kullanılabilir:

systemctl show nginx -p CPUQuotaPerSecUSec -p MemoryMax -p TasksMax

Çıktıdaki değerler bazen bayt veya zaman birimi olarak görünebilir. Bu nedenle yapılandırma dosyası ile çalışma zamanı değerlerini birlikte kontrol etmek önemlidir.

cgroup Dosya Sistemini İnceleme

cgroups v2 kullanan bir sistemde servislerin cgroup dizinleri genellikle /sys/fs/cgroup altında yer alır. Örneğin bir servisin bellek kullanımını incelemek için ilgili cgroup dizinindeki dosyalar kontrol edilebilir. Doğrudan müdahale yapmadan önce sadece okuma amaçlı inceleme önerilir.

cat /sys/fs/cgroup/system.slice/nginx.service/memory.current

Benzer şekilde CPU istatistikleri için:

cat /sys/fs/cgroup/system.slice/nginx.service/cpu.stat

Limit Kaynaklı Hataları Tanıma

Bir servis beklenmedik şekilde duruyorsa veya yanıt vermiyorsa, kaynak limitleri kontrol edilmelidir. Bellek limiti çok düşükse uygulama OOM yani out of memory durumuna girebilir. Süreç limiti düşükse yeni worker veya bağlantı süreçleri oluşturulamayabilir. CPU limiti düşükse uygulama çalışmaya devam eder ancak yanıt süreleri artabilir.

journalctl -u nginx --since '1 hour ago'

Loglarda bellek, görev sayısı veya servis yeniden başlatma olayları görülebilir. Bu çıktılar limitlerin fazla agresif olup olmadığını anlamak için değerlendirilmelidir.

En İyi Uygulamalar

cgroups güçlü bir araçtır; ancak doğru kullanılmadığında beklenmedik kesintilere neden olabilir. Bu nedenle üretim ortamlarında planlı, ölçümlenebilir ve kademeli bir yaklaşım tercih edilmelidir.

• Önce ölçüm yapın: Limit tanımlamadan önce servislerin normal ve yoğun dönem kaynak tüketimini izleyin.
• Kademeli ilerleyin: Çok düşük limitlerle başlamak yerine güvenli aralıklar belirleyip zamanla optimize edin.
• Kritik servisleri ayırın: Veritabanı, web sunucusu, kuyruk işleyici ve yedekleme servisleri için ayrı limit profilleri kullanın.
• Test ortamında deneyin: Yeni limitleri canlı sisteme almadan önce test veya staging ortamında doğrulayın.
• Logları düzenli inceleyin: OOM, servis yeniden başlatma, zaman aşımı ve bağlantı reddi gibi belirtileri takip edin.
• Dokümantasyon tutun: Hangi servise neden hangi limitin verildiğini kaydedin.
• Aşırı katı olmayın: Limitler güvenlik ve stabilite içindir; uygulamanın doğal büyümesini engellememelidir.
• Yedek plan oluşturun: Yanlış limit nedeniyle servis kesintisi yaşanırsa hızlı geri dönüş için yapılandırma geçmişi saklayın.

Önerilen Başlangıç Profili

Kaynak limitleri sunucu türüne göre de değerlendirilmelidir. Örneğin Türkiye VDS Sunucu üzerinde düşük gecikmeli yerel projeler için farklı, Bulut Sunucu üzerinde yatay ölçeklenen uygulamalar için farklı stratejiler tercih edilebilir.

Sıkça Sorulan Sorular

Sonuç

Linux cgroups, modern sunucu yönetiminde performans kararlılığı, kaynak adaleti ve servis izolasyonu için temel teknolojilerden biridir. CPU, bellek, disk I/O ve süreç sayısı gibi kritik kaynakları servis bazında kontrol ederek, tek bir uygulamanın tüm sistemi etkilemesini önlemeye yardımcı olur.

En sağlıklı yaklaşım, önce mevcut kaynak tüketimini ölçmek, ardından systemd üzerinden kademeli limitler tanımlamak ve loglar ile performans metriklerini düzenli takip etmektir. Özellikle çok kiracılı hosting ortamları, yoğun trafikli web servisleri, arka plan iş kuyrukları ve yedekleme süreçleri için cgroups yapılandırması önemli avantaj sağlar.

Projeleriniz için izole, yönetilebilir ve ölçeklenebilir bir altyapı arıyorsanız Corelux Sanal Sunucu, Kiralık Sunucu, Hosting ve Uygulama Sunucuları çözümlerini değerlendirebilirsiniz. Doğru altyapı seçimi ve doğru kaynak sınırlandırma stratejisi ile hem performans hem de güvenlik açısından daha sürdürülebilir bir sunucu mimarisi oluşturabilirsiniz.