89％CPUは理想的ですが、rhel8.4の負荷平均は非常に高いです。

Question

これは、アプリケーション（特にJavaアプリケーション）が多いスレッドを使用し、何か（データベース操作やネットワークアクセスなど）によってアプリケーションがシリアル化されるときの一般的なパターンです。

ほとんどのアプリケーションスレッドがオペレーティングシステムスケジューラによって待機状態で完全に表示されないエントリを待っている場合、すべてのスレッドは処理のためにキューに追加されますが、順番が来ると、ほとんどは何をチェックするだけです。彼らは処理されたコンテンツが欲しい。待つと、今回のラウンドのCPUタイムスロットを放棄し、再実行キューに戻ります。これにより、CPU に十分なアイドル時間がある場合でも、負荷平均が途方もないレベルに増加する可能性があります。

これにより、自動化された監視（さらにはオペレーターも！）がパニックになる可能性があります。従来のコンピューティング集約型ワークロードの高い負荷値は、システムが絶望的に輻輳して多くの有用なタスクを実行できないことを意味するためです。ただし、アイドルCPU時間と使用可能なメモリが多いため、ワークロードは明らかに計算集約的またはメモリ集約的ではありません。つまり、I/O 集約的でなければなりません。

Java VM はこの状況を悪化させる可能性があります。 JVMレベルのJavaスレッドの待機状態が対応するオペレーティングシステムレベルの待機状態に直接マップされない場合、Javaコードが「休止」しても、Javaスレッドの基本スレッドはスリープ状態になります。。 JVMは、上記のように「短いループ」につながる可能性がある省電力モード解除条件を継続的に確認する必要があります。

特定のケースでは、CPU時間消費の上位10人のうち7人がユーザーのJavaプロセスですyarn。 JVMを詳しく見て、各JVMの個々のスレッドが平均して何をしているのかを調べ、それらが何を待っているのかを調べようとする必要があります。最初の推測は、ある種のデータベースまたはネットワーク操作がいくつかの重要なスレッドをブロックしており、その後、その重要なスレッドが進むまで他のスレッドを続行できないことです。

残念ながら、これはアプリケーション開発者だけが実際に解決できる問題であることがよくあります。彼らは、ロックなしの方法で必要なタスクを実行するアルゴリズムを見つけ、データベースクエリが合理的であり、データベースがアプリケーションの要件に合わせて最適に設定されていることを確認する必要があります。

有用な材料：https://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html

Answer 1

これは、アプリケーション（特にJavaアプリケーション）が多いスレッドを使用し、何か（データベース操作やネットワークアクセスなど）によってアプリケーションがシリアル化されるときの一般的なパターンです。