关于系统性能优化涉及的内容非常多，我会分几篇文章来分享，这次分享下定位系统层面问题的常用方法。
系统性能定义
Throughout 吞吐量 （系统每秒钟可以处理的请求数）
Latency 延迟 （系统处理一个请求的延迟）
Usage 资源利用率
吞吐量和延迟的关系
吞吐量越高，延迟会越大。因为请求量过大，系统太繁忙，所以响应时间会降低。
延迟越小，能支持的吞吐量会越高。因为延迟短说明处理速度快，就可以处理更多的请求。
异步化可以提高系统的吞吐量的灵活性，但是不会获得更快的响应时间。
系统性能压测的常用工具
tcpdump
1. 常用参数：
2. 示例
如果想使用wireshark分析tcpdump的包，需要加上是 -s 参数：
tcpcopy——线上引流压测
tcpcopy是一种请求复制工具，用于实时和离线回放，它可以将线上流量拷贝到测试机器，实时模拟线上的真实环境，达到程序不上线的情况下承担线上真实流量的测试。实战演习的必备工具。
a. tcpdump录制pace文件
b. 流量回放
c. 引流模式
wrk & ApacheBench & Jmeter & webbench
个人非常推荐wrk，轻量且压测结果准确，结合Lua脚本可以支持更复杂的测试场景。
压测示例：4个线程来模拟1000个并发连接，整个测试持续30秒，连接超时30秒，打印出请求的延迟统计信息。
更多参数帮助信息：
定位性能瓶颈
可以从以下几个方面衡量系统的性能：
应用层面
系统层面
JVM层面
Profiler
应用层面
应用层面的性能指标：
QPS
响应时间，95、99线等。
成功率
系统层面
系统层面指标有Cpu、内存、磁盘、网路等，推荐用一个犀利的命令查询系统性能情况：
dstat -lcdngy
dstat非常强大，可以实时的监控cpu、磁盘、网络、IO、内存等使用情况。
安装方法
yum install -y dstat
功能说明
Cpu
使用率：Cpu是最重要的资源，如果CPU在等待，也会导致Cpu高使用率。
CPU利用率 = 1 - 程序占用cpu时间/程序总的运行时间
用户时间/内核时间：大致判断应用是计算密集型还是IO密集型。
CPU花在用户态代码的时间称为用户时间，而执行内核态代码的时间称为内核时间。内核时间主要包括系统调用，内核线程和中断的时间。当在整个系统范围内进行测量时，用户时间和内核时间之比揭示了运行的负载类型。计算密集型应用会把大量时间花在用户态代码上，用户时间/内核时间之比接近99/1。这样的例子有图像处理，数据分析等。I/O密集型应用的系统调用频率较高，通过执行内核代码进行I/O操作。一个进行网络I/O的Web服务器的用户/内核时间比大约为70/30。
负载load：在特定时间间隔内运行队列中的平均进程数。每个CPU都有一个运行队列，队列里存放着已经就绪，等待被CPU执行的线程。理想状态下，希望负载平均值小于等于Cpu核数。
Cpu使用率和load的区别：
负载均值用来估量CPU利用率的发展趋势，而不是某一时刻的状况。
负载均值包括所有CPU的需求，而不仅仅是在测量时活跃的。
磁盘
磁盘空间：没有空间会导致程序无法启动或者报错。
有时候linux服务器的系统日志文件过大导致磁盘使用率过高，推荐两种清理方式：
磁盘权限：没有权限会导致程序无法启动或者报错。
磁盘性能测试
io吞吐、iowait
这里重点说下这两个因素，大量的磁盘读写以及过高的iowait往往意味着磁盘可能是瓶颈。实际上iowait并不能反映磁盘成为性能瓶颈，它实际测量的是cpu的时间：
所以唯一定位磁盘成为性能瓶颈的直接方法还是看read/write时间。下面我们着重介绍下如何定位io问题。
a. 宏观确定是否是io的问题：top命令，可以从Cpu这一行看出浪费在I/O Wait上的CPU百分比；数值越高代表越多的CPU资源在等待I/O权限。
b. 确定具体磁盘问题：iostat
%util直观地反应可哪一块磁盘正在被写入，反应了设备的繁忙程度。每毫秒读写请求(rrqm/s wrqm/s)以及每秒读写(r/s w/s)对排查问题也提供了很多有用的信息。
c. 确定具体进程：简单粗暴的iotop直观地反映了哪些进程是导致io问题的罪魁祸首。
d. ps判断进程是否等待IO一样强大
众所周知，ps命令为我们提供了内存、cpu以及进程状态等信息，根据进程状态可以很容易查到正在等待IO的进程信息。
这里简单说下linux进程的几种状态：
R (TASK_RUNNING)，可执行状态。
S (TASK_INTERRUPTIBLE)，可中断的睡眠状态。
D (TASK_UNINTERRUPTIBLE)，不可中断的睡眠状态。
T (TASK_STOPPED or TASK_TRACED)，暂停状态或跟踪状态。
Z (TASK_DEAD – EXIT_ZOMBIE)，退出状态，进程成为僵尸进程。
X (TASK_DEAD – EXIT_DEAD)，退出状态，进程即将被销毁。
其中等待I/O的进程状态一般是"uninterruptible sleep"即D状态，D状态以及R状态进程算为运行队列之中，所以D状态进程过多也会导致系统load偏高，有兴趣可以看下linux load的计算原理。
查看D状态进程：
根据proc伪文件系统获取io相关信息：
e. 确定哪个文件频繁读写：lsof -p pid
网络
1. nestat
netstat -nt 查看tcp相关连接状态、连接数以及发送队列和接收队列
关于tcp的状态需要大家熟悉三次握手和四次挥手的过程，这里先列出tcp的全部状态。
Tcp状态变化图（摘自网络）：
关于tcp状态的几点说明：
正常的连接应该是ESTABLISHED状态，如果存在大量的SYN_SENT的连接，则需要看下防火墙规则。
如果Recv-Q或者Send-Q持续有大量包存在，意味着连接存在瓶颈或者程序存在bug。
2. 一些其他常用技巧
关于netstat还有很多有用的技巧，这里列出平时比较常用的：
JVM
定位问题的杀手锏——线程堆栈
1. 获取线程堆栈的步骤：
小技巧：jstack信息是某个时刻的堆栈信息，有时间仅仅一个jstack并不能分析出问题所在，可以适当多几次jstack，然后进行对比分析。
2. 如何从线程堆栈中找到本地线程对应的id
nid=native thread id，特殊的是nid使用十六进制标识，本地线程id是十进制标识，所以通过进制换算就可以讲两者对应起来。
16进制和10进制的互换：
3. Cpu消耗高的分析方法
a. 找出对应的java进程pid：
b. 找出java进程中最消耗cpu的线程：
将找出的线程id转换为16进制
jstack获取java的线程堆栈
根据16进制的id从线程堆栈中找到相关的堆栈信息
说明：线程堆栈中可以看出对应线程执行的是Java代码还是Native method
找不到对应的线程堆栈？
执行的Native method是重新创建的线程。
代码bug，堆内存耗完，jvm不断执行full gc。
jvm自身bug😂。
垃圾收集的统计信息——查看Gc原因
jstat -gccause用于查看垃圾收集的统计信息，若有发生垃圾回收，还会显示最后一次以及当前发生垃圾回收的原因，它比-gcutil会多出最后一次垃圾回收的原因以及当前正在发生的垃圾回收的原因。
网友评论