Birden fazla hizmeti tek bir Linux sunucusunda çalıştırıyorsanız ve biri aşırı bellek veya disk IO tüketmeye başlarsa, diğer her şeyi yavaşlatabilir. Bu durum yoğun web sunucularında sıkça yaşar; hatalı bir yedekleme işi veya log işleyici ön uç hizmetini kaynak açığına düşürebilir. Çözüm her zaman daha fazla donanım olmaz — çoğu zaman daha iyi izolasyon yeterlidir. Benim ortamımda, systemd slice'ları ile MemoryMax ve IOWeight'i birleştirerek katı sınırlar uyguluyorum. Böylece diğer hizmetler davranış bozukluğunda bile kritik hizmetler yanıt vermeye devam eder. Temel izolasyon için konteyner veya sanal makine gerekmez; systemd'nin yerleşik cgroup v2 kontrolleri çoğu durumda yeterlidir.
Why Use systemd Slices for Resource Control
Slice'lar, systemd'nin hizmetleri paylaşılan cgroup sınırlarına sahip hiyerarşiler halinde gruplaması şeklindedir. Her hizmet için ayrı ayrı sınır uygulamanın yerine, bunları bir slice içine yerleştirip grubu birim olarak yönetebilirsiniz. Bu, özellikle web sunucusu veya veritabanı gibi temel hizmetlerle interferans olmaması gereken düşük öncelikli arka plan işleri olduğunda çok işe yarar. Genelde temel hizmetler için system-minimal.slice adında bir slice oluştururum; cron işleri veya yedekleme gibi işler için ise batch-low.slice gibi bir slice tercih ederim. Hizmetleri bu slice'lara atayarak grup seviyesinde politikalar zorunlu kılarım — bu, hizmet başına ayarlamaya göre daha basit ve ölçeklenebilirdir.
Creating a Custom Slice with Memory and IO Limits
Önce bir slice birimi dosyası oluşturun. Ben yeniden başlatmalar arasında kalıcı olmasını istediğim için /etc/systemd/system/ içine koyuyorum. İşte düşük öncelikli batch slice için bir örnek:
# /etc/systemd/system/batch-low.slice
[Slice]
MemoryMax=2G
IOWeight=100MemoryMax=2G, bu slice içindeki tüm hizmetlerin toplam bellek kullanımını 2 gigabaytla sınırlar. Bu sınırı aşmaya çalışırlarsa, OOM killer slice içindeki süreçleri sonlandırmaya başlar — ancak slice dışındakileri etkilemez. IOWeight=100, göreceli IO önceliğini ayarlar; varsayılan 100 olduğu için bu, temel erişim anlamına gelir. Gerçekten bunları bastırmak istediğimde, gecelik duyarlı iş yükleriyle birlikte çalıştıklarında bu değeri 50'e veya hatta 10'a indiririmi.
Dosyayı kaydettikten sonra systemd'yi yeniden yükleyin ve slice'ı başlatın:
sudo systemctl daemon-reload
sudo systemctl start batch-low.sliceAktif olup olmadığını systemctl status batch-low.slice ile doğrulayabilirsiniz.
Assigning Services to the Slice
Şimdi hizmetlerinizi bu slice'a taşıyın. my-backup.service gibi bir hizmet için, birim dosyasını düzenleyin ve şunu ekleyin:
[Service]
Slice=batch-low.sliceYeniden yükleyip yeniden başlatın:
sudo systemctl daemon-reload
sudo systemctl restart my-backup.serviceHizmetin doğru slice'ta olduğunu onaylamak için şunu çalıştırın:
systemctl show my-backup.service -p SliceSlice=batch-low.slice çıktısını görmeniz gerekir. Ayrıca cgroup yolunu doğrudan kontrol edebilirsiniz: cat /proc/$(pgrep -f my-backup)/cgroup — bu, /sys/fs/cgroup/ altında slice hiyerarşisini göstermelidir.
Monitoring and Adjusting Limits
Gerçek zamanlı slice ve hizmet kaynak kullanımını görmek için systemd-cgtop kullanırım. Bu, cgroup'lar için top gibi çalışır:
sudo systemd-cgtopMEM% ve IO% sütunlarını izleyerek sınırlarınızın aşılıp aşılmadığını görebilirsiniz. Eğer batch-low.slice içindeki hizmetler bellek tahsisini tam olarak kullanmadan duruk kalıyorsa, daralama IO'da olabilir — bu durumda IOWeight değerini daha da düşürebilirsiniz. Tersi durumda, hizmetler sık sık OOM ile sonlandırılıyorsa, MemoryMax değerini artırmayı veya hizmeti kendi içinde optimize etmeyi deneyebilirsiniz.
Loglama için, slice'a ait journal girişlerini kontrol ederim:
sudo journalctl -u batch-low.slice --since "1 hour ago"Bu, sınır ihlallerini hizmet davranışıyla ilişkilendirmemi sağlar.
Important Caveats and Best Practices
İlk olarak, bu sınırlar yalnızca cgroup v2'de çalışır. Çoğu modern dağıtım varsayılan olarak bunu kullanır, ancak mount | grep cgroup2 ile doğrulayın. Eğer cgroup v1 hiyerarşileri görünüyorsa, birleşik moda geçmeniz gerekebilir — ancak bu konunun kapsamı dışı.
İkinci olarak, temel hizmetlere çok sıkı sınırlar vermeyin. Bir kez sshd.slice'ı düşük bellekli bir slice içine yerleştirmiş ve bir ani artış sırasında kilitlenmişim. Şimdi sadece kesinlikle kritik olmayan, yeniden başlatma güvenli iş yüklerine katı sınırlar uyguluyorum.
Üçüncü olarak, bu yöntemi diğer izolasyon teknikleriyle birleştirin. Daha önce systemd-nspawn'ı riskli komut testleri için kullanarak yazdığım yazımda da belirttiğim gibi, katmanlar işe yarar — ancak slice'lar, ekstra karmaşıklık getirmeden temel hizmet hijyenini sağlamak için harika bir yoldur.
Son olarak, slice yapınızı belgeleyin. Ben /etc/systemd/slice-policy.md içindeki basit bir markdown dosyasında her slice'ın amacı ve sınırlarını listeleyerek bu yapıyı tutarım. Bu, el değiştirme veya denetim sırasında karışıklığı önler.
When to Reach for More
Slice'lar ve temel cgroup sınırları, kaynak çekişmesiyle ilgili sorunlarımın %80'ini çözer. Ancak per-cihaz IO daraltımı (MaxBandwidth) veya gerçek zamanlı CPU garantileri gibi şeyler gerekiyorsa, tam cgroup v2 yapılandırmasına bakın veya sistemd'nin Delegate= özelliğiyle iç içe konteynerlere düşünün. Çoğu bare-metal veya VM iş yükü için iyi tasarlanmış bir slice hiyerarşisi ile MemoryMax ve IOWeight, ekstra yük getirmeden tahmin edilebilir performans sağlar.
Parlak olmayabilir ama üretim ortamında sessiz güvenilirlik, parlak yamalardan her zaman daha değerlidir.
Kapak görseli: [email protected] · CC0 (Openverse / kamu malı) · https://www.thingiverse.com/thing:712213