ksoftirqdスレッドのタスクスケジューリング待ち時間の問題のトラブルシューティング - Alibaba Cloud Linux

Softirq (ソフトウェア割り込み要求) は、遅延割り込みを処理するLinuxカーネルメカニズムです。これにより、割り込み要求 (IRQ) の重要性の低い部分は、IRQの重要性の高い部分がhardirq (ハード割り込み要求) によって渡された後、softirq処理のために延期される。多数のタスクまたは時間のかかる処理のためにsoftirq負荷が重い場合、カーネルはタスクをsoftirqからCPUごとのksoftirqdスレッドに転送し、スケジューラを使用してksoftirqdスレッドと他のユーザー空間タスクとの間で負荷を分散します。このトピックでは、Alibaba Cloud Linux 3オペレーティングシステムを例として使用して、softirqレイテンシの問題を引き起こすksoftirqdスレッドのタスクスケジューリングレイテンシの問題をトラブルシューティングする方法を説明します。

softirqレイテンシの問題を確認する

bpftraceスクリプトをElastic Compute Service (ECS) インスタンス上の /tmpなどのディレクトリにダウンロードします。
<tmp> をsoftirq_net_latency.btスクリプトが格納されているディレクトリに置き換えます。
```
sudo wget -P <tmp> https://gitee.com/dtcccccc/softirq_net_latency/raw/master/softirq_net_latency.bt
```
bpftraceをインストールします。
```
sudo yum install -y bpftrace
```
次のコマンドを実行してbpftraceを使用し、NET_RXのレイテンシが100ミリ秒を超えるかどうかを確認します。
<tmp> を、softirq_net_latency.btスクリプトが格納されている実際のディレクトリに置き換えます。
```
sudo bpftrace <tmp>/softirq_net_latency.bt 100000
```
レイテンシが100ミリ秒を超えることをコマンド出力が示す場合、softirqレイテンシの問題が発生します。原因はシナリオによって異なります。
- 報告されたプロセス名 (comm) がksoftirqd/$cpuの場合、ksoftirqdスレッドの不適切なスケジューリングによりレイテンシが発生します。
  softirqタスクは、中程度の優先度を有するksoftirqdスレッドに転送されたが、カーネルスケジューリングポリシーは、ksoftirqdタスクを優先的にスケジュールする。これは、スレッドがタスクを処理するために短い時間を必要とし、ほとんどの時間スリープするためである。この場合、スケジューリングレイテンシが依然として大きい場合、より高い優先度を持つリアルタイムタスクが現在のCPUで実行されているかどうか、またはタスクがカーネルで時間を消費しているかどうかなど、可能性のある例外がないかチェックします。これにより、ksoftirqdスレッドのタスクがスケジュールできなくなります。
- Softirqは割り込みコンテキストで実行され、hardirq処理時間は長くなります。これはまれなケースです。この場合は、カーネルとドライバーを確認してください。
  1. トップツールを使用して、対応するCPU上のすべてのタスクに対するhardirqタスクの割合を表示します。割合は高いです。
  2. /proc/interruptsファイルのコンテンツの変更を定期的に監視します。 /proc/interruptファイルは、システムが起動されてからの各CPU上の各タイプの割り込みのトリガーの総数を記述します。統計に基づいて、各CPUでどのタイプの割り込みがより頻繁にトリガーされるかを確認し、対応するドライバーを確認します。

ftraceを設定してシステムログを記録する

softirq_net_latency.btスクリプトが格納されているディレクトリに、softirq_ftrace.patchファイルをダウンロードします。
<tmp> をsoftirq_net_latency.btスクリプトが格納されているディレクトリに置き換えます。
```
sudo wget -P <tmp> https://gitee.com/dtcccccc/softirq_net_latency/raw/master/softirq_ftrace.patch
```

必要なシステム情報を収集するようにftraceを設定します。

sudo sh -c 'echo "irq:softirq_raise irq:softirq_entry sched:sched_switch sched:sched_wakeup raw_syscalls:sys_enter raw_syscalls:sys_exit" > /sys/kernel/debug/tracing/set_event'
sudo sh -c 'echo 1 > /sys/kernel/debug/tracing/tracing_on'

ftraceログ機能を有効にし、長いsoftirqレイテンシに関する情報を取得してから、ftraceログ機能を無効にします。
<tmp> をsoftirq_net_latency.btスクリプトが格納されているディレクトリに置き換えます。
```
cd <tmp>
sudo patch -p1 < <tmp>/softirq_ftrace.patch
sudo bpftrace --unsafe <tmp>/softirq_net_latency.bt 100000
```

例外の診断と分析

この例では、以下のbpftraceログが印刷され、CPU11のksoftirqdスレッドスケジューリング例外を分析するために使用されます。
```
High IRQ-to-softirq latency: 132169 usec (132 ms) on CPU:11 comm:ksoftirqd/11
```
ログに記録されたタイムスタンプ (秒単位) を表示し、softirq_raise時間とsoftirq_entry時間の間隔が長いことを確認します。次に、トレースログファイルを開き、前のタイムスタンプに基づいてスケジューリングイベントを分析します。
ベクトル (vec) は3に設定され、これはネットワークタイプのsoftirqsを示す。
```
sudo su
cd /sys/kernel/debug/tracing/per_cpu/cpu11/
grep "vec=3" ./trace
```

次のチェック项目に注意してください。

ログの左端の内容は、レイテンシの問題が発生したときに実行されていたタスクを示しています。前のタイムスタンプで指定された期間内に実行されていたタスクを表示します。 chrt -p $pidコマンドを実行して、タスクのスケジューリングポリシーを表示します。 SCHED_DEADLINE、SCHED_FIFO、またはSCHED_RRスケジューリングポリシーがタスクに適用されている場合、そのタスクは、ksoftirqdタスクを含む一般的なタスクよりも優先度が高くなります。この場合、ksoftirqdタスクは一時停止され、スケジュールできません。
他のスケジューリングポリシーがタスクに適用される場合、タスクは共通の優先順位であり、共通のプロセスに属する。共通タスクは、長期間にわたってカーネル内でスタックされ得る。たとえば、ログは、現在のプロセスが長期間タスクの処理を継続し、その期間中にプロセスのスケジューリングが行われないことを示しています。さらに、タスクのsyscall_enter時間とsyscall_exit時間の間隔は長く、スケジューリングが行われない期間に及びます。この場合、原因を分析するには、タスクのアクションとsyscall関数と組み合わせて詳細な分析を実行します。
トレース・ログ・ファイルが、SCHED_OTHERまたはSCHED_NORMALスケジューリング・ポリシーが現在のプロセスに適用されたこと、システム・コールがめったに行われないか、またはすぐに終了したこと、またはカーネルがタスクを共通プロセスにスケジュールしたことを示す場合、例外がカーネル・スケジューラに存在する可能性があります。問題をさらにトラブルシューティングするには、お問い合わせ、上記の情報を提供してください。