ここで特に興味深いのは、システムの起動後に行われた設定の変更が、展開前に行われた決定よりもはるかに重要でない領域に入ることです。
下の写真を見てください。
最新のコンピューターが適切に機能するために必要な4つの主要なリソースを示しています。 パフォーマンスチューニングは、アプリケーションプロセス間でこれらのリソースを最適に分散する技術です。 さらに、これらのリソースはすべて無制限ではなく、生産性への影響という点でも同等ではありません。
ストレージサブシステムのパフォーマンスは、使用されているストレージテクノロジーのパフォーマンス（ハードドライブ、SSD、SAN、NAS）に低下します-アクセス速度とスループットは大きく異なります。 また、強力なプロセッサと大量のメモリは、ストレージデバイスが解決されるタスクの要件を満たさない場合、状況を保存しません。
Linuxの専門家としてハードウェアの決定に影響を与えることができる場合は、組織に適切な（または優れた）ストレージプラットフォームがあることを確認してください。 これにより、将来的に多くの問題が解決されます。
次に、入力/出力（I / O）コントロールの助けを借りて何ができるかを見てみましょう。
ストレージデバイスがすべてです
公式には、I / Oコントローラーはblkioと呼ばれますが、気分が良いとBlockyに反応します。 CPUコントローラーと同様に、Blockyには2つの動作モードがあります。
- 相対I / Oボール（シェア）を使用した調整。10〜1000の範囲の値を設定することにより、すべてまたは選択したブロックストレージデバイスのレベルでパフォーマンスを制御できます。デフォルトでは1000選択したユーザーまたはサービス。 CPUの場合のように、なぜ1024ではなく1000なのでしょうか？ いい質問です。 どうやら、これはLinuxのオープンな性質が彼に利益をもたらさない場合です。
- 特定のユーザーまたはサービスの読み取りおよび/または書き込み速度を制限する絶対帯域幅調整。 デフォルトでは、このモードは無効になっています。
以下のスクリーンショットは、systemctlコマンドを使用して調整できるパラメーターを示しています。 ここでは、Tabキーを押してオプションのリストを表示することにより、自動プロンプトの魔法を使用しました。 これはbash-completionと呼ばれ、まだこの機能を使用していない場合は、適切なPRMをインストールします。
相対I / Oボールは、BlockIODeviceWeightパラメーターとBlockIOWeightパラメーターによって制御されます。 これらのコントローラーで遊ぶ前に、これを理解する必要があります。CFQI / Oスケジューラーがストレージデバイスで有効になっている場合にのみ機能します。
I / Oスケジューラとは何ですか？ 遠いところから始めましょう。Linuxカーネルは、コンピューターのすべてのハードウェアコンポーネントが相互に正しく通信することを保証する責任があることを思い出してください。 そして、これらのすべてのコンポーネントは同時に異なるものを必要とするため、順序付けなしではできません。 さて、例えば、どうやって私たちの人生を整理し、仕事、休息、睡眠などのためにそれを構造化するのでしょうか。
ストレージデバイスについて説明する場合、I / Oスケジューラはカーネル内での作業を整理する責任があります。 これは、USBフラッシュドライブやハードドライブから、実際にはSAN内のISCIデバイス上のどこかにあるファイルである仮想ディスクに至るまで、ブロックデバイスのデータフローを制御する方法を定義するプログラムコードです。
また、Linuxで使用できるこれらすべてのデバイスの上に、コンピューターが実行する必要のあるさまざまなタスクがあります。 さらに、実際には、Red Hatで「ユースケース」と呼ばれるものがあります。 そのため、さまざまなシナリオに焦点を当てたさまざまなプランナーがいます。 これらのスケジューラは、noop、deadline、cfqと呼ばれます。 一言で言えば、それらはそれぞれ次のように説明できます。
- Noop-回転部品（フラッシュ、ssdなど）のないブロックストレージデバイスに最適です。
- Deadlineは、遅延の最小化に焦点を当てた軽量スケジューラーです。 デフォルトでは、ほとんどのアプリケーションが読み取りにつまずくため、読み取りよりも書き込みの方が優先されます。
- Cfq-システム全体のレベルでのI / O帯域幅の公平な分散に焦点を当てています。 そして、上で述べたように、これはcgroupの相対I / Oオプションをサポートする唯一のスケジューラです。
スケジューラーの詳細については、Red Hat Enterprise Linux 7パフォーマンスチューニングガイドを参照してください。
プランナーについてのこの議論は何でしたか？ さらに、ほとんどのコンピューターでは、SATAドライブがない場合、cfqはデフォルトでは使用されません。 これを知らなくても、効果なしで青に変わるまでBlockIOWeightを変更できます。 残念ながら、systemdは次のことを通知しません。「申し訳ありませんが、このパラメーターを変更しようとしても無駄です。 デバイスが間違ったスケジューラを使用しているため、これは機能しません。
それでは、この「興味深い」機能についてどのように知ることができますか？ いつものように、以前の投稿で書いたcgroupsのドキュメントから。 これらまたはこれらのレギュレーターを使用する前に、それに慣れることは常に役に立ちます。
ユースケースに渡す
繰り返しになりますが、一般的な言葉から詳細に移ります。Kryakin氏を紹介します。
彼はケータリングに従事しており、注文を追跡するためにアプリケーションサーバーに2つのデータベースを持っています。 Kryakin氏は、ガチョウは水鳥の王座を偽装しているため、鴨料理の注文のデータベースは、ガチョウ料理のベースよりもはるかに重要であると主張しています。
両方のデータベースはサービスとして構成され、ユニットファイルは次のようになります。
実際、それらで呼び出されるスクリプト（duck.shおよびgoose.sh）はデータベースで実際の作業を行うことはなく、ddコマンドループを使用して読み取りと書き込みをシミュレートするだけです。 両方のスクリプトは、仮想ディスク上にある/データベースファイルシステムを使用します。
アヒルとガチョウを実行して、cgroup階層のどこに着くかを見てみましょう。
そして今、ddプロセスのPIDがわかっているので、iotopコマンドを使用して、ストレージサブシステムで何が起こるかを見てみましょう。
さて、12-14 MB / s ...速くありません。 Kryakin氏はデータストレージシステムにあまり投資しなかったようです。 その妥当性についてはすでに質問がありましたが、驚くことはあまりありません。
PID 3301（ガチョウ）とPID 3300（アヒル）の2つのタスクを見てみましょう。 それぞれが約6 MB /秒のI / Oを使用します。 上の画面は少し異なる数字ですが、実際には常にジャンプしており、平均して、これら2つのタスクはストレージデバイスの帯域幅を等しく共有しています。
Kryakin氏は、鴨にガチョウの少なくとも5倍のI / O帯域幅を持たせたいため、鴨の注文が常に最初に処理されます。 次のコマンドを使用して、これにBlockIOWeightパラメーターを使用してみましょう。
iotopを見ると、動作しなかったことがわかります。
device / dev / vdbのI / Oスケジューラを確認しましょう：
興味深い...スケジューラをcfqに変更しようとしていますが、何も機能しません。 なんで？
実際、システムはKVM仮想マシン上で実行され、バージョン7.1以降、Red Hat Enterprise Linuxでスケジューラーを変更することはできません。 これはバグではなく、仮想化されたI / Oデバイスを操作するメカニズムの改善に関連する機能です。
しかし、絶望しないでください。 変更できるパラメータが2つあります。BlockIOReadBandwidthとBlockIOWriteBandwidthはブロックデバイスレベルで動作し、I / Oスケジューラを無視します。 デバイス/ dev / vdbの帯域幅（受信用と出力用に約14 MB / s）を知っているので、グースを2 MB / sに制限することで、Kryakin氏の希望を満たすことができるようです。 試してみましょう：
PID 3426、別名グースは、現在2 MB / s前後のどこかでI / Oを使用しており、PID 3425、つまりアヒルは、ほぼ14個すべてを使用しています！
Hooray、私たちは顧客が望んだことをしました。つまり、一定数のガチョウだけでなく、Linuxの第一人者としての評判も保存しました。