大家好，我是mars先生的小量子！今天minmin忙于空手道训练，无暇顾及本周的推送，只能由我来紧急救场了。最近处理了几个客户反馈的bug，搞得我头疼不已，借此机会分享一下我处理这些问题的经历。
说起来，我之前在爱奇艺工作时，经常处理内部同事的Trouble Shooting问题。那时的客户都是公司内部的同事，程序也部署在公司的服务器上，我们有服务器的root权限，Trouble Shooting起来非常方便。首先，复现问题非常容易，因为客户出bug的环境就是我们自己的环境，其次可以使用各种linux和jvm的调试工具。
自从来到PingCAP之后，现在的客户都是外部公司的开发人员，程序都部署在对方公司的机房。条件好的客户会给我们开一个远程界面，可以远程操作；条件不好的连一个Error Stack也拷贝不出来，只能拍个模糊的照片发给我们，真是让人头疼~~
本文主要分享一下我在PingCAP处理的一些Trouble Shooting案例。
01
文件权限问题
某天，一个客户告诉我他们无法读取数据。于是我开始了一整个下午的Trouble Shooting之旅，首先获取了客户的远程控制权限。
- 确认版本 => 没有问题
- 检查配置是否正确 => 没有问题
- 查看日志 => 没有异常
- ...
尽管检查了所有可能的原因，但就是无法读取数据。最后无意中发现tispark的jar包在linux上的权限设置有误，导致提交spark任务的用户没有权限读取。
原来，客户是手动将tispark的jar包拷贝到安装目录的，但用的linux用户不对。
02
分布式集群版本不一致
又有一天，一个客户告诉我出现了错误。
根据以往经验，这个错误通常是由于在分布式集群上使用了两个不同版本的jar包，在序列化和反序列化时会检测到前后类不一致，从而抛出错误。再加上用户提到是集群升级后出现的错误，基本可以确定用户在升级时没有替换所有的jar包，或者某些进程没有重启。
让客户自己排查一下，果然证实了我的猜测。
03
版本需要升级
又有一天，一个客户告诉我出现了错误。
这个Error Stack看起来有点眼熟，好像是之前修复过的一个bug。询问了一下客户使用的版本，果然是比较老的版本。让客户升级到最新版，问题就解决了。
04
第三方库内存泄漏
又有一天，一个客户告诉我出现了错误。
经调查发现，tispark和tikv通讯时使用了GRPC，而GRPC底层使用netty进行通讯。这个错误表明是由于netty在通讯时需要申请native memory，而错误是由于native memory不足导致的。
让客户将内存从1G调大到8G后，之前无法运行的任务可以顺利运行。
几天后，客户又告诉我出现了新的错误。
我初步怀疑问题的本质原因是netty有内存泄漏。尝试在本地复现失败，只能到客户现场获取heap dump回来分析。
最后，我发现19个PoolChunk对象，每个16M，总共占用了约304M的内存。
PoolChunk对象被PoolThreadCache引用，因此怀疑是Netty的PoolThreadCache机制导致的内存无法释放。
为了验证这个猜想，我们让客户添加了这个参数
-Dshade.io.netty.allocator.type=unpooled
也就是说让Netty禁止使用Memory Pool，发现客户的程序可以正常运行。
大家好，我是训练完之后回家帮Mars调整微信文章格式的HelloMin。看完他的文章，我突然有种老公其实是客服的幻觉？说好的数据库高级工程师呢？微信每次都不回我，原来都在和客户聊天？？？
钱不好挣啊~
Schönes Wochenende!
我的2019周更计划已完成：39/52
[************......]
