systemd Slice ile Bellek ve IO Sınırları: Kaynak İzolasyon Kılavuzu

Benim ortamımda, aynı host üzerinde genellikle birden fazla hizmet çalıştırırım — veritabanları, web uygulamaları, izleme araçları — ve uygun sınırlar olmadan, bir işlem tüm belleği veya disk IO’yu tüketebilir, diğer her şeyi etkileyebilir. İşte burada systemd Slice devreye giriyor. Hizmetleri gruplandırıp slice seviyesinde kaynak kısıtlamaları uygulayabiliyorum, böylece adil paylaşım ve izolasyon sağlanıyor. Bu yaklaşımı, özellikle Proxmox veya bare metal sunucularda karışık iş yüklerinde, gürültülü komşular tarafından kritik sistemlerin etkilenmesini önlemek için kullanıyorum.

Why Use systemd Slice for Resource Control

Konfigürasyona dalmadan önce, bir slice’in ne olduğunu anlamak faydalı. systemd’de, slice, diğer birimleri (hizmetler gibi) organize eden hiyerarşik bir birimdir ve kaynak kontrollerini kolektif olarak uygulamanızı sağlar. Her hizmet için ayrı ayrı sınır tanımlamak yerine, ben bir slice tanımlarım — örneğin web-services.slice — ve hizmetleri ona atarım. Daha sonra bellek ve IO sınırlarını slice’a uygularım. Bu daha temiz ve ölçeklenebilir, özellikle onlarca birimi yönetirken.

Bir log ajanı tarafından sınırsız bellek tüketimi nedeniyle artan bellek tabanlı patlamaları gördükten sonra ilk kez slice’ları kullanmaya başladım. Bu ajanı 512M bellek üst sınırı olan ayrı bir slice’e taşıdığımda, log flood’ı sırasında bile host stabil kaldı. Temel şey, systemd’nin bu sınırları modern dağıtımlarda varsayılan olan cgroups v2 üzerinden zorlamasıdır.

Creating a Custom Slice with Limits

Bellek ve IO sınırları olan bir slice oluşturmak için, drop-in dosyası veya tam bir birim dosyası oluştururum. restricted.slice adlı bir slice için şöyle yaparım:

[Slice]
MemoryMax=512M
IOReadBandwidthMax=/dev/sda 50M
IOWriteBandwidthMax=/dev/sda 30M

Bu dosyayı /etc/systemd/system/restricted.slice.d/limits.conf olarak kaydedip systemd’i yeniden yüklerim:

sudo systemctl daemon-reload

Ardından, hizmet dosyasında Slice=restricted.slice kullanarak herhangi bir hizmeti bu slice’a atayabilirim. Örneğin, özel bir uygulamayı sınırlamak için:

[Service]
Slice=restricted.slice

Düzenledikten sonra hizmeti yeniden başlatırım:

sudo systemctl restart my-app.service

Verifying That Limits Are Applied

Hizmet çalıştığında, sınırların aktif olup olmadığını kontrol ederim. En kolay yolu, cgroup v2 dosya sistemine bakmaktır:

cat /sys/fs/cgroup/system.slice/restricted.slice/memory.max

Bu, 536870912 (512M bayt) göstermelidir. IO için ise:

cat /sys/fs/cgroup/system.slice/restricted.slice/io.max

Sınırlar uygulanmıyorsa, sistemin cgroups v2 kullandığını doğrularım:

mount | grep -E 'cgroup2'

Mount edilmemişse, daha eski Ubuntu LTS sürümlerinde yapmış olduğum gibi, kernel önyükleme parametrelerine systemd.unified_cgroup_hierarchy=1 eklemem gerekebilir.

Monitoring Slice Usage Over Time

Sınırları koymak sadece mücadele yarısı; limitleri düzgün ayarlamak için kullanımı da izlemem gerekir. Gerçek zamanlı görüntü için systemd-cgtop kullanırım:

sudo systemd-cgtop

Bu, her birkaç saniyede bir slice başına bellek ve IO kullanımını gösterir. Daha uzun süreli izleme için, cgroup v2 istatistiklerini toplayan Prometheus node exporter üzerinden gelen metrikleri kullanırım. Bir slice bellek sınırının %90’unu beş dakikadan uzun süre aşarsa, genellikle bir sızıntı araştırmam veya limiti artırmam gerekir — bu durumu daha önce <https://furkanikkan.com/urun/systemd-resolved-ile-dns-over-tls-ve-dnssec-yapilandirma-kilavuzu-102> adlı yazımda da belirttiğim gibi, systemd özelliklerini gözlemlenebilirlikle birleştirerek üretim sistemlerinde güveni artırabileceğimi söylemiştim.

Common Pitfalls and Warnings

Başlangıçta yaptığım bir hata, IO sınırlarını yanlış bloğa aygıtına uygulamak oldu. LVM veya MDADM kullanıyorsanız, temel aygıtı (örneğin /dev/sda) belirtmeniz veya joker karakter kullanmanız gerekir. Ben küçük bir değerle ilk testi yapıp etkisini gözlemlemeyi tercih ederim.

Bir diğer uyarı: MemoryMax’i çok düşük ayarlamak, hizmetlerin OOM ile sonlandırılmasına sebep olur. Ben genellikle yüksek bir değerle (2G gibi) başlar ve logları izleyerek धीरे-धीरे azaltırım. Ayrıca, slice’lar hiyerarşiktir — bir parent slice’ta uygulanan sınırlar, tüm çocuk birimleri etkiler.

Son olarak, cgroups v1 ve v2 konfigürasyonlarını karıştırmaktan kaçının. cgconf gibi eski araçlar güvenilir olmayabilir. Sistemd’nin yerel arayüzüne sadık kalın.

When to Use Slices Over Service-Level Limits

İlgili hizmet gruplarını sınırlamak istediğimde (örneğin, tüm izleme ajansları) Ansible veya Puppet gibi dağıtım araçlarıyla tutarlı gruplama yapmak istediğimde systemd-cgtop gibi araçlarla toplam kullanımı görmek istediğimde

slice’ları tercih ederim. Tek hizmet sınırları için, hâlâ doğrudan hizmet dosyasında sınırları set ederim. Ancak ölçekli izolasyon için, slice’lar benim ilk tercihimdir.

Conclusion

systemd Slice’ı bellek ve IO izolasyonu için kullanmak, benim hostlarımı daha öngörülebilir ve dayanıklı hâle getirdi. Köşe kesmek değil, bir hizmetin tüm sistemi destabilize etmesini önleyecek sınırlar koymak. İş akışına alışınca — slice oluştur, sınırları uygula, hizmetleri ata, izle — bu, güvenilir Linux işlemlerinin bir parçası haline gelir.

Çok kiracılı iş yükleri çalıştırıyorsanız veya sadece bir yedekleme işinin veritabanınızı çökertmesini önlemek istiyorsanız, slice’ları deneyin. Küçük başlayın, staging ortamında test edin, ve oradan ölçeklendirin.

Kapak görseli: Lenharth Systems · CC0 (Openverse / kamu malı) · https://stocksnap.io/photo/cpu-processor-SPQ6DQLFLF