/ sys/block/[disk]/queue/schedulerに書き込むことで、実行中のカーネル上の特定のデバイスのI/Oスケジューラーを変更できると思われます。たとえば、私は自分のシステムで見ることができます:
anon@anon:~$ cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]
デフォルトは完全に公平なキューイングスケジューラです。私が思っているのは、カスタムカーネルに4つすべてのスケジューラを含めることに用途があるかどうかです。カーネルが適切なハードウェア用の適切なスケジューラー、特にフラッシュベースのドライブ用の「noop」スケジューラー、および従来のハードドライブ。
これは事実ですか?
/usr/src/linux/Documentation/block/switching-sched.txt
に記載されているように、特定のブロックデバイスのI/Oスケジューラーは実行時に変更できます。新しいスケジューラを使用する前に以前のスケジューラの要求がすべてフラッシュされるため、ある程度の遅延が発生する可能性がありますが、デバイスが頻繁に使用されている場合でも問題なく変更できます。
# 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
理想的には、すべてのニーズを満たす単一のスケジューラーが存在することになります。まだ存在していないようです。多くの場合、カーネルには、ワークロードに最適なスケジューラを選択するための十分な知識がありません。
noop
は多くの場合、I/Oを再スケジュールしようとするとリソースが浪費されるメモリバックアップブロックデバイス(RAMディスクなど)およびその他の非回転メディア(フラッシュ)に最適です。deadline
は、待ち時間に厳しい制限を設定しようとする軽量のスケジューラーです。cfq
は、システム全体のI/O帯域幅の公平性を維持しようとしますデフォルトは長い間anticipatory
であり、多くのチューニングを受け取りましたが、2.6.33(2010年初期)で削除されました。 cfq
は少し前にデフォルトになりました。そのパフォーマンスは妥当であり、マルチユーザーシステム(およびシングルユーザーデスクトップでも)にとって公平性が良い目標であるためです。一部のシナリオでは、データベースは既に例として使用されています。データベースには独自の固有のスケジューリングおよびアクセスパターンが既に存在する傾向があり、多くの場合most重要なサービスです公平性?)-anticipatory
は、これらのワークロードで最高のパフォーマンスを得るために調整可能であるという長い歴史があり、deadline
はすべての要求を基礎となるデバイスに非常に迅速に渡します。
Udevルールを使用して、システムがhwのいくつかの特性に基づいてスケジューラーを決定できるようにすることができます。
SSDおよびその他の非回転ドライブのudevルールの例は次のようになります
# set noop scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"
新しいudevルールファイル内(例:/etc/udev/rules.d/60-ssd-scheduler.rules
)。この答えは debian wiki に基づいています
Ssdディスクがルールを使用するかどうかを確認するために、事前にトリガー属性を確認することができます。
for f in /sys/block/sd?/queue/rotational; do printf "$f "; cat $f; done
カーネルが異なるカーネルをサポートする目的は、再起動せずにそれらを試すことができることです。次に、sytsemを介してテストワークロードを実行し、パフォーマンスを測定し、それをアプリの標準ワークロードにすることができます。
最新のサーバーグレードのハードウェアでは、noopのみがまったく有用であるように見えます。他のテストは私のテストでは遅いようです。
これは、ブート時に「elevator」パラメータをカーネルコマンドラインに追加することで設定できます(grub.cfgなど)。
例:
elevator=deadline
これにより、すべてのブロックデバイスの「期限」がデフォルトのI/Oスケジューラになります。
システムの起動後にスケジューラをクエリまたは変更する場合、または特定のブロックデバイスに対して別のスケジューラを使用する場合は、ツールioschedsetこれを簡単にします。
https://github.com/kata198/ioschedset
Archlinuxを使用している場合は、aurで入手できます。
https://aur.archlinux.org/packages/ioschedset
使用例:
# 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
使い方は一目瞭然です。ツールはスタンドアロンであり、bashのみが必要です。
お役に立てれば!
編集:免責事項、これらは私が書いたスクリプトです。