一、ps aux 或 lax 输出的解释

USER 进程的属主；

PID 进程的ID；

PPID 父进程；

%CPU 进程占用的CPU百分比；

%MEM 占用内存的百分比；

NI 进程的NICE值，数值大，表示较少占用CPU时间；

VSZ 进程虚拟大小；

RSS 驻留中页的数量；

TTY 终端ID

STAT 进程状态（有以下几种）

D 无法中断的休眠状态（通常 IO 的进程）；

R 正在运行可中在队列中可过行的；

S 处于休眠状态；

T 停止或被追踪；

W 进入内存交换（从内核2.6开始无效）；

X 死掉的进程（从来没见过）；

Z 僵尸进程；

< 优先级高的进程

N 优先级较低的进程

L 有些页被锁进内存；

s 进程的领导者（在它之下有子进程）；

l 多进程的（使用 CLONE_THREAD, 类似 NPTL pthreads）；

+ 位于后台的进程组；

WCHAN 正在等待的进程资源；

START 启动进程的时间；

TIME 进程消耗CPU的时间；

COMMAND 命令的名称和参数；

Linux是一个多用户，多任务的系统，可以同时运行多个用户的多个程序，就必然会产生很多的进程，而每个进程会有不同的状态。

Linux进程状态：R (TASK_RUNNING)，可执行状态。

只有在该状态的进程才可能在CPU上运行。而同一时刻可能有多个进程处于可执行状态，这些进程的task_struct结构（进程控制块）被放入对应CPU的可执行队列中（一个进程最多只能出现在一个CPU的可执行队列中）。进程调度器的任务就是从各个CPU的可执行队列中分别选择一个进程在该CPU上运行。

很多操作系统教科书将正在CPU上执行的进程定义为RUNNING状态、而将可执行但是尚未被调度执行的进程定义为READY状态，这两种状态在linux下统一为 TASK_RUNNING状态。

Linux进程状态：S (TASK_INTERRUPTIBLE)，可中断的睡眠状态。

处于这个状态的进程因为等待某某事件的发生（比如等待socket连接、等待信号量），而被挂起。这些进程的task_struct结构被放入对应事件的等待队列中。当这些事件发生时（由外部中断触发、或由其他进程触发），对应的等待队列中的一个或多个进程将被唤醒。

通过ps命令我们会看到，一般情况下，进程列表中的绝大多数进程都处于TASK_INTERRUPTIBLE状态（除非机器的负载很高）。毕竟CPU就这么一两个，进程动辄几十上百个，如果不是绝大多数进程都在睡眠，CPU又怎么响应得过来。

Linux进程状态：D (TASK_UNINTERRUPTIBLE)，不可中断的睡眠状态。

与TASK_INTERRUPTIBLE状态类似，进程处于睡眠状态，但是此刻进程是不可中断的。不可中断，指的并不是CPU不响应外部硬件的中断，而是指进程不响应异步信号。

绝大多数情况下，进程处在睡眠状态时，总是应该能够响应异步信号的。否则你将惊奇的发现，kill -9竟然杀不死一个正在睡眠的进程了！于是我们也很好理解，为什么ps命令看到的进程几乎不会出现TASK_UNINTERRUPTIBLE状态，而总是TASK_INTERRUPTIBLE状态。

而TASK_UNINTERRUPTIBLE状态存在的意义就在于，内核的某些处理流程是不能被打断的。如果响应异步信号，程序的执行流程中就会被插入一段用于处理异步信号的流程（这个插入的流程可能只存在于内核态，也可能延伸到用户态），于是原有的流程就被中断了。（参见《linux内核异步中断浅析》）

在进程对某些硬件进行操作时（比如进程调用read系统调用对某个设备文件进行读操作，而read系统调用最终执行到对应设备驱动的代码，并与对应的物理设备进行交互），可能需要使用TASK_UNINTERRUPTIBLE状态对进程进行保护，以避免进程与设备交互的过程被打断，造成设备陷入不可控的状态。这种情况下的TASK_UNINTERRUPTIBLE状态总是非常短暂的，通过ps命令基本上不可能捕捉到。

二、查看系统负载vmstat

procs

r 列表示运行和等待cpu时间片的进程数，如果长期大于1，说明cpu不足，需要增加cpu。

b 列表示在等待资源的进程数，比如正在等待I/O、或者内存交换等。

cpu 表示cpu的使用状态

us 列显示了用户方式下所花费 CPU 时间的百分比。us的值比较高时，说明用户进程消耗的cpu时间多，但是如果长期大于50%，需要考虑优化用户的程序。

sy 列显示了内核进程所花费的cpu时间的百分比。这里us + sy的参考值为80%，如果us+sy 大于 80%说明可能存在CPU不足。

wa 列显示了IO等待所占用的CPU时间的百分比。这里wa的参考值为30%，如果wa超过30%，说明IO等待严重，这可能是磁盘大量随机访问造成的，也可能磁盘或者磁盘访问控制器的带宽瓶颈造成的(主要是块操作)。

id 列显示了cpu处在空闲状态的时间百分比

system 显示采集间隔内发生的中断数

in 列表示在某一时间间隔中观测到的每秒设备中断数。

cs列表示每秒产生的上下文切换次数，如当 cs 比磁盘 I/O 和网络信息包速率高得多，都应进行进一步调查。

memory

swpd 切换到内存交换区的内存数量(k表示)。如果swpd的值不为0，或者比较大，比如超过了100m，只要si、so的值长期为0，系统性能还是正常

free 当前的空闲页面列表中内存数量(k表示)

buff 作为buffer cache的内存数量，一般对块设备的读写才需要缓冲。

cache: 作为page cache的内存数量，一般作为文件系统的cache，如果cache较大，说明用到cache的文件较多，如果此时IO中bi比较小，说明文件系统效率比较好。

swap

si 由内存进入内存交换区数量。

so由内存交换区进入内存数量。

IO

bi 从块设备读入数据的总量（读磁盘）（每秒kb）。

bo 块设备写入数据的总量（写磁盘）（每秒kb）

这里我们设置的bi+bo参考值为1000，如果超过1000，而且wa值较大应该考虑均衡磁盘负载，可以结合iostat输出来分析。

查看磁盘负载iostat

每隔2秒统计一次磁盘IO信息，直到按Ctrl+C终止程序，-d 选项表示统计磁盘信息， -k 表示以每秒KB的形式显示，-t 要求打印出时间信息，2 表示每隔 2 秒输出一次。第一次输出的磁盘IO负载状况提供了关于自从系统启动以来的统计信息。随后的每一次输出则是每个间隔之间的平均IO负载状况。

# iostat -x 1 10

rqm/s: 每秒进行 merge 的读操作数目。即 delta(rmerge)/s

wrqm/s: 每秒进行 merge 的写操作数目。即 delta(wmerge)/s

r/s: 每秒完成的读 I/O 设备次数。即 delta(rio)/s

w/s: 每秒完成的写 I/O 设备次数。即 delta(wio)/s

rsec/s: 每秒读扇区数。即 delta(rsect)/s

wsec/s: 每秒写扇区数。即 delta(wsect)/s

rkB/s: 每秒读K字节数。是 rsect/s 的一半，因为每扇区大小为512字节。(需要计算)

wkB/s: 每秒写K字节数。是 wsect/s 的一半。(需要计算)

avgrq-sz: 平均每次设备I/O操作的数据大小 (扇区)。delta(rsect+wsect)/delta(rio+wio)

avgqu-sz: 平均I/O队列长度。即 delta(aveq)/s/1000 (因为aveq的单位为毫秒)。

await: 平均每次设备I/O操作的等待时间 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)

svctm: 平均每次设备I/O操作的服务时间 (毫秒)。即 delta(use)/delta(rio+wio)

%util: 一秒中有百分之多少的时间用于 I/O 操作，或者说一秒中有多少时间 I/O 队列是非空的。即 delta(use)/s/1000 (因为use的单位为毫秒)  如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。

idle小于70% IO压力就较大了,一般读取速度有较多的wait.

同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时IO压力高)

另外还可以参考

一般:

svctm < await (因为同时等待的请求的等待时间被重复计算了)，

svctm的大小一般和磁盘性能有关:CPU/内存的负荷也会对其有影响，请求过多也会间接导致 svctm 的增加。

await: await的大小一般取决于服务时间(svctm) 以及 I/O 队列的长度和 I/O 请求的发出模式。

如果 svctm 比较接近 await，说明I/O 几乎没有等待时间；

如果 await 远大于 svctm，说明 I/O队列太长，应用得到的响应时间变慢，

如果响应时间超过了用户可以容许的范围，这时可以考虑更换更快的磁盘，调整内核 elevator算法，优化应用，或者升级 CPU。

队列长度(avgqu-sz)也可作为衡量系统 I/O 负荷的指标，但由于 avgqu-sz 是按照单位时间的平均值，所以不能反映瞬间的 I/O 洪水。

fuser 查看问题目录进程

问题定位/mnt目录,使用fuser 查看此目录占用进程

root@pts/30 # fuser -m /mnt

解决df 、 find 不好使的问题

解决思路：

1.、strace 命令跟踪,定位问题，首先使用 命令跟踪, 查看执行到哪一步卡死

2、也可以使用cat /proc/mounts 查看当前mount状态,发现确实有对mnt目录的记录

3. fuser 查看问题目录进程，使用fuser 查看此目录占用进程，然后kill掉

遇到的问题：登录服务器想查看磁盘使用情况，使用了df，但卡住半天没有响应，运行strace df，发现最后卡在了stat(“/proc/sys/fs/binfmt_misc”, 

无法进入这个路径“/proc/sys/fs/binfmt_misc”，想到”/proc/sys/fs/”下ls看下这个文件夹，也会卡住

运行mount输出，正常有“binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc 

(rw,relatime)”，发现这个服务器没有挂载，想尝试挂载mount binfmt_misc -t binfmt_misc 

/proc/sys/fs/binfmt_misc ，也会卡在“readlink(“/proc/sys/fs/binfmt_misc””

解决方式

1. systemctl restart proc-sys-fs-binfmt_misc.automount;

2. 升级到最新 systemd-219-57 版本; 

3. 按照红帽知识库的步骤对 proc-sys-fs-binfmt_misc.automount 进行 mask 操作, 只进行静态的 mount 操作;

我用的第一种方式，亲测好使