我在 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
- 128gig 内存
- 12 个 4Tb 7200 驱动器
- CentOS 6.5
- 我不确定型号,但供应商是 SuperMicro
发生这种情况时的负载约为 90-160ish 1 分钟。
奇怪的是我可以进入任何其他 /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)
好的,我尝试安装调整并将其设置为吞吐量性能。
[[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 ]
一般来说,我看到这种情况是由于阅读停滞而发生的。您的
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中可以清楚地看出:
/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 控制器
我一直在将所有受影响的机器固件更新到最新版本,这似乎正在解决问题。
由于在 CentOS 6 上安装 3.10 的其他随机问题,我们不得不从 3.10 内核实验降级,但固件升级似乎解决了这个问题。