ps auxがJavaプロセスで高CPU / IOにハングしている

Javaプロセスとnrpeチェックにいくつかの問題があります。32コアシステムで時々1000％CPUを使用するプロセスがいくつかあります。あなたがするまで、システムはかなり反応します

ps aux 

または/ proc / pid＃で次のようなことをしようとします

[root@flume07.domain.com /proc/18679]# ls
hangs..

ps auxの痕跡

stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0
stat("/dev/pts1", 0x7fffb8526f00)       = -1 ENOENT (No such file or directory)
stat("/dev/pts", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
readlink("/proc/15693/fd/2", "/dev/pts/1", 127) = 10
stat("/dev/pts/1", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
write(1, "root     15693 15692  0 06:25 pt"..., 55root     15693 15692  0 06:25 pts/1    00:00:00 ps -Af
) = 55
stat("/proc/18679", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
open("/proc/18679/stat", O_RDONLY)      = 5
read(5, "18679 (java) S 1 18662 3738 3481"..., 1023) = 264
close(5)                                = 0
open("/proc/18679/status", O_RDONLY)    = 5
read(5, "Name:\tjava\nState:\tS (sleeping)\nT"..., 1023) = 889
close(5)                                = 0
open("/proc/18679/cmdline", O_RDONLY)   = 5
read(5,

Javaプロセスは正常に動作し、正常に完了しますが、問題は、ps auxが完了するのを待っている間にタイムアウトが発生するため、プロセスがダウンしていると考えて監視を狂わせることです。

私は次のようなことをしようとしました

 nice -19 ionice -c1 /usr/lib64/nagios/plugins/check_procs -w 1:1 -c 1:1 -a 'diamond' -u root -t 30

運がない

編集

システムスペック

• 32コアIntel（R）Xeon（R）CPU E5-2650 0 @ 2.00GHz
• ラムの128ギガ
• 12個の4Tb 7200ドライブ
• CentOS 6.5
• モデルはわかりませんが、ベンダーはSuperMicroです

これが発生したときの負荷は、1分間で約90〜160です。

奇妙な部分は、他の/ proc / pid＃に入ることができ、うまく動作することです。システムは、sshを入力したときに応答します。高負荷のアラートを受け取ったときのように、sshで問題なく実行できます。

別の編集

私はスケジューラに期限を使用しています

[root@dn07.domain.com ~]# for i in {a..m}; do cat /sys/block/sd${i}/queue/scheduler; done
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq

マウントは次のようになります

[root@dn07.manage.com ~]# mount
/dev/sda3 on / type ext4 (rw,noatime,barrier=0)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sda1 on /boot type ext2 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
/dev/sdb1 on /disk1 type xfs (rw,nobarrier)
/dev/sdc1 on /disk2 type xfs (rw,nobarrier)
/dev/sdd1 on /disk3 type xfs (rw,nobarrier)
/dev/sde1 on /disk4 type xfs (rw,nobarrier)
/dev/sdf1 on /disk5 type xfs (rw,nobarrier)
/dev/sdg1 on /disk6 type xfs (rw,nobarrier)
/dev/sdh1 on /disk7 type xfs (rw,nobarrier)
/dev/sdi1 on /disk8 type xfs (rw,nobarrier)
/dev/sdj1 on /disk9 type xfs (rw,nobarrier)
/dev/sdk1 on /disk10 type xfs (rw,nobarrier)
/dev/sdl1 on /disk11 type xfs (rw,nobarrier)
/dev/sdm1 on /disk12 type xfs (rw,nobarrier)

Ok tunedをインストールして、スループットパフォーマンスを設定しようとしました。

[root@dn07.domain.com ~]# tuned-adm profile throughput-performance
Switching to profile 'throughput-performance'
Applying deadline elevator: sda sdb sdc sdd sde sdf sdg sdh[  OK  ] sdk sdl sdm
Applying ktune sysctl settings:
/etc/ktune.d/tunedadm.conf:                                [  OK  ]
Calling '/etc/ktune.d/tunedadm.sh start':                  [  OK  ]
Applying sysctl settings from /etc/sysctl.d/99-chef-attributes.conf
Applying sysctl settings from /etc/sysctl.conf
Starting tuned:                                            [  OK  ]

一般に、読み取りが停止したためにこれが起こるのを見てきました。これは、strace出力によって確認されます。ps auxコマンドの実行中に/ proc / xxxx / cmdlineファイルを読み取ろうとするとハングします。

I / Oの瞬間的なスパイクは、システムのリソースを枯渇させています。90〜160の負荷は、ストレージサブシステムに関連する場合、非常に悪いニュースです。

ストレージアレイについて、ハードウェアRAIDコントローラーが設置されているかどうか教えてください。サーバー上のプライマリアプリケーションに書き込みバイアスがかかっていますか？言及したディスク（12 x 4TB）は、低速のニアラインSASまたはSATAディスクです。ドライブアレイの前に書き込みキャッシュの形式がない場合、書き込みはシステムの負荷を押し上げることができます。これらがSupermicroバックプレーン上の純粋なSATAドライブである場合、他のディスクの問題（タイムアウト、故障したドライブ、バックプレーンなど）の可能性を軽視しないでください。これはすべてのHadoopノードで発生しますか？

簡単なテストはiotop、これが起こっている間に実行しようとすることです。また、これはEL6.5であるため、有効になっているtuned-adm設定がありますか？書き込みバリアは有効になっていますか？

サーバーのI / Oエレベーターを変更していない場合ionice、影響がある可能性があります。CFQ以外に変更した場合（このサーバーはおそらく期限にあるはずです）、ionice違いはありません。

編集：

実稼働環境で見たもう1つの奇妙なことです。これらはJavaプロセスであり、マルチスレッドが非常に多いと仮定します。PIDはどうですか？kernel.pid_maxのsysctl値は何ですか？以前にPIDを使い果たし、結果として高負荷になった状況がありました。

また、カーネルバージョン2.6.32-358.23.2.el6.x86_64に言及しています。これは1年以上前のCentOS 6.4リリースの一部ですが、サーバーの残りの部分は6.5です。yum.confでカーネルの更新をブラックリストに登録しましたか？おそらく、そのシステムのカーネル2.6.32-431.xx以降である必要があります。お使いの古いカーネルにhugepagesの問題がある可能性があります。カーネルを変更できない場合は、次を使用して無効にしてみてください。

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled。

問題はディスク関連の問題ではなく明らかです。そして、これはハングした痕跡から明らかです：

open("/proc/18679/cmdline", O_RDONLY)   = 5
read(5,

/ procは、カーネルとユーザー空間の間のインターフェイスです。ディスクにはまったく触れません。コマンドの引数を読み取ってハングアップした場合、通常はカーネル関連の問題であり、ストレージの問題ではありません。@kasperdコメントを参照してください。

負荷は問題の副次的な影響にすぎず、数値が大きいと完全な話をすることができません。非常に高負荷のサーバーがあり、そのサーバー上で問題なく動作することができます。

で何が起こっているかについての詳細情報を得ることができcat /proc/$PID/stackます。$PID読み取りが停止するプロセスIDはどこですか。

あなたの場合は、カーネルのアップグレードから始めます。

そのため、CentOSが提供するすべての調整と最新の2.6カーネルへのアップグレードを行っても、ハングが引き続き発生していました。以前ほどではありませんが、まだそれらを見ています。

修正は、CentOSがここのcentosplusリポジトリで提供する3.10.xシリーズカーネルにアップグレードすることでした。

http://mirror.centos.org/centos/6/xen4/x86_64/Packages/

これにより、すべてのプロセスツリーのハングがなくなりました。私が言ったように、システムは新しいプロセスの実行がきちんとしたものであるような狂ったような負荷の下にはありませんでした。そのため、ほとんどが2.6カーネルの問題になります。

これは別の修正です。

次のRAIDコントローラーを実行しているようです

Adaptec 71605

影響を受けるすべてのマシンのファームウェアを最新バージョンに更新してきましたが、問題は解決しているようです。

CentOS 6に3.10をインストールする他のランダムな問題のため、3.10カーネルの実験からダウングレードする必要がありましたが、ファームウェアのアップグレードにより問題が修正されたようです。