web-dev-qa-db-ja.com

（cfqスケジューラーを使用するデバイスに対して）ioniceの効果をテストするにはどうすればよいですか？

私はイオニスの効果を測定するための実験を構築しようとしています。私がやりたいのは、（ serverfaultに関する別の回答 ごとに）十分な頻度でI/Oを発生させ、十分に「ニックのかかった」プロセスでI/Oが不足するようにすることです。

serverfaultに関する別の回答 に基づいて、250ミリ秒ごとに一般的なcfqでスケジュールされたデバイスに対して少なくとも1つの実際のI/O操作を発生させる必要があると思います。私の考えは、ループを持っている些細なプログラムを書くことでした。

  • 共通デバイス上の（構成可能な）ファイルに書き込みます。
  • fsync()（明確なI/O操作を強制するため）を実行し、
  • usleep()を使用して、構成可能な時間を遅延させます
  • 定期的にlseek()を使用してファイルを切り捨てます（ファイルシステムがいっぱいにならないようにするため）

次に、共通デバイス上の1つのファイルに対して、ionice -c3（idleスケジューリングクラス）を使用してプログラムの1つのインスタンスを起動します。デフォルトの（best-effort）スケジューリングクラスでさまざまなインスタンスを同時に実行し、共通デバイス上の別のファイルを指定します（遅延値を変更します）。

私の仮説は、「ベストエフォート」プロセスで250ミリ秒以上の遅延値の場合、「アイドル」プロセスによって進捗が見られるというものでした。 250ミリ秒未満の値の場合、「アイドル」プロセスによる進行はほとんどまたはまったく見られません。

私の観察では、2つのプロセスのパフォーマンスに違いはありませんでした。彼らは両方とも同様の進歩を遂げました。念のため（「ベストエフォート」プロセスが250ミリ秒ごとよりもはるかに高速にI/Oを実行していることを示す場合）、「ベストエフォート」プロセスの複数の同時インスタンスを開始し、no（ゼロ）を指定しました。ディレイ。それでも、2つのスケジューリングクラスのプロセス間でパフォーマンスに違いは見られませんでした。

念のため、スケジューラクラスを再確認しました。

$ cat /sys/block/xvda/queue/scheduler
noop anticipatory deadline [cfq]

Cfqスケジューラーがどのように機能するかについて私が見逃しているのは何ですか？

重要な場合、これは2.6.18カーネル上にあります。

linuxstorageperformance-tuningschedulerionice
5
jhfrontz

stress -i nやstress -d nのような負荷ジェネレーターを使用して効果を測定してみます。ここで、「n」はプロセスの数です。 1つのウィンドウで実行します。別のデバイスでnmonまたはiostatを試して、同じブロックデバイスで代表的なアプリケーションプロセスを試してください。さまざまなイオニス設定（またはアプリ内からの応答のテスト）を使用して、iostatでサービス時間がどのように変化するかを確認します。

Cfqに関しては、RHEL5ライフサイクル全体（2.6.18）で変更があったようです。アプリケーションサーバーでは、競合の問題のためにnoopおよびdeadlineエレベータに移動する必要があることが十分にわかりました。

2
ewwhite