web-dev-qa-db-ja.com

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

Javaプロセスとnrpeのチェックで問題が発生しています。32コアシステムで1000％cpuを使用するプロセスがいくつかあります。

ps aux

または/ proc/pid＃のような何かをしようとする

[[email protected] /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ギグ
  • 4Tb 7200ドライブ×12
  • CentOS 6.5
  • モデルはわかりませんが、ベンダーはSuperMicroです

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

奇妙な点は、他の/ proc/pid＃に入ることができ、それがうまく機能することです。システムはsshを実行するときに応答します。高負荷が通知されたときのように、正常にsshを実行できます。

別の編集

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

[[email protected] ~]# 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

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

[[email protected] ~]# 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をインストールして、スループットパフォーマンスに設定してみました。

[[email protected] ~]# 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  ]
linuxcentosjavacpu-usagehigh-load
13
Mike

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

I/Oの一時的な急上昇により、システムのリソースが不足しています。ストレージサブシステムに関連する場合、90〜160の負荷は非常に悪いニュースです。

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

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

サーバーのI/Oエレベーターを変更していない場合は、ioniceが影響する可能性があります。 [〜＃〜] cfq [〜＃〜] 以外に変更した場合、（このサーバーはおそらく deadline =）、ioniceは違いを生じません。

編集：

本番環境で見たもう1つの奇妙なこと。これらはJavaプロセスであり、マルチスレッド化されていると想定しています。PIDでどのように処理していますか？カーネルのsysctl値は何ですか。 pid_max ？以前にPIDを使い果たし、その結果高負荷になった状況がありました。

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

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

8
ewwhite

問題はディスク関連の問題ではなく明らかです。そして、これは絞首刑の痕跡から明らかです：

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

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

負荷は問題の副作用にすぎず、数値が高いからといって全体像がわかりません。アプリケーションが問題なく動作する、非常に高い負荷のサーバーを使用できます。

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

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

3
Mircea Vutcovici

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

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

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

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

2
Mike

これは別の修正です。

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

Adaptec 71605

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

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

0
Mike