it-swarm-ja.com

Linux I / Oスケジューラーの選択

/ sys/block/[disk]/queue/schedulerに書き込むことで、実行中のカーネル上の特定のデバイスのI/Oスケジューラーを変更できると思われます。たとえば、私は自分のシステムで見ることができます:

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

デフォルトは完全に公平なキューイングスケジューラです。私が思っているのは、カスタムカーネルに4つすべてのスケジューラを含めることに用途があるかどうかです。カーネルが適切なハードウェア用の適切なスケジューラー、特にフラッシュベースのドライブ用の「noop」スケジューラー、および従来のハードドライブ。

これは事実ですか?

81

/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はすべての要求を基礎となるデバイスに非常に迅速に渡します。

109
ephemient

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
19
Dani_l

カーネルが異なるカーネルをサポートする目的は、再起動せずにそれらを試すことができることです。次に、sytsemを介してテストワークロードを実行し、パフォーマンスを測定し、それをアプリの標準ワークロードにすることができます。

最新のサーバーグレードのハードウェアでは、noopのみがまったく有用であるように見えます。他のテストは私のテストでは遅いようです。

7
MarkR

これは、ブート時に「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
[[email protected] ~]$ io-get-sched
sda:    bfq
sr0:    bfq

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

# Set sda to use "kyber"
[[email protected] ~]$ 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
[[email protected] ~]$ io-get-sched
sda:    kyber
sr0:    bfq

# Set all block devices to use 'deadline' i/o scheduler
[[email protected] ~]$ 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
[[email protected] ~]$ io-get-sched sda
sda:    mq-deadline

使い方は一目瞭然です。ツールはスタンドアロンであり、bashのみが必要です。

お役に立てれば!

編集:免責事項、これらは私が書いたスクリプトです。

0
Tim Savannah