故障排查与性能优化

服务雪崩，听到这个词就能想到问题的严重性。是的，整个项目，整条业务线都挂了，从该业务线延伸出来的下游业务线也跟着凉了。

项目不断新增需求，难免不会出现问题，特别是近期新增的增加请求处理耗时的需求。以及一些配置的修改而忽略掉的问题，如dubbo工作线程数调增时，忽略了redis连接池的修改。由于redis可用连接远小于工作线程数，就会出现多个线程竞争redis连接，影响性能。

线上某服务一直运行很稳定，最近突然就`cpu`百分百，`rpc`远程调用全部失败，并走了`mock`逻辑。重启后，一个小时后问题又重现。于是`dump`线程栈信息，但不仔细看也看不出什么问题。于是就有了一番排查历程。

对于线上应用，出现进程自动挂掉的原因，如果可以排除因程序本身原因，那么很大可能性是因为操作系统内存不够用，进程被操作系统kill掉了。

基于go提供的基准测试能力编写并发测试用例，为排除脚本本身的性能影响，脚本只实现简单的逻辑，并实现预编译。通过调整虚拟机池策略、cpu数、并行度等，输出调用lua脚本的平均耗时、占用的内存。

业务使用我们基础部门封装的kafka组件，在一次版本迭代中，我们引入了offset缓存，正是这个缓存，在某种条件触发下，会导致出现消息重复消费现象。

moosefs没有关于底层自定义二进制通信协议的文档，且各大版本api上差异很大。我们在github上找到一个go语言实现api操作moosefs的开源库，但不幸的是，这个组件实现的api版本很低，在测试阶段，我们发现上传文件到moosefs后，moosefs上存储的文件的md5与本地原文件md5不一致，如果是图片，能很明显的看出少了一块像素。

业务反馈有个iOS设备上传出现403问题，打点日记只能看到403，没有详细的错误信息。开了s3的日记后，也只是看到403 AccessDenied。

自研实现文件上传下载的中间件在测试阶段发现断点续传有问题。具体表现是：使用wget下载mp4文件可以正常播放，用google浏览器打开链接，google浏览器无法正常播放mp4视频。

用go开发的一个文件上传中间件，由于依赖了ceph这个c库，早期通过pprof排查，怀疑内存泄露在c层，而项目依赖ceph，于是就怀疑是ceph的问题。但通过使用jemalloc排查后，并未发现ceph有什么异常。最后使用最笨的方法，定位到github.com/chai2010/webp库存在内存泄露bug。

上传的文件是仅办公网络可访问，办法室网络有带宽限制，一个页面加载上百张图片，很容易达到带宽限制，所以出现下载很慢。

只因请求头deviceId多了一个‘\n’导致，服务端接收到的body是空的。

因为go标准库实现tls握手性能比较差，在一台8核的机器，只能到达2000这个量级，所以当到达某个临界点的时候，握手占用CPU过高，反过头来影响正常的业务请求，导致了业务请求处理变得十分慢。

记录一次工作中实战的Java内存泄漏问题排查，Pod重启后无法查看现场，但通过gc日记可以确认存在内存泄露，并通过运行一段时间发现有个Java类的实例数量非常高。

了解网络协议、学会利用tcpdump抓包，学会利用Wireshark分析数据包，将能帮助我们解决一些仅从客户端日记分析或仅从服务端日记分析无法解决的疑难杂症。本篇结合笔者经历的一些实战案例，带大家掌握网络问题排查必备技能：tcpdump抓包分析。

代码中，与tls有关的地方就是发送https请求从s3下载文件，所以检查下载文件调用链路上是否存在可疑的内存泄漏，发现如下疑点。统计了访问日记，发现确实经常出现响应403。所以问题就清晰了，由于403是有body的，没有close响应的body导致的内存泄漏。

据业务反馈，AI生成图片上传后，首次立即下载耗时可能需要几秒，且出现概率极大，很容易复现。如果是上传后，过个几秒后再下载，耗时则只需要几百毫秒。

所以，这个案例的用途是：在read函数调用之前，记录时间戳，在read函数return前计算方法执行耗时，将结果保存到`us`全局变量。使用`@`声明的全局变量，会在bpftrace脚本进程结束时输出到控制台。

难题一：上传MFS文件MD5不一致；难题二：疑是go-ceph导致的内存泄漏；难题三：ceph文件首次下载慢。