☰

新しいLinux IO「圧力輻輳情報」が100％で表示されないのはなぜですか？

tag-icon • tag-icon linux monitoring io
新しいLinux IO「圧力輻輳情報」が100％で表示されないのはなぜですか？

atop私は（私のFedora 30インストールで）輝く新しいラインがあることを発見しました。

上の男

PSI - 圧力失速情報。

この行には、各カテゴリーの3つのパーセンテージ、つまり過去10秒、60秒、および300秒間の平均圧力の割合（スラッシュで区切られた）が含まれています。カテゴリは、「一部」CPU（cs）、「一部」メモリ（ms）、「フル」メモリ（mf）、「一部」I / O（is）、および「フル」I / O（if）です。

詳しくは、「」をご覧ください。圧力失速情報追跡「[LWN.net, 2018]。

5分10秒間隔で走ってdd if=/dev/zero bs=1M of=test見守りました。最も高いis値はif63％です。その高い値に達するには数回待つ必要があります。

この指標は、「すべてのIO遅延によるCPUの潜在的な損失」になると予想しました。[1]/"タスクはioが完了するのを待っています。"[2]100％同じでしょう...

私の初期の期待は現実ではありませんでした。atop私の著者は、dd既存のプロセスリストでCPUの15〜20％を使用しているからです。しかし、この数字を加えてもまだ100％ではありません:-)。

対照的に、（O_DIRECTなしで）ファイルを読むことは約43％ddに増加しis、CPUの約9％を使用しているようです。それは少なくともそうだここに大きなギャップがあるように:-)。

ddライターを実行すると、oflag=directIO圧力が51％に達し、CPU使用率が6％になります。

ddリーダーを実行すると、iflag=directIO圧力は47％に達し、CPU使用率は3％です。

この明らかな違いをどのように理解していますか？

IOスケジューラはmq-deadline機械式ハードディスクです。私のカーネルはv5.2-rc5-290-g4ae004a9bca83つのext4パッチで構成されていますが、これは重要ではありません。

答え1

この質問に対する私の最初の答えは、「IO圧力」が「CPU IOレイテンシ」の概念と密接に関連していることです。私が見たCPU IOの待ち時間も短すぎるようです。したがって、「IO圧力」が何の意味もないとは限りません。

しかし今は少なくともそれを持っています。CPU iowait時間問題に対する解決策。言い換えれば、iowaitで始まると、nohz=off予想されるiowait時間が与えられます。あるいは、CPUアイドルの代わりにポーリングを強制して同じ効果を得ることもできます。これにより、スケジューラティックが決して止まらないようになります。

cd /sys/devices/system/cpu

# Disable all cpuidle states, including C1 ("halt"), but not POLL
for i in cpu*/cpuidle/state[1-9]*/disable; do echo 1 | sudo tee $i; done

# Reset to default (C-states enabled)
for i in cpu*/cpuidle/state*/disable; do echo 0 | sudo tee $i; done

起動すると、nohz=off「IO圧力」の値も増加するようです。私はまだ新しい価値に自信を持っていません。私が予想したものに近づいたようです...

nohz=offコードを正しく理解しても、iowaitのようにIO圧力を上げることは意味がありません！少なくとも圧力ストール情報の元のパッチは完全にイベントベースのようです。スケジューラに頼ることは見えません！

実行中（最小60秒）、次のatop行が使用されました。dd if=test iflag=direct bs=1M of=/dev/null

CPU |  sys   2% |  user  1% |  irq   1% |  idle    300% |  wait     96% 

cpu |  sys   1% |  user  0% |  irq   0% |  idle     89% |  cpu003 w 10%
cpu |  sys   1% |  user  0% |  irq   0% |  idle     23% |  cpu001 w 76%
cpu |  sys   0% |  user  0% |  irq   0% |  idle     98% |  cpu000 w  1%
cpu |  sys   0% |  user  0% |  irq   0% |  idle     90% |  cpu002 w  9%

CPL |  avg1    0.76 |  avg5    0.92 |  avg15   0.84 |               | numcpu     4

PSI |  cs     0/0/0 |  ms     0/0/0 |  mf     0/0/0 |  is  83/57/44 |  if  83/57/44
  • CPU3のアイドル時間以外の時間（100〜89）は11％です。 10％は「iowait」と計算されます。
  • CPU1はアイドル時間ではなく時間（100〜23）の77％を持ちます。 76％は「iowait」と計算されます。
  • cpu2+cpu0の非アイドル時間は12%です。 10％は「iowait」と計算されます。
  • ms0です。したがって、いくつかの（無視できない）iowait時間を「IO待機停止」ではなく「メモリ競合停止」として計算することは不可能です。 （しかし、これがより一般的かどうかはわかりません）。

psi は各 CPU に関連する作業状態を追跡し、停止状態で費やされた時間をサンプリングします。 2秒ごとに、サンプルはCPU全体で平均を取得し（使用していないCPUからアーティファクトを削除するためにCPUがアイドル状態ではない時間で重みを付けて）、停止時間の割合に変換されます。

-[パッチ08/10] psi：CPU、メモリ、IOの圧力ストール情報

たとえば、CPU1のIO圧力は76/77 = 98.7％（全体）です。これは加重平均で最大の項でなければなりません。それで、まだ報告された価値が予想よりはるかに低いと思います。

上記のテストでは、「全体」値は「部分」値と基本的に同じです。したがって、これらの不思議な違いは、「IO圧力（一部）」にも適用されると予想されます。

重要なのは、加重平均に使用される「非アイドル」時間は純粋なアイドル時間だけを除外することです。したがって、「非アイドル」時間は単なるCPU使用量ではありません。 「非アイドル」時間には「CPU IOレイテンシ」も含まれます。

構造体 psi_group_cpu {
    /* このグループに属するジョブの状態 */
    符号なし整数操作[NR_PSI_TASK_COUNTS];

    /*実行可能ファイルがありますまたはD状態仕事*/
    無料ではありません。

    groupc->nonidle = ジョブ[NR_RUNNING] ||
        ジョブ[NR_IOWAIT] ||ジョブ[NR_MEMSTALL];

注：PSIは実際に報告されたCPU固有の「iowait」を使用しません。自己会計を実行します。繰り返しますが、私のリンクの質問によると、「iowait」が深刻に過小評価されている可能性がありますが、考える「iowait」に対応するPSIは、この問題を回避するように設計されています。

このコマンドを単一のCPUに固定すると、抑制されddた場合はtaskset -c 0IO圧力が96％、そうでない場合は90％になります。NO_IDLE_HZ私にとっては、この数字はもっと信頼できるようです。

関連情報