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
• 公羊128gig
• 12个4Tb 7200驱动器
• CentOS的6.5
• 我不确定型号，但供应商是SuperMicro

发生这种情况时，负载大约在90-160欧元之间持续1分钟。

奇怪的是，我可以进入任何其他的/ 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)

好的，我尝试安装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则不会有任何区别。

编辑：

我在生产环境中看到的另一件事很奇怪。这些是Java进程，我假设它们是多线程的。您如何处理PID？kernel.pid_max的sysctl值是多少？我曾经遇到过用尽PID的情况，并因此产生了高负载。

此外，您还提到了内核版本2.6.32-358.23.2.el6.x86_64。这已经超过一年了，并且是CentOS 6.4发行版的一部分，但是服务器的其余部分是6.5。您是否在yum.conf中将内核更新列入黑名单？对于该系统，您可能应该在内核2.6.32-431.xx或更高版本上。您所拥有的旧内核可能会出现大量页面问题。如果您不能更改内核，请尝试使用以下命令禁用它们：

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

问题很明显不是磁盘相关的问题。从悬挂的strace可以明显看出这一点：

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内核实验降级，但是固件升级似乎可以解决该问题。