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",...}) = 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,...}) = 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核心英特尔(R)Xeon(R)cpu E5-2650 0 @ 2.00GHz
> 128gig的ram
> 12个4Tb 7200驱动器
> CentOS 6.5
>我不确定模型,但供应商是SuperMicro
发生这种情况时的负荷约为90-160ish,持续1分钟.
奇怪的是我可以进入任何其他/ proc / pid#并且它工作得很好.当我进入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 ]
解决方法
I / O中的瞬间峰值正在使系统资源匮乏.如果与存储子系统相关,那么90-160的负载是非常坏的消息.
对于存储阵列,您能否告诉我们是否有硬件RAID控制器？服务器上的主要应用程序是否存在写入偏差？您提到的磁盘(12 x 4TB)是低速近线SAS或SATA磁盘.如果驱动器阵列前面没有write caching形式,则写入能够推动系统负载.如果这些是Supermicro背板上的纯SATA驱动器,请不要打折possibility of other disk problems(超时,故障驱动器,背板等)这是否会在所有Hadoop节点上发生？
一个简单的测试是尝试在发生这种情况时运行iotop.此外,由于这是EL6.5,你有没有启用任何tuned-adm settings？是否启用了写入障碍？
如果您尚未更换服务器的I / O电梯,则可能会产生影响.如果您已将其更改为CFQ以外的任何内容(此服务器应该在deadline),则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.x.x或更新版本的系统. There could be a hugepages issue with the older kernel you have.如果您无法更改内核,请尝试使用以下命令禁用它们：
echo never> / SYS /内核/ MM / redhat_transparent_hugepage /启用.
