类别 | 监控命令 | 描述 | 备注 |
内存瓶颈 | free | 查看内存使用 | |
vmstat 3(间隔时间) 100(监控次数) | 查看swap in/out详细定位是否存在性能瓶颈 | 推荐使用 | |
sar -r 3 | 和free命令类似,查看内存的使用情况,但是不包含swap的情况 | ||
cpu瓶颈 | top -H | 按照cpu消耗高低进行排序 | |
ps -Lp 进程号 cu | 查看某个进程的cpu消耗排序 | ||
cat /proc/cpuinfo |grep ‘processor’|wc -l | 查看cpu核数 | ||
top | 查看cpu总体消耗,包括分项消耗如user,system,idle,nice等消耗 | ||
top 然后shift+h:显示java线程,然后shift+M:按照内存使用进行排序;shift+P:按照cpu时间排序;shift+T:按照cpu累计使用时间排序
多核cpu,按“1”进入top视图 | |||
sar -u 3(间隔时间) | 查看cpu总体消耗占比 | ||
sar -q | 查看cpu load | ||
top -b -n 1 | awk ‘{if (NR<=7)print;else if($8==”D”){print;count++}}END{print “Total status D:”count}’ | 计算在cpu load里面的uninterruptedsleep的任务数量 | uninterruptedsleep的任务会被计入cpu load,如磁盘堵塞 | |
网络瓶颈 | cat /var/log/messages | 查看内核日志,查看是否丢包 | |
watch more /proc/net/dev | 用于定位丢包,错包情况,以便看网络瓶颈 | 重点关注drop(包被丢弃)和网络包传送的总量,不要超过网络上限 | |
sar -n SOCK | 查看网络流量 | ||
netstat -na|grep ESTABLISHED|wc -l | 查看tcp连接成功状态的数量 | 此命令特别消耗cpu,不适合进行长时间监控数据收集 | |
netstat -na|awk’{print $6}’|sort |uniq -c |sort -nr | 看tcp各个状态数量 | ||
netstat -i | 查看网络错误 | ||
ss state ESTABLISHED| wc -l | 更高效地统计tcp连接状态为ESTABLISHED的数量 | ||
cat /proc/net/snmp | 查看和分析240秒内网络包量,流量,错包,丢包 | 用于计算重传率tcpetr=RetransSegs/OutSegs | |
ping ip | 测试网络性能 | ||
traceroute ip | 查看路由经过的地址 | 常用于定位网络在各个路由区段的耗时 | |
dig 域名 | 查看域名解析地址 | ||
dmesg | 查看系统内核日志 | ||
磁盘瓶颈 | iostat -x -k -d 1 | 详细列出磁盘的读写情况 | 当看到I/O等待时间所占CPU时间的比重很高的时候,首先要检查的就是机器是否正在大量使用交换空间,同时关注iowait占比cpu的消耗是否很大,如果大说明磁盘存在大的瓶颈,同时关注await,表示磁盘的响应时间以便小于5ms |
iostat -x | 查看系统各个磁盘的读写性能 | 重点关注await和iowait的cpu占比 | |
iotop | 查看哪个进程在大量读取IO | 一般先通过iostat查看是否存在io瓶颈,再定位哪个进程在大量读取IO | |
df -hl | 查看磁盘剩余空间 | ||
du -sh | 查看磁盘使用了多少空间 | ||
应用瓶颈 | ps -ef | grep java | 查看某个进程的id号 | |
ps -ef | grep httpd| wc -l | 查看特定进程的数量 | ||
cat ***.log | grep ***Exception | wc -l | 统计日志文件中包含特定异常数量 | ||
jstack -l pid | 用于查看线程是否存在死锁 | ||
awk’{print $8}’ 2017-05-22-access_log|egrep ’301|302′| wc -l | 统计log中301、302状态码的行数,$8表示第八列是状态码,可以根据实际情况更改 | 常用于应用故障定位 | |
grep ‘wholesaleProductDetailNew’ cookie_log | awk ‘{if($10==”200″)}’print}’ | awk ‘print $12′ | more | 打印包含特定数据的12列数据 | ||
grep “2017:05:22″ cookielog | awk ‘($12>0.3){print $12 “–” $8}’ | sort > 目录地址 | 对apache或者nginx访问log进行响应时间排序,$12表示cookie log中的12列表示响应时间 | 用于排查是否是由于是某些访问超长造成整体的RT变长 | |
grep -v ‘HTTP/1.1″ 200′ | 取出非200响应码的URL | ||
pgm -A -f 应用集群名称 “grep “’301 ‘ log文件地址 | wc -l | 查看整个集群的log中301状态码的数量 | ||
ps -efL | grep [PID] | wc -l | 查看某个进程创建的线程数 | ||
find / -type f -name “*.log” | xargs grep “ERROR” | 统计所有的log文件中,包含Error字符的行 | 这个在排查问题过程中比较有用 | |
jstat -gc [pid] | 查看gc情况 | ||
jstat -gcnew [pid] | 查看young区的内存使用情况,包括MTT(最大交互次数就被交换到old区),TT是目前已经交换的次数 | ||
jstat -gcold | 查看old区的内存使用情况 | ||
jmap -J-d64 -dump:format=b,file=dump.bin PID | dump出内存快照 | -J-d64防止jmap导致虚拟机crash(jdk6有bug) | |
-XX:+HeapDumpOnOutOfMemeryError | 在java启动时加入,当出现内存溢出时,存储内存快照 | ||
jmap -histo [pid] | 按照对象内存大小排序 | 注意会导致full gc | |
gcore [pid] | 导出完成的内存快照 | 通常和jmap -permstat /opt/**/java gcore.bin 一起使用,将core dump转换成heap dump | |
-XX:HeapDumpPath=/home/logs -Xloggc:/home/log/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps | 在Java启动参数中加入,打印gc日志 | ||
-server -Xms4000m -Xmx4000m -Xmn1500m -Xss256k -XX:PermSize=340m -XX:MaxPermSize=340m -XX:+UseConcMarkSweepGC | 调整JVM堆大小 | xss是栈大小 |
r/s + w/s: 就是当前的IOPS #### (93+0=93)
avgrq-sz:平均每次设备I/O操作的数据大小(扇区)#### (248.0)
avgqu-sz :平均I/O队列长度 ####(0.10)
await:请求队列中等待时间+svctm(服务时间) 单位是毫秒,按照每次IO平均。####(1.06)
The average time (in milliseconds) for I/O requests issued to the device to be served.
This includes the time spent by the requests in queue and the time spent servicing them.
svctm:平均每次设备I/O操作的服务时间(毫秒) ####(1.06)
svctm已经被官方注明不可信,仅供参考.因为iostat各值基本都是计算出来的,而svctm计算方法存在错误的地方
The average service time (in milliseconds) for I/O requests that were issued to the device.
Warning! Do not trust this field any more. This field will be removed in a future sysstat version.
iostat -x 磁盘分析
%util: (bandwidth utilization for the device)平均有百分之多少的时间用于I/O操作,或者说有多少时间I/O队列是非空的###(9.90)
如果%util接近100%,表明I/O请求太多,I/O系统已经满负荷,磁盘可能存在瓶颈,一般%util大于70%,I/O压力就比较大,读取速度有较多的wait。
注意:如果存储设备是RAID或SSD之类的,这个说法已经不准确了
可以结合vmstat查看查看b值(等待资源的进程数)和wa值(I/O等待所占用的CPU时间的百分比,高过30%时I/O压力高)
Percentage of elapsed time during which I/O requests were issued to the device (bandwidth utilization for the device).
Device saturation occurs when this value is close to 100% for devices serving requests serially.
But for devices serving requests in parallel, such as RAID arrays and modern SSDs, this number does not reflect their performance limits.
avgqu-sz:(队列长度)可作为衡量系统I/O负荷的指标, 超过处理能力的请求数目,待处理的 I/O 请求,当请求持续超出磁盘处理能力,该值将增加。
但由于avcqu-sz是按照单位时间的平均值,所以不能反映瞬间的I/O洪水。应结合参考svctm.以及r/s及w/s。
svctm的大小一般和磁盘性能有关,CPU/内存的负荷也会对其有影响,请求过多也会间接导致svctm的增加。
await的大小一般取决于服务时间(svctm)以及I/O队列的长度和I/O请求的发出模式。
如果await比较接近svctm,说明I/O几乎没有等待时间;如果await远大于svctm,说明I/O队列太长,应用得到的响应时间变慢,
如果响应时间超过了用户可以容许的范围,这时可以考虑更换更快的磁盘,调整内核elevator算法,优化应用,或者升级CPU