Linux I/O zamanlayıcı ayarlaması: mq-deadline, none ve BFQ

Linux I/O zamanlayıcı, okuma ve yazma isteklerinin depolama aygıtınıza ulaşma sırasını belirler ve doğru seçim neredeyse tamamen donanımınıza bağlıdır. NVMe için none NVMe için, mq-deadline karışık iş yükleri çalıştıran SATA SSD'ler ve HDD'ler için bfq bir işlemin diğerlerini engellememesi gerektiğinde kullanın. Bu kılavuz, üç ana zamanlayıcının nasıl çalıştığını, iş yükünüze hangisinin uygun olduğunu ve sonucu nasıl ayarlayıp doğrulayacağınızı ele almaktadır.

Okumadan önce uygulamalı bir kılavuz istiyorsanız, bu video terminalden zamanlayıcıları değiştirme ve test etmenin temellerini ele almaktadır.

mq-deadline, none ve BFQ arasındaki farklar

Her zamanlayıcı, istekleri farklı bir stratejiyle işler. Bunların nasıl farklılık gösterdiğini bilmek, önyükleme sırasında çekirdeğin seçtiği şeyi çalıştırmak yerine bilinçli bir seçim yapmanızı sağlar.

mq-deadline

mq-deadline mq-deadline zamanlayıcı, hiçbir isteğin sonsuza kadar beklememesini sağlar. Okuma ve yazma işlemleri için ayrı sıralı kuyruklar tutar, arama süresini kısaltmak için bunları Mantıksal Blok Adresine göre sıralar ve son tarihleri uygular: varsayılan olarak okumalar için 500 ms ve yazmalar için 5 saniye. Bir istek son tarihine ulaştığında, kuyruğun başına atlar.

Okuma işlemleri genellikle uygulamayı engellerken, yazma işlemleri eşzamansız olarak işlendiğinden, okuma işlemleri yazma işlemlerine göre önceliklidir. Yazma işlemlerinin tamamen durmasını önlemek için, zamanlayıcı belirli sayıda okuma işleminden sonra gecikmiş yazma işlemlerini toplu olarak işler. Sonuç olarak tutarlı bir düşük gecikme süresi elde edilir; bu da onu veritabanı sunucuları ve okuma ile yazma işlemlerini bir arada içeren tüm iş yükleri için çok uygun hale getirir.

yok

Zamanlayıcı none zamanlayıcı neredeyse hiçbir şey yapmaz. İstekleri, yeniden sıralama, birleştirme veya önceliklendirme yapmadan, İlk Giren İlk Çıkar (FIFO) sırasına göre doğrudan cihaza iletir. Bu, kendi dahili kuyruklarını yöneten ve aynı anda on binlerce işlenmekte olan isteği takip edebilen modern NVMe sürücülerine uygundur. Yazılım zamanlama katmanının kaldırılması, uygulamadan cihaza mümkün olan en kısa yolu sağlar; bu da tam olarak yüksek verimli NVMe iş yüklerinin istediği şeydir.

Bunun tek dezavantajı, donanımın kendi başına akıllı bir şekilde zamanlama yapabildiği durumlarda işe yaramasıdır. Kuyrukları sığ olan HDD'lerde veya SATA SSD'lerde, yazılımın yeniden sıralama işlemini atlamak genellikle performansı iyileştirmez, aksine kötüleştirir.

BFQ

BFQ (Budget Fair Queuing), adaleti ön planda tutar. Zaman dilimleri yerine, her işleme disk sektörleri cinsinden ölçülen bir bütçe verir. Büyük sıralı okuyucular, verimi yüksek tutmak için daha büyük bütçeler alırken, gecikmeye duyarlı görevler hızlı bir şekilde hizmet alabilmeleri için daha küçük bütçeler alır ve bir geri bildirim döngüsü, çalışma sırasında bütçeleri ayarlar.

BFQ, yoğun yük altında bile etkileşimli görevlerin yanıt verebilirliğini korur; böylece arka planda büyük bir dosya aktarımı çalışırken video oynatma veya veritabanı sorgusu sorunsuz devam eder. Bu adalet, CPU'ya mal olur. İstek başına ek yükü yaklaşık 1,9 mikrosaniyedir; bu, mq-deadline'ın yaklaşık üç katıdır ve daha yavaş bir ARM çekirdeğinde bu ek yük, aynı zamanlayıcının hızlı bir x86 yongasında ulaştığı verimin çok altında kalır. Ham verim ve CPU verimliliğinin en önemli olduğu sunucularda, bu ödünleşmeyi haklı çıkarmak zordur.

İş yükünüze uygun bir zamanlayıcı seçme

Doğru zamanlayıcıyı belirleyen iki faktör vardır: depolama donanımınız ve uygulamanızın erişim modeli. Donanımdan başlayalım. Cihaz, yetenekli bir ürün yazılımına sahip NVMe sürücü gibi istekleri zaten yeniden sıralıyorsa, yazılım zamanlaması sadece ek yük getirir, bu nedenle none kazanır. Arama süresinin baskın olduğu dönen HDD'lerde, yazılımla yeniden sıralama gecikmeyi azaltır, bu nedenle mq-deadline veya bfq daha iyi seçimlerdir. SATA SSD'ler ikisinin arasında yer alır: HDD'lerden daha hızlıdır ancak NVMe'nin derin kuyrukları yoktur; bu durumda mq-deadline uygun olur.

Aynı mantık, başka bir şey sizin için zaten zamanlama yapıyorsa da geçerlidir. Virtio-blk üzerindeki konuk sanal makineler, I/O zamanlamasını ana bilgisayara bırakır ve yazma geri dönüşlü önbelleğe sahip donanım RAID denetleyicileri kendi sıralamalarını optimize eder. Her iki durumda da none , iş için iki kez ödeme yapmaktan kaçınır.

Erişim modeli ikinci faktördür. Saniyede binlerce rastgele 4K okuma işlemi yapan bir veritabanının, NVMe dizisinden büyük sıralı blokları aktaran bir eğitim işi ile hiçbir ortak yanı yoktur ve her ikisi de farklı zamanlayıcılar gerektirir. Aşağıdaki tablo, yaygın iş yüklerini bir başlangıç noktasına eşler.

Dikkat çekmeye değer bir istisna var. NVMe'de bile, finansal sistemlerde olduğu gibi, p99 veya p999'daki kuyruk gecikmesi sizin için önemli bir metrikse, mq-deadline , sıkı son tarihler uygulayarak ve ara sıra geciken istekleri önleyerek none sıkı son tarihleri uygulayarak ve ara sıra geciken istekleri önleyerek

Zamanlayıcı parametrelerini değiştirme ve ayarlama

Hem zamanlayıcıların değiştirilmesi hem de parametrelerinin ayarlanması sysfs aracılığıyla gerçekleşir ve değişikliği test etmek için yeniden başlatma gerekmez.

Etkin zamanlayıcıyı değiştirme

Bir cihaz için nelerin mevcut olduğunu kontrol edin; parantez içindeki değer aktif olan değerdir:

cat /sys/block/sda/queue/scheduler

Çalışma sırasında farklı bir zamanlayıcıya geçin. Bu değişiklik hemen yürürlüğe girer, ancak yeniden başlatma sonrasında geçerliliğini yitirir:

echo bfq | sudo tee /sys/block/sda/queue/scheduler

Eğer bfq listede yoksa, önce modülü yükleyin:

sudo modprobe bfq

Seçimin kalıcı olması için, RHEL 9 ve benzeri sürümlerde artık zamanlayıcıyı değiştirmeyen eski elevator= çekirdek parametresi yerine bir udev kuralı kullanın; bu parametre RHEL 9 ve benzeri sürümlerde artık zamanlayıcıyı değiştirmiyor. Bu kural, mq-deadline içindeki tüm rotasyonel olmayan SCSI diskleri için /etc/udev/rules.d/60-io-scheduler.rules:

ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"

Yeniden yükleyin ve yeniden başlatmadan uygulayın:

sudo udevadm control --reload-rules && sudo udevadm trigger

RHEL tabanlı sistemlerde, TuneD profilleri, cihaz başına kurallar yerine sistem genelindeki profiller aracılığıyla aynı işi yapar.

Ayarlanmaya değer parametreler

Her zamanlayıcı, ayarlanabilir özelliklerini /sys/block/<device>/queue/iosched/altında ayarlanabilir parametrelerini gösterir. mq-deadlineiçin, son süreler ana etkenlerdir. SATA SSD'lerdeki gecikmeye duyarlı veritabanları, daha kısa sürelerden yararlanır:

echo 100 | sudo tee /sys/block/sda/queue/iosched/read_expire
echo 1000 | sudo tee /sys/block/sda/queue/iosched/write_expire

Yüksek bfq yüksek verimli sistemlerde, gecikme sezgisel yöntemlerini devre dışı bırakmak verimi artırır:

echo 0 | sudo tee /sys/block/sda/queue/iosched/low_latency
echo 0 | sudo tee /sys/block/sda/queue/iosched/slice_idle

Paylaşımlı barındırma için BFQ, cgroups v2 ile iyi bir uyum sağlar. io.weight değerleri atayarak, örneğin bir veritabanı işlemine bir yedekleme işinin on katı kadar I/O payı verebilirsiniz; böylece arka plandaki işler etkileşimli trafiği boğmaz. Neyi değiştirirseniz değiştirin, BFQ'nun istek başına daha yüksek maliyeti CPU'ya bağlı, yüksek IOPS sistemlerinde artar; bu nedenle, uygulamaya geçmeden önce performans testi yapın.

Ayarlamadan sonra performansı doğrulama

Herhangi bir değişiklik yapmadan önce daima bir temel değer kaydetmelisiniz. Aksi takdirde, yapılan ayarlamanın işe yarayıp yaramadığını anlamanız mümkün olmaz.

fio, bunun için standart bir araçtır. Blok boyutu, kuyruk derinliği ve I/O motoru ayarları aracılığıyla belirli iş yükü modellerini yeniden üretir. Her zaman --direct=1 seçeneğini kullanın, böylece sayfa önbelleğini atlayarak önbelleğe alınmış okumalar yerine zamanlayıcıyı ve cihazı doğrudan ölçer. Testi gerçek iş yüküne uyarlayın:

Aynı testi iodepth 1 ile 256 arasındaki değerler için aynı testi çalıştırarak cihazın doygunluk noktasını, yani IOPS'nin artmayı bıraktığı ve gecikmenin aniden yükseldiği seviyeyi bulun. Bir değişiklikten sonra canlı izleme için iostat -x 1 önemli metrikleri raporlayın: r_await ve w_await okuma ve yazma tamamlanma gecikmesi için, aqu-sz ortalama kuyruk derinliği için ve %util cihaz kullanımı için. %util değer 100 yüzdeye yakınsa, sınır donanımdır ve hiçbir zamanlayıcı değişikliği yardımcı olmaz.

Yazılım maliyetini donanım maliyetinden ayırmak için, btt ile blktrace'i çalıştırın. Bu, gecikmeyi Q2D (yazılım kuyruğunda harcanan süre) ve D2C (cihazın isteği yerine getirmesi için harcadığı süre) olarak ayırır. Q2D baskınsa, zamanlayıcı darboğazınızdır. D2C baskınsa, donanımdır.

Sonuçları okurken akılda tutulması gereken bir nokta: zamanlayıcı seçimi çoğunlukla gecikme dağılımının ortancasını değil, kuyruğunu şekillendirir. none NVMe mq-deadline 'ye geçmek, medyan gecikmeyi birkaç mikrosaniye artırabilirken, p99 ve p999 gecikmesini yarı yarıya azaltabilir. SLA'larla sınırlı kullanıcı odaklı hizmetler için bu ödün verme neredeyse her zaman değerlidir; bu nedenle, ortalama verim değil, kuyruk gecikmesini ölçmek bu çalışmanın amacıdır.

Doğru zamanlayıcıyı seçmek

Zamanlayıcı ayarlaması, algoritmayı donanıma ve erişim modeline uydurmak, ardından bunu ölçümlerle kanıtlamaktır. Kısaca:

• NVMe: kullanın none kullanın ve kuyruk oluşturma işini donanım yazılımına bırakın.
• Karışık I/O'lu SATA SSD'ler ve HDD'ler: mq-deadline kullanın.
• Paylaşımlı veya çoklu kiracılı ana bilgisayarlar: bfq kullanın, böylece bir iş yükünün diğerlerini engellemesini önleyin.
• Ortalama gecikme süresini değil, kuyruk gecikme süresini ölçün: zamanlayıcı değişiklikleri p99 ve p999'da görünür, bu yüzden ölçülmesi gereken budur.
• Kalıcı hale getirin: udev kuralları veya TuneD kullanın, asla dead elevator= parametresini asla kullanmayın.

Herhangi bir zamanlayıcıdan en iyi şekilde yararlanmak, buna ayak uydurabilecek donanımla başlar. Yüksek verimli, düşük gecikmeli iş yükleri için tasarlanmış NVMe destekli sunuculara ihtiyacınız varsa, FDC'nin VPS seçeneklerini inceleyin.