Ubuntu Server’da Systemd Resource Limit Tanımlama

Ubuntu Server ortamlarında sistem kaynaklarını etkin bir şekilde yönetmek, sunucu stabilitesini ve performansı artırmak için kritik öneme sahiptir. Systemd, modern Linux dağıtımlarında varsayılan init sistemi olarak hizmet verirken, servislerin CPU, bellek ve dosya tanımlayıcı gibi kaynaklarını sınırlama imkanı sunar. Bu makalede, systemd unit dosyaları aracılığıyla resource limit tanımlama sürecini adım adım inceleyeceğiz. Bu yaklaşım, özellikle yüksek yük altında çalışan uygulamalar için kaynak tüketimini kontrol altına alarak sistem çökmelerini önler ve kaynak paylaşımını optimize eder. Pratik örneklerle destekleyerek, sistem yöneticilerinin hemen uygulayabileceği yöntemleri paylaşacağız.

Systemd Kaynak Limitlerinin Temel Kavramları

Systemd, servislerin kaynak kullanımını kısıtlamak amacıyla çeşitli direktifler sağlar. Bu limitler, servislerin aşırı kaynak tüketerek diğer süreçleri etkilemesini engeller. Örneğin, LimitCPU= ile CPU kullanımını saniye cinsinden sınırlayabilir, LimitMEMORY= ile bellek kullanımını bayt bazında belirleyebilirsiniz. Bu ayarlar, [Service] bölümünde tanımlanır ve systemd’nin cgroup (control group) mekanizmasıyla uygulanır. Ubuntu Server 20.04 ve üzeri sürümlerde bu özellikler varsayılan olarak etkin olup, kalıcı yapılandırma için override dosyaları tercih edilir.

Kaynak limitleri tanımlarken, sistem genelinde tutarlılık sağlamak önemlidir. LimitAS= ile sanal bellek limitini, LimitNOFILE= ile açık dosya sayısını ayarlayabilirsiniz. Bu limitler aşıldığında, servis graceful bir şekilde sonlandırılır veya hata loglanır. Uygulama öncesi mevcut limitleri sorgulamak için systemctl show –property=CPUQuota servicename komutunu kullanın. Bu sayede, mevcut konfigürasyonu inceleyip yeni limitleri buna göre uyarlayabilirsiniz. Her limit değişikliği sonrası daemon-reload ile systemd’nin konfigürasyonu yenilenmelidir.

Resource Limit Tanımlama Adımları

Override Dosyası Oluşturma

Servis konfigürasyonunu değiştirmek için doğrudan orijinal unit dosyasını düzenlemeyin; bunun yerine /etc/systemd/system/servicename.service.d/ dizini altında override.conf dosyası oluşturun. Örneğin, nginx için mkdir -p /etc/systemd/system/nginx.service.d/ && nano /etc/systemd/system/nginx.service.d/override.conf komutunu çalıştırın. Dosya içeriğine [Service] başlığını ekleyin ve limitleri tanımlayın: LimitCPU=20%, LimitMEMORY=512M, LimitNOFILE=65536. Bu yöntem, paket güncellemelerinde ayarlarınızın korunmasını sağlar. Dosya kaydedildikten sonra systemctl daemon-reload komutuyla değişiklikleri yükleyin.

Servis Yeniden Başlatma ve Test

Değişiklikleri uygulamak üzere systemctl restart servicename komutunu kullanın. Limitlerin etkin olup olmadığını doğrulamak için systemctl status servicename ile servis durumunu kontrol edin veya journalctl -u servicename -f ile logları izleyin. Stress testi için stress-ng –cpu 4 –timeout 60s gibi araçlar kullanarak limit ihlallerini simüle edin. Bu adımda, LimitRSS= ile resident set size’ı sınırlayarak bellek sızıntılarını erken tespit edebilirsiniz. Her test sonrası loglarda “Reached limit” gibi uyarılar arayın ve gerekirse limitleri ayarlayın.

Pratik Uygulama Örnekleri

Web Sunucusu İçin CPU ve Bellek Sınırlaması

Apache2 servisi için yüksek trafik senaryolarında kaynak patlamalarını önleyin. Override dosyasında LimitCPU=50%, LimitMEMORY=1G, LimitNOFILE=102400 tanımlayın. Bu ayar, Apache’nin mod_php süreçlerinin aşırı CPU çekirdek tüketimini %50 ile sınırlar ve 1 GB belleği aşmasını engeller. Uygulama sonrası apache2ctl graceful ile yumuşak yeniden başlatma yapın. Performans izleme için top veya htop ile süreçleri gözlemleyin; LimitPROCESSES=100 ekleyerek eşzamanlı süreç sayısını da kontrol altına alın. Bu konfigürasyon, orta ölçekli web siteleri için ideal olup, üretim ortamlarında %20-30 kaynak tasarrufu sağlar.

Özel Uygulama Servisi İçin Gelişmiş Limitler

Kendi yazdığınız bir Node.js uygulamasını systemd servisi olarak çalıştırıyorsanız, /etc/systemd/system/myapp.service dosyasında [Service] bölümüne LimitSTACK=8M, LimitNPROC=50 ekleyin. Bu, stack overflow’ları önler ve süreç fork’larını sınırlar. Servis dosyasını etkinleştirmek için systemctl enable myapp.service yapın. Gelişmiş senaryolarda, Delegate=yes ile cgroup delegasyonu etkinleştirerek alt süreçleri de sınırlayın. Örnek servis dosyası: ExecStart=/usr/bin/node /opt/myapp/index.js. Bu yapılandırma, mikro servis mimarilerinde tutarlı kaynak yönetimi sağlar ve ölçeklenebilirlik artırır.

İzleme ve Bakım Önerileri

Resource limitlerini uzun vadede yönetmek için düzenli izleme şarttır. systemctl show servicename –all ile tüm limitleri listeleyin ve Prometheus gibi araçlarla metrikleri toplayın. Limit ihlalleri sıklaşırsa, logrotate ile journal loglarını yönetin. Ubuntu’nun unattended-upgrades ile sistem güncellemelerini otomatikleştirirken, custom limit dosyalarınızın bozulmadığından emin olun. Periyodik bakımda, systemctl edit servicename ile interaktif override oluşturun. Bu proaktif yaklaşım, downtime’ları minimize eder.

Systemd resource limit tanımlama, Ubuntu Server’larda proaktif sistem yönetiminin temel taşlarından biridir. Bu yöntemleri uygulayarak, servislerinizi daha güvenli ve verimli hale getirebilirsiniz. Düzenli testler ve ince ayarlarla, kurumsal düzeyde performans elde edin; böylece kaynak israfını önleyin ve sistem güvenilirliğini maksimize edin.