異常な高負荷平均の原因は何ですか？
先週の火曜日の夜に気づいたところ、トラフィックが少ないため負荷平均が急激に上がり異常に見えた。通常、数は平均して約.40以下で、私のサーバー（mysql、php、Apache）は最適化されています。プロセスがCPUをほとんど使用していないにもかかわらず、IOWaitが異常に高いことに気付きました。
トップ-01:44:39 1日、21：13、1ユーザー、平均負荷：1.41、1.09、0.86 タスク：合計60、実行1、スリープ59、停止0、ゾンビ0 Cpu0：0.0％us、0.0％sy、0.0％ni、100.0％id、0.0％wa、0.0％hi、0.0％si、0.0％st Cpu1：0.0％us、0.0％sy、 0.0％ni、100.0％id、0.0％wa、0.0％hi、0.0％si、0.0％st Cpu2：0.0％us、0.3％sy、0.0％ni、99.7％id、0.0％wa、 0.0％hi、0.0％si、0.0％st Cpu3：0.0％us、0.0％sy、0.0％ni、100.0％id、0.0％wa、0.0％hi、0.0％si、0.0％st Cpu4：0.0％us、0.0％sy、0.0％ni、100.0％id、0.0％wa、0.0％hi、0.0％si、0.0％st Cpu5：0.0％us、0.0％ sy、0.0％ni、100.0％id、0.0％wa、0.0％hi、0.0％si、0.0％st Cpu6：0.0％us、0.0％sy、0.0％ni、100.0％id、0.0％ wa、0.0％hi、0.0％si、0.0％st Cpu7：0.0％us、0.0％sy、0.0％ni、91.5％id、8.5％wa、0.0％hi、0.0％si、0.0％ st Mem：合計1048576k、使用済み331944k、空き716632k、0kバッファ スワップ：合計0k、使用0k、空き0k、キャッシュ0k [.___ _。] PID USER PR NI VIRT RES SHR S％CPU％MEM TIME + COMMAND 1 root 15 0 2468 1376 1140 S 0 0.1 0：00.92 init 1656 root 15 0 13652 5212 664 S 0 0.5 0：00.00 Apache2 9323 root 18 0 13652 5212 664 S 0 0.5 0：00.00 Apache2 10079 root 18 0 3972 1248 972 S 0 0.1 0：00.00 su 10080 root 15 0 4612 1956 1448 S 0 0.2 0：00.01 bash 11298 root 15 0 13652 5212 664 S 0 0.5 0：00.00 Apache2 11778 chikorit 15 0 2344 1092 884 S 0 0.1 0：00.05 top 15384 root 18 0 17544 13m 1568 S 0 1.3 0：02.28 miniserv.pl 15585 root 15 0 8280 2736 2168 S 0 0.3 0：00.02 sshd 15608チコリット15 0 8280 1436 860 S 0 0.1 0：00.02 sshd
これがVMStatです
procs ----------- memory ---------- --- swap-- ----- io ---- -system-- ---- cpu-- - rb swpd free buff cache si so bi bo in cs us sy id wa 1 0 0 768644 0 0 0 0 14 23 0 10 1 0 99 0
IOStat-異常はありません
総ディスク読み取り：67.13 K /秒|合計ディスク書き込み：0.00 B/s TID PRIOユーザーディスク読み取りディスク書き込みSWAPIN IO>コマンド 19496 be/4 chikorit 11.85 K/s 0.00 B/s 0.00％0.00％Apache2 -k start 19501 be/4 mysql 3.95 K/s 0.00 B/s 0.00％0.00％mysqld 19568 be/4 chikorit 11.85 K/s 0.00 B/s 0.00％0.00％Apache2 -k start 19569 be/4 chikorit 11.85 K/s 0.00 B/s 0.00％0.00％Apache2 -k start 19570 be/4 chikorit 11.85 K/s 0.00 B/s 0.00％0.00％Apache2 -k start 19571 be/4 chikorit 7.90 K/s 0.00 B/s 0.00％0.00％Apache2 -k start 19573 be/4 chikorit 7.90 K/s 0.00 B/s 0.00％0.00％Apache2 -k start 1 be/4 root 0.00 B/s 0.00 B/s 0.00％0.00％init 11778 be/4 chikorit 0.00 B/s 0.00 B/s 0.00％0.00％top 19470 be/4 mysql 0.00 B/s 0.00 B/s 0.00％0.00％mysqld
平均グラフの読み込み- http://i.stack.imgur.com/kYsD0.png
これを確認する前に、これがMySQLの問題でないかどうかを確認したいと思います。また、これはOpenVZ上のUbuntu 10.04 LTSサーバーです。
編集：これはおそらくIO待つ上で良い絵を与えるでしょう
top-22:12:22 up 17：41、1ユーザー、負荷平均：1.10、1.09、0.93 タスク：合計33、1実行、32スリープ、0停止、0ゾンビ CPU （s）：0.6％us、0.2％sy、0.0％ni、89.0％id、10.1％wa、0.0％hi、0.0％si、0.0％st Mem：合計1048576k、260708k使用、787868k無料、0kバッファ スワップ：合計0k、使用0k、空き0k、キャッシュ0k PID USER PR NI VIRT RES SHR S％CPU％MEM TIME + COMMAND 1ルート15 0 2468 1376 1140 S 0 0.1 0：00.88 init 5849ルート15 0 12336 4028 668 S 0 0.4 0：00.00 Apache2 8063ルート15 0 12336 4028 668 S 0 0.4 0： 00.00 Apache2 9732 root 16 0 8280 2728 2168 S 0 0.3 0：00.02 sshd 9746 chikorit 18 0 8412 1444 864 S 0 0.1 0：01.10 sshd 9747 chikorit 18 0 4576 1960 1488 S 0 0.2 0：00.24 bash 13706 chikorit 15 0 2344 1088 884 R 0 0.1 0：00.03 top 15745 chikorit 15 0 12968 5108 1280 S 0 0.5 0：00.00 Apache2 15751 chikorit 15 0 72184 25m 18m S 0 2.5 0：00.37 php5-fpm 15790 chikorit 18 0 12472 4640 1 192 S 0 0.4 0：00.00 Apache2 15797 chikorit 15 0 72888 23m 16m S 0 2.3 0：00.06 php5-fpm 16038 root 15 0 67772 2848 592 D 0 0.3 0：00.00 php5-fpm 16309 syslog 18 0 24084 1316 992 S 0 0.1 0：00.07 rsyslogd 16316 root 15 0 5472 908500 S 0 0.1 0：00.00 sshd 16326 root 15 0 2304 908 712 S 0 0.1 0：00.02 cron 17464 root 15 0 10252 7560 856 D 0 0.7 0：01.88 psad 17466 root 18 0 1684 276208 S 0 0.0 0：00.31 psadwatchd 17559ルート18 0 11444 2020 732 S 0 0.2 0：00.47 sendmail-mta 17688ルート15 0 10252 5388 1136 S 0 0.5 0：03.81 python 17752 teamspea 19 0 44648 7308 4676 S 0 0.7 1：09.70 ts3server_linux 18098 root 15 0 12336 6380 3032 S 0 0.6 0：00.47 Apache2 18099 chikorit 18 0 10368 2536 464 S 0 0.2 0：00.00 Apache2 18120 ntp 15 0 4336 1316 984 S 0 0.1 0：00.87 ntpd 18379 root 15 0 12336 4028 668 S 0 0.4 0：00.00 Apache2 18387 mysql 15 0 62796 36m 5864 S 0 3.6 1：43.26 mysqld [.__ __。] 19584ルート15 0 12336 4028 668 S 0 0.4 0：00.02 Apache2 22498ルート16 0 12336 4028 668 S 0 0.4 0：00.00 Apache2 24260ルート15 0 67772 3612 1356 S 0 0.3 0：00.22 php5-fpm 27712 root 15 0 12336 4028 668 S 0 0.4 0：00.00 Apache2 27730 root 15 0 12336 4028 668 S 0 0.4 0：00.00 Apache2 30343 root 15 0 12336 4028 668 S 0 0.4 0：00.00 Apache2 30366 root 15 0 12336 4028 668 S 0 0.4 0：00.00 Apache2
これは現在のところ無料のRAMです。
キャッシュされた使用済み共有バッファの合計 Mem：1024 302 721 0 0 0 -/ + buffers/cache：302 721 スワップ：0 0 0
更新：ログ、特にCPUスパイクの原因となっているPHP5-FPMを調べます。何らかの理由でそのセグメントに障害が発生していることがわかりました。
[2012年6月3日06:11:20]通知：[プールwww]子14132が開始されました [2012年6月3日06:11:25]警告：[プールwww]子13664は、開始から53.686322秒後に信号11（SIGSEGV）で終了しました [03-Jun-2012 06:11:25]通知：[プールwww]子14328が開始しました [03-Jun-2012 06:11:25]警告：[プールwww]子14132は、開始から4.708681秒後に信号11（SIGSEGV）で終了しました [03-Jun-2012 06:11:25]通知：[プールwww]子14329が開始されました [2012年6月3日06:11:58]警告：[プールwww]子14328は、開始から32.981228秒後に信号11（SIGSEGV）で終了しました [2012年6月3日06:11:58]通知：[プールwww]子15745が開始しました [03-Jun-2012 06:12:25]警告：[プールwww]子15745は27.442864秒後にシグナル11（SIGSEGV）で終了しました開始から [2012年6月3日06:12:25]通知：[プールwww]子供17446が開始しました [2012年6月3日06:12:25]警告：[プールwww ]開始から60.411278秒後に子14329がシグナル11（SIGSEGV）で終了しました [03-Jun-2012 06:12:25]通知：[プールwww]子17447が開始されました [03-Jun-2012 06:13:02]警告：[プールwww]子17446は信号11（SIGSEGV）で36.746793秒後に終了しました開始 [2012年6月3日06:13:02]通知：[プールwww]子18133が開始しました [2012年6月3日06:13:48]警告：[プールwww ]開始から82.710107秒後に子17447がシグナル11（SIGSEGV）で終了しました
これが問題を引き起こしているのではないかと思っています。それが原因である場合、おそらくそれをfastcgi/fcgidに切り替えることで解決できる可能性があります...しかし、それでも、他の何かが原因でこれが行われていないかどうかを確認したいと思います。
見たところ、高いCPU使用率は、Wordpressプラグイン、Google XMLサイトマップジェネレーターが原因であると考えられます。これを無効にすると、CPUの平均はほとんど低下しました。それでも、プラグインを監査して削除するCPUを過度に使用する可能性があるもの。
サーバーにメモリの問題があると思います。これにより、データがバッファーではなくディスクから送信されるのをコンテナーが待機する必要があります。サーバーにアクセスできる場合は、コンテナーで実行するのではなく、サーバーでvmstatを実行してみてください。仮想サーバーのメモリ管理は、ホストサーバーに依存しています。最初に気づいたのは、データのバッファ、キャッシュ、またはスワップがないことです。これらはすべてパフォーマンスにとって重要です。
I/Oの増加を引き起こしているプロセスを確認するには、dstatまたはiotopを使用できます。
Phpがクラッシュする理由を確認するには、Apacheの起動時にulimit -c unlimited。次回phpがクラッシュすると、コアダンプが発生します。クラッシュのスタックトレースを取得するには、bt内でgdbコマンドを使用します。例えば。
gdb /usr/bin/httpd core
(gdb) bt
また、物理ディスクサブシステムに実際の問題がないことを確認/確認しました-RAIDの再構築、BBUの失敗、単一ディスクの故障...も同様の症状を引き起こす可能性があります