web-dev-qa-db-ja.com

高システムCPU負荷（％sys）、システムロック

過去2週間、システムのCPU使用率に断続的な重大なスパイク（％sysとして表示）が発生します。これはおそらく30分間続き、sshを含むほとんどのプロセスがロックされます。

私はこれを理解しようとしましたが、上部には関連性がありません（表示されるプロセスのシステム使用率は重要ではありません）、スパイクは断続的であり、このWebサーバーがホストするWebアプリケーションのワークロードを使用してスパイクを再現できませんでした.

％sysおよび（場合によっては）％siの高いCPU使用率をデバッグする方法についてアイデアがあれば、共有してください。

システム仕様（これに該当するかどうかは不明）：専用サーバー、CentOS 6、コアi7 950、一貫性のある4〜8 GB RAMいつでも空き、ハードドライブはRAIDにある-1。

追加情報：

  • dmesgの出力がスパイク間で変化しない
  • / var/log/messagesはスパイク間で変化しません
  • これが cat/proc/vmstat です
  • これは、典型的なスパイク中の mpstat 1 の出力です

07.11.11を追加します。単純な再起動によってシステム状態が復元されたように見えますが、そもそも障害の原因がわからない可能性があります。

linuxcentral-processing-unit
7
Mark

ばかげているように聞こえるかもしれませんが、最初からスパイクが発生した原因は、再起動が役立ち、私たちにはわからないかもしれません。

回答ありがとうございます。

0
Mark

このスレッドは本当に古く、％sys->サイクルが％systemで費やされている場合、実行の多くはより低いレベルのコードで行われるため、カーネル側で問題が発生している可能性があることは既に知っています。この問題が再現する場合は、次の出力を収集してください。

echo t > /proc/sysrq-trigger

システムメッセージ（var/log/messagesまたは/var/log/syslog）は、スレッドがシステムCPU時間を大量に使用していないかどうかを確認します。

4
Prashant Lakhera

CentOS 6.2および6.3では、巨大ページのサポートを無効にします。

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
1
Andrija

高い％siは、高い割り込み率を示唆します（siは、softirqハンドラー、AFAIKで費やされた時間です）。したがって、私の最初の推測は、サーバーのネットワークインターフェイスが破壊されていることです。

0
janneb