Bir Linux G / Ç Zamanlayıcısının Seçilmesi

/ Sys / block / [disk] / queue / scheduler'a yazarak çalışan bir çekirdekteki belirli bir aygıt için G / Ç zamanlayıcısını değiştirmenin sözde mümkün olduğunu okudum. Örneğin sistemimde görebiliyorum:

anon@anon:~$ cat /sys/block/sda/queue/scheduler 
noop anticipatory deadline [cfq] 

varsayılan, tamamen adil kuyruk planlayıcısıdır. Merak ettiğim, özel çekirdeğime dört zamanlayıcıyı da dahil etmenin herhangi bir faydası olup olmadığı. Çekirdek, doğru donanım için doğru zamanlayıcıyı, özellikle de flash tabanlı sürücüler için 'noop' zamanlayıcıyı ve geleneksel bir sabit sürücü.

Durum bu mu?

Belgede belirtildiği gibi /usr/src/linux/Documentation/block/switching-sched.txt, herhangi bir belirli blok cihazındaki G / Ç zamanlayıcı çalışma zamanında değiştirilebilir. Yeni programlayıcı kullanıma sokulmadan önce önceki programlayıcının isteklerinin tümü temizlendiğinden bir miktar gecikme olabilir, ancak cihaz yoğun kullanımda olsa bile sorunsuz değiştirilebilir.

# cat /sys/block/hda/queue/scheduler
noop deadline [cfq]
# echo anticipatory > /sys/block/hda/queue/scheduler
# cat /sys/block/hda/queue/scheduler
noop [deadline] cfq

İdeal olarak, tüm ihtiyaçları karşılayacak tek bir programlayıcı olacaktır. Henüz var görünmüyor. Çekirdek genellikle iş yükünüz için en iyi zamanlayıcıyı seçmek için yeterli bilgiye sahip değildir:

• noop genellikle bellek destekli blok aygıtları (örneğin ramdiskler) ve G / Ç'yi yeniden planlamaya çalışmanın kaynak israfı olduğu diğer dönel olmayan ortamlar (flash) için en iyi seçimdir
• deadline gecikmeye kesin bir sınır koymaya çalışan hafif bir zamanlayıcıdır
• cfq I / O bant genişliğinin sistem genelinde adil olmasını sağlamaya çalışır

Varsayılan anticipatoryuzun bir süre içindi ve çok fazla ayar aldı, ancak 2.6.33'te (2010'un başlarında) kaldırıldı . cfqPerformansı makul olduğundan ve adalet çok kullanıcılı sistemler (ve hatta tek kullanıcılı masaüstü bilgisayarlar) için iyi bir hedef olduğundan, bir süre önce varsayılan haline geldi. Bazı senaryolar için - veritabanları genellikle kendi özel zamanlama ve erişim modellerine sahip olma eğiliminde olduklarından ve genellikle en önemli hizmet olduklarından (adalet kimin umurunda?) - anticipatoryayarlanabilir olma konusunda uzun bir geçmişe sahiptir. Bu iş yüklerinde en iyi performans için ve deadlinetüm istekleri çok hızlı bir şekilde temeldeki cihaza aktarır.

Sistemin zamanlayıcıya hw'nin bazı özelliklerine göre karar vermesine izin vermek için bir udev kuralı kullanmak mümkündür.
SSD'ler ve diğer rotasyonel olmayan sürücüler için örnek bir udev kuralı şöyle görünebilir:

# set noop scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"

yeni bir udev kuralları dosyasında (örneğin, /etc/udev/rules.d/60-ssd-scheduler.rules). Bu cevap debian wiki'ye dayanmaktadır

SD disklerin kuralı kullanıp kullanmayacağını kontrol etmek için tetikleyici özelliğini önceden kontrol etmek mümkündür:

for f in /sys/block/sd?/queue/rotational; do printf "$f "; cat $f; done

Çekirdeğin farklı olanları desteklemesinin amacı, onları yeniden başlatmadan deneyebilmenizdir; daha sonra sistem aracılığıyla test iş yüklerini çalıştırabilir, performansı ölçebilir ve ardından bunu uygulamanız için standart hale getirebilirsiniz.

Modern sunucu sınıfı donanımda, sadece noop olanı hiç kullanışlı görünmüyor. Diğerleri testlerimde daha yavaş görünüyor.

Çekirdeğin cmdline'ına "asansör" parametresini ekleyerek bunu önyükleme sırasında ayarlayabilirsiniz (grub.cfg gibi)

Misal:

elevator=deadline

Bu, "son tarihi" tüm blok aygıtları için varsayılan G / Ç zamanlayıcısı yapacaktır.

Sistem başlatıldıktan sonra zamanlayıcıyı sorgulamak veya değiştirmek isterseniz veya belirli bir blok cihazı için farklı bir zamanlayıcı kullanmak isterseniz, bunu kolaylaştırmak için ioschedset aracını kurmanızı ve kullanmanızı öneririm .

https://github.com/kata198/ioschedset

Archlinux'taysanız, aur'da mevcuttur:

https://aur.archlinux.org/packages/ioschedset

Bazı örnek kullanım:

# Get i/o scheduler for all block devices
[username@hostname ~]$ io-get-sched
sda:    bfq
sr0:    bfq

# Query available I/O schedulers
[username@hostname ~]$ io-set-sched --list
mq-deadline kyber bfq none

# Set sda to use "kyber"
[username@hostname ~]$ io-set-sched kyber /dev/sda
Must be root to set IO Scheduler. Rerunning under sudo...

[sudo] password for username:
+ Successfully set sda to 'kyber'!

# Get i/o scheduler for all block devices to assert change
[username@hostname ~]$ io-get-sched
sda:    kyber
sr0:    bfq

# Set all block devices to use 'deadline' i/o scheduler
[username@hostname ~]$ io-set-sched deadline
Must be root to set IO Scheduler. Rerunning under sudo...

+ Successfully set sda to 'deadline'!
+ Successfully set sr0 to 'deadline'!

# Get the current block scheduler just for sda
[username@hostname ~]$ io-get-sched sda
sda:    mq-deadline

Kullanım kendinden açıklamalı olmalıdır. Araçlar bağımsızdır ve yalnızca bash gerektirir.

Bu yardımcı olur umarım!

DÜZENLEME: Sorumluluk reddi, bunlar yazdığım senaryolar.

Linux Çekirdeği, çalışma zamanında G / Ç Zamanlayıcısını otomatik olarak değiştirmez. Bununla demek istediğim, Linux çekirdeği, bugün itibariyle, ikincil depolama aygıtının türüne bağlı olarak otomatik olarak "en uygun" bir zamanlayıcı seçemiyor. Başlatma sırasında veya çalışma zamanı sırasında, IO planlayıcısını manuel olarak değiştirmek mümkündür .

Varsayılan zamanlayıcı, başlangıçta /linux-2.6 /block/Kconfig.iosched adresinde bulunan dosyanın içeriğine göre seçilir . Bununla birlikte, echo/ sys / block / [DEV] / queue / scheduler konumunda bulunan dosyaya geçerli bir programlayıcı adı ekleyerek çalışma zamanı sırasında IO zamanlayıcısını değiştirmek mümkündür . Örneğin,echo deadline > /sys/block/hda/queue/scheduler