综合篇看了小一半，综合篇的案例明显更加贴近实际。往往一个问题并不是只有一个原因导致的！

下面小结几个重要的点。

容器

• 如果使用容器，那么需要一开始就限制 CPU 和内存的使用，不要让单个容器的内存占用影响整个宿主机上所有的其他容易
• 同时不要忘记，这样的限制往往会导致应用在有些时候出现异常和崩溃，特别是对于内存本身就有要求的应用，分配一个合理的限制很关键

通过 docker logs 可以查看当前容器产生的日志

通过 docker inspect 可以查看当前容器的情况和配置，并通过 State 来确定容器退出情况和退出错误原因

丢包

• 有的时候丢包并发完全应网络原因导致
• 当请求量过大，而相关队列有限制大小的时候，linux 会主动丢弃一些请求，也会导致丢包
• 千万不要忘记还有iptables这个，因为很多规则的配置往往就影响到了网络的通信状况

netstat -s
可以看到所有网络情况
netstat -i 
可以看到网卡情况
iptables -t filter -nvL
可以看到 iptables 的转发情况和策略

现实情况下，还没有遇到出现大量网络的丢包的情况，这个问题查起来也挺难的

perf

• 火焰图中主要看深度和长度
• 长度表示占用 cpu 时间更多
• 深度表示调用堆栈越深

perf record -a -g -p 9 -- sleep 30

其实我实际中 看 go 的 pprof 更加多一点，从程序的角度中更加能说明问题

内核线程

• 个人认为，就目前来说，直接通过内核线程去判断问题可能还早一些，因为内核线程很多，即使你知道它是做什么的，但是真实原因往往无法直接确定
• 还是优先能通过性能指标判断来的更加准确
• 或者 strace 直接查看系统调用会显得更加容易判断当前是由于什么调用导致的瓶颈