Linux

Linuxシステムの操作をしているとき、時々ユーザモードプロセスのデッドループに遭遇する、すなわちシステムが遅い、プロセスがハングする、など。問題を解決するには？次の小シリーズでは、次のユーザー状態プロセスの無限ループについて説明します。

1、問題の現象

ビジネス・プロセス（ユーザ・モード、マルチスレッド・プログラム）の死にリンクされ、OS無応答、システムも例外ではありませんログインします。カーネルモードプロセスからスタックを参照、次のようにすべてのスレッドがカーネルモードスタックプロセスで立ち往生しているようだ：

[ルート@ vmc116〜]＃猫の/proc /27007 /タスク/11825 /スタック

"ffffffff8100baf6"] retint_careful + 0x14の/0x32の

"ffffffffffffffff"] 0xffffffffffffffff

2、問題分析

1）解析カーネルスタック

entry_64.S

コードを次のように：

カーネルスタック見てから、すべてのプロセスがretint_carefulにブロックされ、これは次のようにプロセス割り込みリターンフロー、（コンパイル）コードがあります< BR>

ret_from_intr：

DISABLE_INTERRUPTS（CLBR_NONE）

TRACE_IRQS_OFF

PER_CPU_VAR（irq_count）
/* * /<保存された前回のスタックを復元します。 BR>

popq％

CFI_DEF_CFAのRSI、SS + 8-RBPは、/* REG /オフリセットdef_cfa_expr * /

leaq ARGOFFSET-RBP（％のRSI）の後、％RSP

CFI_DEF_CFA_REGISTER rsp

CFI_ADJUST_CFA_OFFSET RBP-ARGOFFSET < Ｂｒ＞ ＜ｐ＞。 。 。

retint_careful：

CFI_RESTORE_STATE

$ TIF_NEED_RESCHED BT、％EDX

JNC retint_signal

TRACE_IRQS_ON

ENABLE_INTERRUPTS（ CLBR_NONE）

pushq_cfi％RDI

SCHEDULE_USER

popq_cfi％RDI

GET_THREAD_INFO（％RCX）

DISABLE_INTERRUPTS（CLBR_NONE）

TRACE_IRQS_OFF

JMP retint_check

これは、ユーザモード分解、合成retint_careful + 0x14の/0x32のからの割り込みリターン流を遮断した後、ユーザ・モード・プロセスが中断され、実際に

SCHEDULE_USER

（）はスケジュールするには、この実際に呼び出しているスケジュールは、そのプロセスがリターンが来る中断する場合、スケジュールする必要性を見つけると言うことです（
で、実際にはブロッキングポイントを確認することができます。 TIF_NEED_RESCHEDが設定されているので、ここでスケジューリングが行われます。

質問があります。なぜ、スタックにschedule（）のスタックフレームが表示されないのですか。

これはアセンブリによって直接呼び出されるため、関連するスタックフレームプッシュおよびコンテキスト保存操作はありません。

2）ステータス情報の分析

topコマンドの結果から、関連するスレッドは実際にはR状態にあり、CPUはほぼ完全に使い果たされており、そのほとんどはユーザーモードで消費されています。

[ルート@ vmc116〜]＃トップ

トップ - 9時42分23秒までの16日間、午前2時21分、23人のユーザー、負荷平均：84.08、84.30、83.62

タスク：1037総計、85ランニング、952睡眠、0停止、0ゾンビ

CPU（S）：97.6％で米国、2.2％のSY、0.2％NI、0.0％IDを、0.0％のWA、0.0％のHI 0.0％のSi、0.0％ST

Memの：32878852k合計、32315464k使用、563388k無料、374152kバッファは

スワップ：35110904k合計、使用38644k、35072260k無料、28852536kキャッシュさ

PIDユーザPR NI VIRT RES SHR S％のCPU％MEM TIME + COMMAND

27074ルート20 0 5316メートルと163メートルと14メートルのR 10.2 0.5 321：06.17 z_itask_templat

27084ルート20 0 5316メートル163メートル14メートルR 10.2 0.5 296：23.37 z_itask_templat

27085ルート20 0 5316m 163m 14m R 10.2 0.5 337：57.26 z_itask _templat

27095ルート20 0 5316メートル163メートルと14メートルのR 10.2 0.5 327：31.93 z_itask_templat

27102ルート20 0 5316メートル163メートルと14メートルのR 10.2 0.5 306：49.44 z_itask_templat

27113ルート20 0 5316メートル163メートル14メートルR 10.2 0.5 310：47.41 z_itask_templat

25730ルート20 0 5316メートルと163メートルと14メートルのR 10.2 0.5 283：03.37 z_itask_templat

30069ルート20 0 5316メートルと163メートルと14メートルのR 10.2 0.5 283：49.67 z_itask_templat

13938ルート20 0 5316メートル163メートルと14メートルのR 10.2 0.5 261：24.46 z_itask_templat

16326ルート20 0 5316メートル163メートルと14メートルのR 10.2 0.5 150：24.53 z_itask_templat

6795ルート20 0 5316メートル163メートル14メートルR 10.2 0.5 100：26.77 z_itask_templat

27063ルート20 0 5316メートルと163メートルと14メートルのR 9.9 0.5 337：18.77 z_itask_templat

27065ルート20 0 5316メートルと163メートルと14メートルのR 9.9 0.5 314：24.17 z_itask_templat

27068ルート20 0 5316メートル163メートルと14メートルのR 9.9 0.5 336：32.78 z_itask_templat

27069ルート20 0 5316メートル163メートルと14メートルのR 9.9 0.5 338：55.08 z_itask_templat

27072ルート20 0 5316メートルと163メートルと14メートルのR 9.9 0.5 306：46.0​​8 z_itask_templat

27075ルート20 0 5316メートルと163メートルと14メートルのR 9.9 0.5 316：49.51 z_itask_templat

。 。 。

3）プロセスのスケジューリング情報は、時計からスケジューリング情報を

関連スレッドを
：

[ルート@ vmc116〜]＃猫の/proc /27007 /タスク/11825 /schedstat < BR>

15681811525768 129628804592612 3557465

[ルート@ vmc116〜]＃猫の/proc /27007 /タスク/11825 /schedstat

15682016493013 129630684625241 3557509

[ルート@ vmc116〜]＃猫の/proc /27007 /タスク/11825 /schedstat

15682843570331 129638127548315 3557686

[ルート@のvmc116〜]＃猫の/proc /27007 /タスク/11825 /schedstat

15683323640217 129642447477861 3557793

[ルート@ vmc116〜]＃猫の/proc /27007 /タスク/11825 /schedstat

15683698477621 129645817640726 3557875

が見つかり関連するスレッドスケジューリング統計は増加しており、関連するスレッドが実行するようにスケジュールされ、その状態は常にRであることを示しています。ユーザー状態に無限ループ（または非スリープデッドロック）があると考えられます。

ここに別の問題があります。無限ループ処理によって100％の占有率が通常発生するのではなく、各スレッドのCPU使用率が上から約10％になるのはなぜですか。

CFSスケジューリングアルゴリズムによれば、スレッドの数と優先順位が同じであるため、タイムスライスは均等に分散され、スレッドの1つがCPUを独占することは許可されません。その結果、複数のスレッド間でラウンドロビンスケジューリングが行われ、すべてのCPUが消費されます。 。

もう1つの質問：この場合、カーネルがソフトロックを検出しないのはなぜですか？

ビジネスプロセスの優先度は高くないため、ウォッチドッグカーネルスレッド（最高優先度のリアルタイムスレッド）のスケジューリングには影響しません。そのため、ソフトロックアップは生成されません。

もう1つの質問：スレッドスタックを見るたびにretint_carefulをブロックするのはなぜですか。

これは（割り込みが戻ったとき）スケジューリングのタイミングなので、（他の状況にかかわらず〜）他の時点ではスケジューリングは実行できず、スレッドスタックの動作を調べて、プロセススケジューリングにも依存する必要があります。したがって、スタックを見るたびに、スタックプロセス（catコマンド）がディスパッチされるのを見る時間です。この時間は割り込みが戻る時間なので、今見たブロッキングポイントはretint_carefulです。

4）ユーザー状態分析

上記の分析から、ユーザー状態にデッドロックがあると想定されます。

ユーザーモードの確認方法：

デバッグ情報を展開してから、関連プロセスをgdbアタッチし、スタックを確認し、コードロジック分析を組み合わせます。

問題によってユーザー状態プロセスに無限ループが発生したことの最終確認。

以上がLinuxシステムの次のユーザ状態処理無限ループの処理方法ですまず問題の原因を分析し、その理由に応じて対処してください。