目录
top命令:
登录到服务器使用top命令确认服务器的具体情况
top - 18:23:14 up 15 days, 3:21, 1 user, load average: 1.91, 1.87, 1.68
Tasks: 202 total, 1 running, 201 sleeping, 0 stopped, 0 zombie
Cpu(s): 11.6%us, 5.0%sy, 0.0%ni, 82.4%id, 0.0%wa, 0.0%hi, 0.9%si, 0.1%st
Mem: 8057844k total, 7900088k used, 157756k free, 260704k buffers
Swap: 4192924k total, 0k used, 4192924k free, 2638024k cached
第一行是任务队列信息,同 uptime 命令的执行结果。其内容如下:
符号 | 含义 |
---|---|
18:52:04 | 当前时间 |
up 10days, 3:49 | 系统运行时间,格式为:天,时:分 |
1 user | 当前登录用户数 |
load average: 0.00, 0.01, 0.05 | 系统负载,即任务队列的平均长度。三个数值分别为 1分钟、5分钟、15分钟前到现在的平均值 |
第二、三行为进程和CPU的信息。当有多个CPU时,这些内容可能会超过两行。内容如下:
符号 | 含义 |
---|---|
total | 进程总数 |
running | 正在运行的进程数 |
sleeping | 睡眠的进程数 |
stopped | 停止的进程数 |
zombie | 僵尸进程数 |
%Cpu(s) |
|
0.0 us | 用户空间占用CPU百分比 |
0.1 sy | 内核空间占用CPU百分比 |
0.0 ni | 用户进程空间内改变过优先级的进程占用CPU百分比 |
98.7 id | 空闲CPU百分比; |
0.0 wa | 等待输入输出的CPU时间百分比 |
0.0 hi | 硬件CPU中断占用百分比 |
0.0 si | 软中断占用百分比 |
0.0 st | 虚拟机占用百分比 |
最后两行为内存信息。内容如下:
符号 | 含义 |
---|---|
KiB Mem |
|
7993560 total | 物理内存总量 |
207064 free | 空闲内存总量 |
723688 used | 使用的物理内存总量 |
7062808 buffer/cache | 用作内核缓存的内存量 |
KiB Swap |
|
8257532 total | 交换区总量 |
8257356 free | 空闲交换区总量 |
176 used | 使用的交换区总量 |
6479580 avail Mem | 缓冲的交换区总量,内存中的内容被换出到交换区,而后又被换入到内存,但使用过的交换区尚未被覆盖,该数值即为这些内容已存在于内存中的交换区的大小,相应的内存再次被换出时可不必再对交换区写入 |
进程信息区统计信息区域的下方显示了各个进程的详细信息。首先来认识一下各列的含义。
序号 | 列名 | 含义 |
---|---|---|
a | PID | 进程id |
b | PPID | 父进程id |
c | RUSER | Real user name |
d | UID | 进程所有者的用户id |
e | USER | 进程所有者的用户名 |
f | GROUP | 进程所有者的组名 |
g | TTY | 启动进程的终端名。不是从终端启动的进程则显示为 ? |
h | PR | 优先级 |
i | NI | nice值。负值表示高优先级,正值表示低优先级 |
j | P | 最后使用的CPU,仅在多CPU环境下有意义 |
k | %CPU | 上次更新到现在的CPU时间占用百分比(进程占用单核cpu的时间占比) |
l | TIME | 进程使用的CPU时间总计,单位秒 |
m | TIME+ | 进程使用的CPU时间总计,单位1/100秒 |
n | %MEM | 进程使用的物理内存百分比 |
o | VIRT | 进程使用的虚拟内存总量,单位kb。VIRT=SWAP+RES |
p | SWAP | 进程使用的虚拟内存中,被换出的大小,单位kb。 |
q | RES | 进程使用的、未被换出的物理内存大小,单位kb。RES=CODE+DATA |
r | CODE | 可执行代码占用的物理内存大小,单位kb |
s | DATA | 可执行代码以外的部分(数据段+栈)占用的物理内存大小,单位kb |
t | SHR | 共享内存大小,单位kb |
u | nFLT | 页面错误次数 |
v | nDRT | 最后一次写入到现在,被修改过的页面数。 |
w | S | 进程状态(D=不可中断的睡眠状态,R=运行,S=睡眠,T=跟踪/停止,Z=僵尸进程) |
x | COMMAND | 命令名/命令行 |
y | WCHAN | 若该进程在睡眠,则显示睡眠中的系统函数名 |
z | Flags | 任务标志,参考 sched.h |
top 按1后显示每个核的cpu使用情况
定位具体的异常业务
这里咱们可以使用 pwdx 命令根据 pid 找到业务进程路径,进而定位到负责人和项目:
可得出结论:该进程对应的就是sqs服务
定位异常线程及具体代码行
1.执行top -c命令,找到cpu最高的进程的id
2.执行top -H -p pid,这个命令就能显示刚刚找到的进程的所有线程的资源消耗情况。找到CPU负载高的线程pid 8627, 把这个数字转换成16进制,21B3(10进制转16进制,用linux命令: printf %x 8627)。
3.执行jstack -l pid,拿到进程的线程dump文件。这个命令会打出这个进程的所有线程的运行堆栈。
4.用记事本打开这个文件,搜索“21B3”,就是搜一下16进制显示的线程id。搜到后,下面的堆栈就是这个线程打出来的。排查问题从这里深入。
今天最后排查出来的结果是“VM THREAD”把进程的资源耗尽。那只能说明是jvm在耗cpu。很容易想到是疯狂的GC,按关键字 “overhead” 搜一下系统日志, 发现 “java.lang.OutOfMemoryError: GC overhead limit exceeded”日志。问题明了了。jvm在疯狂的Full GC,而且有个大对象始终根节点路径可达,无法释放。dump了一下这个实例的内存,发现确实有大对象,占用了一个多G的堆内存。
传统的方案一般是4步:
-
top + P 按cpu占比排序 +M 按内存占比排序 // 首先按进程负载排序找到 maxLoad(pid)
-
top -Hp 进程PID:1073 // 找到相关负载 线程PID
-
printf “0x%x\n”线程PID: 0x431 // 将线程PID转换为 16进制,为后面查找 jstack 日志做准备
-
jstack 进程PID | vim +/十六进制线程PID - // 例如:jstack 1040|vim +/0x431