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-160ish 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)好的，我嘗試安裝調整併將其設置為吞吐量性能。
[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.