Linux 4.1カーネルのホットパッチ実装に成功

当初、同社の運用および保守担当者は、一部のホスト マシン上のプロセスの CPU 使用率が異常に高いと報告しました。しかし、数万台のマシンの中で発生したケースはわずか数件であり、確率は 1 万分の 1 程度であることを意味します。監視における小さなエラーは、ダウンタイムなどの重大な結果を引き起こすことはなく、簡単に見落とされる可能性があります。

しかし、この異常は一時的なものであり、検出が容易ではないことを考慮すると、このようなマシンがさらに存在する可能性があり、または現在は正常であっても将来的に異常になる可能性もあります。カーネル開発者の本能的な好奇心から、この問題には何か怪しいところがあるに違いないと感じます。そこで私たちは調査を続けました。

現象1: CPUモニタリングが0または100%になる

問題となる現象は、Redis プロセスの CPU 監視のピーク値が 100% になることもあれば 0 になることもあります。場合によっては、数十分間 0 になることもあります。次の図に示すように、突然 1 秒間 100% に達し、その後 0 に変わります。

多数のマシンの統計法則から判断すると、この現象は 2.6.32 カーネルでは発生しませんが、4.1 カーネルでは少数のケースで発生します。 2.6.32 は、プラットフォームの安定した開発を強力にサポートする、以前に採用したバージョンです。 4.1 は、新しい CPU、新しいボード、RDMA、NVMe、binlog2.0 など、多くの新しい技術要件を満たすことができます。 2 つのバージョンはバックグラウンドでシームレスに維持され、機能の向上と最適化のために徐々にバージョン 4.1 以上に移行しています。

現象2: 上部に0または300%が表示される

マシンにログインし、top -b -d 1 –p <pid> | を実行します。 grep <pid> 。プロセスの CPU 使用率が数分から数十分ごとに 300% に達していることがわかります。これは、プロセスの 3 つのスレッドによって占有されている 3 つの CPU がフルに使用されていることを意味し、監視プログラムと同じ異常を示しています。

上記の異常なプログラムは、同じデータ ソース (/proc/pid/stat 内のプロセスによって占有されるユーザー時間 utime とカーネル時間 stime) を使用します。 utime と stime の更新ステータスをキャプチャした結果、utime または stime は数分または数十分ごとに更新され、ステップ値は数百から 1000 以上に達していることがわかりました。一方、通常のプロセスは数秒ごとに更新され、ステップ値は数十です。

異常箇所を特定したら、その原因を突き止める必要があります。監視ロジック、IO 負荷、呼び出しボトルネックなどの可能性を排除した結果、4.1 カーネルの CPU 時間統計にバグがあることが確認されました。

CPU時間統計ロジック

/proc/pid/stat で utime と stime が更新されるコード実行パスを確認すると、cputime_adjust() に疑わしい場所が見つかりました。

utime+stime>=rtime の場合、直接ジャンプします。つまり、utime と stime は更新されません。ここでの rtime は実行時間であり、プロセスが占有する合計 CPU 時間を表します。通常、これはプロセス ユーザー状態時間 + カーネル状態時間と等しいか、近似値になります。しかし、カーネルは CONFIG_VIRT_CPU_ACCOUNTING_GEN オプションで構成されているため、utime と stime は単調に増加します。実行時間は、スケジューラでカウントされるプロセスの合計実行時間です。

カーネルは /proc/pid/stat の utime と stime を更新するたびに、それらを rtime と比較します。 utime+stime が長時間 rtime より大きい場合、コードは直接終了し、/proc/pid/stat は更新されません。 rtime が更新を続け、utime+stime に追いついた場合にのみ、utime と stime が更新されます。

*** ラウンド: コールドパッチ

問題のあるコードの場所が見つかったので、カーネル コミュニティにアクセスして、利用可能な成熟したパッチがあるかどうかを確認しましょう。 kernel/sched/cputime.c の変更ログを確認し、パッチを確認してください: stime+utime=rtime であることを確認してください。説明をもう一度見てください。top などのツールでは、使用率が 100% を超えて表示されますが、その後、一定期間は 0 になります。これが私たちが直面している問題ではないでしょうか?長い間探し続けた後、ついに何の苦労もなく見つけることができるというのは本当です！ (パッチリンク: https://lore.kernel.org/patchwork/patch/609410/ )

このパッチは 4.3 カーネル以降のバージョンで送信されましたが、4.1 安定バージョン ブランチには送信されなかったため、4.1 カーネルに移植されました。パッチを適用した後、ストレス テストでは、CPU 時間が 100% または 0% ではなく、0 ～ 100% の間でスムーズに変動していることが示されました。

この時点で、問題は解決したと思うかもしれません。しかし、問題は半分しか解決されていません。多くの場合、重要なポイントは「しかし」の後に来ます。

第2ラウンド: ホットパッチ

このコールドパッチをカーネルコードに適用すると、新しく追加されたサーバーの問題を解決することしかできませんが、同社にはカーネルのアップグレード後に再起動できない既存のサーバーがまだ何万台も残っています。

他に適切な選択肢がない場合、ストック更新では次の妥協案を採用せざるを得なくなります。監視プログラムは統計的手法を変更してこれを回避し、utime と stime を使用せず、runtime を使用してプロセスの実行時間をカウントします。

このソリューションは高速かつ実行可能ですが、大きな欠点もあります。

1. 多くのビジネス部門が統計手順を変更する必要があり、その結果研究開発コストが高くなります。

2. /proc/pid/stat の utime と stime は標準的な統計方法であり、一部のサードパーティコンポーネントは変更が容易ではありません。

3. 不正確な utime と stime の問題は根本的に解決されていません。 ps コマンドや top コマンドを使用する場合、ユーザー、研究開発、運用保守は依然として混乱し、コミュニケーションと調整のコストがさらに発生します。

幸いなことに、UCloud が何度も成功裏に適用してきた技術、ホット パッチ技術にも頼ることができます。

いわゆるホットパッチ技術とは、欠陥のあるサーバーカーネルまたはプロセスの実行中にメモリにロードされたプログラムバイナリにパッチを適用し、プログラムが新しい正しいロジックをオンラインでリアルタイムに実行できるようにすることです。それは、関二業と同じように、意識のある状態で麻酔なしで骨を削ったり傷を治したりする行為として簡単に理解することができます。もちろん、骨を削って治すときに内核は痛みを感じませんが、うまく削らないと、内核はためらうことなく、非常に早く、簡単に、目の前で死んでしまいます。

このホットパッチ修復には 2 つの困難があります。

難しさ1: ホットパッチの生産

このホット パッチは、スピンロック メンバー変数を構造体に追加します。これには、メモリの割り当てと新しいメンバーの解放が含まれます。構造体インスタンスをコピーして解放すると、新しいメンバーを追加で処理する必要があります。省略するとメモリ リークが発生してクラッシュにつながる可能性があり、リスクが増大します。

もう 1 つは、プロセスの開始時に構造体インスタンスが初期化されることです。新しいスピンロック メンバーを既存のインスタンスに挿入するにはどうすればよいですか?諺にあるように、敵が来たら兵士で阻止します。洪水が来たら、土でそれを阻止します。ネイティブ パッチがスピンロック メンバーを使用するコード パスをインターセプトすることを考えました。インスタンスにこのメンバーが含まれていないことが判明した場合は、割り当て、初期化、ロック、およびロックの解放が行われます。

問題を解決するには、困難な山を登るだけでなく、潜在的なリスクも管理する必要があります。チームは、何百万ものロードおよびアンロードのホット パッチ テストを実行するスクリプトを作成し、メモリ リークがないこと、スタンドアロン操作が安定していることを発見し、新たな勝利を収めました。

難しさ2: 再現が難しい

もう一つの難点は、問題を再現するのが難しいことです。既存の運用環境でのみ、修正プログラムを検証するケースは少なく、ユーザー環境ではリスクを負うことはできません。この状況に対処するための標準化された処理手順、つまり適切に設計されたグレースケール戦略を設計することがすでにあります。これは、UCloud が常に重視してきた中核的なコンセプトと機能でもあります。分析後、この問題は、ホット パッチの安定性の検証とホット パッチの正確性の検証に分解できます。そこで、次のグレースケール戦略を採用しました。

1. 安定性の検証: まず、いくつかのマシンをテストして、正常かどうかを確認します。次に、社内の重要度の低い 500 台のマシンを使用して修正プログラムを適用します。グレースケールは数日間正常に動作し、安定性を検証してリスクが制御されていることを保証します。

2. 正確性の検証: 問題のあるマシンを見つけ、utime+stime と rtime を同時に出力します。コードのロジックによれば、rtime が utime+stime より小さい場合は古いロジックが実行され、rtime が utime+stime より大きい場合は新しいホット パッチ ロジックが実行されます。下の図に示すように、ホット パッチの新しいロジックに入ると、utime+stime が正常に印刷され、rtime と同期して更新され、ホット パッチの正確性が検証されます。

3. ネットワーク全体への変更: *** 既存のネットワーク環境内のマシンにバッチでホットパッチを適用し、ネットワーク全体に変更を加えました。問題は根本的に解決されました。全面的に協力していただいた運用・保守担当の同僚に感謝申し上げます。

要約すると、異常なプロセス CPU 時間統計の問題に対する完全な分析と解決策のアイデアを詳しく紹介しました。この問題は深刻なダウンタイムの問題ではありませんが、ユーザーが監視データについて混乱し、マシンの負荷が高すぎる可能性があり、リソースを追加する必要があると誤って判断する可能性があります。問題を解決すれば不必要な出費を避けることができます。さらに、この問題は、top コマンドや ps コマンドを使用する際に、R&D、運用保守、技術サポート担当者にも混乱を引き起こします。最終的に、問題の本質を慎重に分析・検証し、ホットパッチで適切に解決しました。