第三章<实际系统的性能分析>
应用服务
像web服务，应用服务这种一般是有access log的，会包括访问路径url，method，time，httpStatus等信息，所以可以通过监控和汇总这些信息可以得知应用系统的性能状况。
监控系统一般是会触发告警的。比如“死亡”钉钉，企业微信，短信，邮件等。然后就可以上去查看日志，通过分段定位法来时间分段，位置分段定位，这个过程可以使用一些性能工具(top，ps，vmstat，iostat，free，netstat，perf)等来查看概要信息，事件信息，快照信息。
像java这种是提供一些自带工具的jstace，Jconsole，同时应该着重查看GC日志。又比如golang，通过pprof也可以很好的进行性能分析和问题排查。
性能监控包括：
- 基础监控：cpu，网络，硬盘，内存，中断信息，负载变化等
- 服务监控：jvm，服务端口，接入上下游服务的超时监控等
- 业务监控：业务状态码，业务流程等
不管什么系统，性能分析都应该包括队列和线程，线程池，连接池等。
DB服务
在以上的基础监控除外，还需要对会话，sql语句，慢日志等监控。
数据库是数据处理较集中的服务，因此可能会有锁的开销，因此锁信息也是要监控分析的。
DB性能分析示意图
DB数据库性能分析
DB服务的性能调优可以从以下方向入手：
- 响应时间：从发出请求到返回响应为止的时间
- IOPS：物理磁盘每秒能处理的次数
- 吞吐：对每个处理的应答
- 缓存命中率：在总的处理次数中，通过缓存进行处理的次数占总处理次数的比例，越高越好
- 脏数据：已经更新但还没刷如磁盘的数据。
磁盘与IOPS的示意图：
磁盘性能达到最大就是尽量达到最大的IOPS的最大值，同时可以通过多个RAID拼成一块的大逻辑磁盘来对外工作，相当于把磁盘io分片到多个物理磁盘上。
单块磁盘存储性能的分析思路：
单块磁盘先查看磁盘利用率和队列等待数量
多块磁盘组成逻辑磁盘的性能分析思路：
磁盘使用率和IO次数不是绝对的评判标准。实际使用的一个指标是响应的恶化程度。根据等待队列理论，负载越大，等待队列越多请求，等待的时间越长。
IO与缓存导致性能降低。脏数据块导致缓存满了，造成缓存空间不足，会导致写入性能非常缓慢。
网络性能分析
书中重点指出了TCP的滑动窗口，ACK机制，MSS，MTU。但是详细的没有说，比如流量控制，拥塞控制(慢启动，拥塞避免，快速重传，快速恢复)等没有进一步介绍。
一个请求包在网络中是经过了n级的跳转的，所以在任何一级都可能产生网络问题。
网络问题包括：
- 请求包大小引起的分片，或者粘包
- 网络距离遥远，请求延迟
- 网络跳级过程中的不稳定，丢包
这些都会造成网络问题，性能问题。
容易掉进去的陷阱
- 关注受害者：重要的是找出谁引出的，而不是性能出现的地方。一般是用过事假形式信息和快照形式信息得到。在同一时间出现的可疑者就是嫌疑犯。若和可疑者的特征对上就是真凶了。
- 没有意识到基础不稳：先排除基础设备的问题，比如jvm的GC会引起API变慢，os变慢会引起sql变慢等。
- 没有意识到负载的变化：根据等待队列理论，负载增加，等待时间就更加。而概要形式分析是汇总和平均，可能会掩盖真实的数据
- 不能确定谁“拿球”：在协作式（分布式系统）中，出现延迟问题，要先确定属于哪个系统的问题。思路是找出 时间上空着的地方，然后调查在那之后是怎么交互的，一般就知道是属于哪个系统的问题了。带时间戳的事件形式信息可以帮助排查分析问题。
- 不能确定因果关系：性能问题很多，内存减少，CPU暴涨，IO增加，处理数量增加等等。不能确定因果关系，就会胡乱尝试找问题，浪费时间。所以要先确定因果关系。
DB服务器的分析流程
小结
第三章主要从应用服务，数据库服务，网络三个方面来介绍怎么做性能分析。要对操作系统，基本的设备的特定了解才能做好更好的判断。
