Ubuntu Server’da Systemd Service Resource Limit Tanımlama

Ubuntu Server ortamlarında systemd servislerini yönetirken, kaynak limitlerini tanımlamak kritik bir öneme sahiptir. Systemd, modern Linux dağıtımlarında varsayılan init sistemi olarak hizmet vermektedir ve servislerin CPU, bellek, dosya tanımlayıcıları gibi kaynakları aşırı tüketmesini önleyerek sistem istikrarını sağlar. Bu makalede, Ubuntu Server üzerinde systemd servisleri için resource limitlerini nasıl tanımlayacağınızı adım adım inceleyeceğiz. Özellikle üretim ortamlarında çalışan uygulamalar için bu ayarlar, kaynak paylaşımını optimize eder, güvenlik açıklarını kapatır ve beklenmedik çökmeleri engeller. Aşağıdaki bölümlerde temel kavramlardan pratik yapılandırmalara kadar kapsamlı bir rehber sunacağız.

Systemd Servislerinde Resource Limit Kavramları

Systemd, servis birim dosyalarında (unit files) [Service] bölümünde çeşitli resource limit direktifleri sunar. Bu limitler, servislerin sistem kaynaklarını sınırsız kullanmasını önler ve çoklu tenant ortamlarında adil paylaşımı sağlar. Örneğin, LimitNOFILE ile maksimum açık dosya sayısını, MemoryMax ile bellek kullanımını sınırlayabilirsiniz. Bu ayarlar, cgroup v2 tabanlı Ubuntu sürümlerinde (22.04 ve sonrası) daha etkin çalışır ve kernel düzeyinde uygulanır.

Resource limitleri tanımlarken, systemd’nin cgroups entegrasyonunu kullanmak esastır. CPUQuota=20% gibi direktifler, servis CPU kullanımını yüzde olarak sınırlar. Benzer şekilde, TasksMax=1000 ile process sayısını kısıtlayabilirsiniz. Bu limitler, servis yeniden başlatıldığında otomatik uygulanır ve dinamik olarak izlenebilir. journalctl ile logları inceleyerek limit ihlallerini tespit edebilirsiniz.

Yaygın Limit Türleri

En sık kullanılan limitler arasında MemoryHigh ve MemoryMax yer alır. MemoryHigh, bellek kullanımının belirli bir eşiğe yaklaştığında OOM killer’ı tetiklemeden uyarı verir; MemoryMax ise katı bir üst sınır çizer. CPU limitleri için CPUQuota veya CPUShares tercih edilir. Dosya ve ağ limitleri için LimitNOFILE=65536 ve LimitNPROC=1024 gibi değerler standarttır. Bu direktifleri belirlerken, uygulamanızın gerçek ihtiyaçlarını sysctl ve top komutlarıyla analiz edin. Örneğin, bir web sunucusu için bellek limitini 512M olarak ayarlamak, paylaşımlı sunucularda idealdir ve sistem genelinde stabilite sağlar.

Override ve Drop-in Dosyaları

Servis unit dosyalarını doğrudan düzenlemek yerine, /etc/systemd/system/ klasöründe .d uzantılı drop-in dosyaları oluşturun. Bu yöntem, paket güncellemelerinde ayarlarınızın korunmasını sağlar. Örneğin, nginx.service.d/limits.conf dosyası ile [Service] altına limitleri ekleyin. Ardından systemctl daemon-reload komutuyla değişiklikleri yükleyin. Bu yaklaşım, modüler yapılandırma sağlar ve hata riskini minimize eder. Drop-in dosyaları, orijinal unit’i override etmeden genişletir, böylece bakım kolaylaşır.

Resource Limitleri Yapılandırma Adımları

Yapılandırmaya başlamadan önce, mevcut servis durumunu systemctl status servis_adi ile kontrol edin. Ardından, override dizinini oluşturun: sudo mkdir -p /etc/systemd/system/servis_adi.service.d/. limits.conf dosyasını nano veya vim ile düzenleyin ve [Service] başlığı altında limitleri belirtin. Örnek: LimitNOFILE=4096, MemoryMax=256M, CPUQuota=50%.

1. Servis için drop-in dizini oluşturun: sudo mkdir -p /etc/systemd/system/ornek.service.d/
2. limits.conf dosyasını oluşturun ve içeriği yazın:

[Service]
LimitNOFILE=65536
MemoryMax=1G
CPUQuota=25%

1. Değişiklikleri yükleyin: sudo systemctl daemon-reload
2. Servisi yeniden başlatın: sudo systemctl restart ornek.service
3. Doğrulayın: systemctl show ornek.service | grep -E ‘Memory|Limit|CPU’

Bu adımlar, Ubuntu 20.04 ve 22.04’te test edilmiştir. Limit ihlali durumunda servis graceful shutdown yapar ve loglarda “Reached memory limit” gibi mesajlar görünür. İzleme için systemd-analyze ve cgroup bilgilerini kullanın.

Pratik Örnekler ve En İyi Uygulamalar

Node.js tabanlı bir API servisi için örnek yapılandırma: [Service] altına TasksMax=500, IOReadBandwidthMax=/ 10M ekleyin. Bu, disk I/O’sunu sınırlar ve DDoS saldırılarına karşı korur. Bir veritabanı servisi (PostgreSQL) için LimitNPROC=200 ve PrivateTmp=yes ile geçici dosyaları izole edin. Test etmek adına stress-ng ile yük simüle edin: stress-ng –vm 1 –vm-bytes 300M –timeout 60s.

Uygulama Örneği: Web Sunucusu

Apache httpd için /etc/systemd/system/httpd.service.d/limits.conf oluşturun. İçerik: LimitNOFILE=16384, MemoryMax=512M. Yeniden yükleme sonrası, apache2.service status ile MemoryCurrent değerini izleyin. Bu ayar, yüksek trafikli sitelerde bellek şişmesini önler ve sunucu ömrünü uzatır. Gerçek üretimde, bu limitleri Prometheus ile entegre ederek grafik raporlar alın.

Sorun Giderme İpuçları

Limit aşımlarında “systemd-oomd” etkinse otomatik müdahale eder. Hata için journalctl -u servis_adi -f kullanın. Eğer limit çok düşükse, servis başarısız olur; gradual artırma yapın. Ubuntu’da cgroup v1’den v2’ye geçiş için boot parametresini systemd.unified_cgroup_hierarchy=1 olarak ayarlayın. Bu adımlar, yaygın sorunları çözer ve yapılandırmayı optimize eder.

Bu rehberle, Ubuntu Server’ınızda systemd servisleri için etkili resource limitler tanımlayabilirsiniz. Düzenli izleme ve ayar incelemeleriyle sistem performansınızı maksimize edin, olası riskleri proaktif yönetin. Uygulamalarınızı güvenli ve verimli kılmak için bu teknikleri hemen deneyin.