MarsTalk | Trouble Trouble Shooting

大家好，我是mars先生的小量子！今天minmin忙于空手道训练，无暇顾及本周的推送，只能由我来紧急救场了。最近处理了几个客户反馈的bug，搞得我头疼不已，借此机会分享一下我处理这些问题的经历。

说起来，我之前在爱奇艺工作时，经常处理内部同事的Trouble Shooting问题。那时的客户都是公司内部的同事，程序也部署在公司的服务器上，我们有服务器的root权限，Trouble Shooting起来非常方便。首先，复现问题非常容易，因为客户出bug的环境就是我们自己的环境，其次可以使用各种linux和jvm的调试工具。

自从来到PingCAP之后，现在的客户都是外部公司的开发人员，程序都部署在对方公司的机房。条件好的客户会给我们开一个远程界面，可以远程操作；条件不好的连一个Error Stack也拷贝不出来，只能拍个模糊的照片发给我们，真是让人头疼~~

本文主要分享一下我在PingCAP处理的一些Trouble Shooting案例。

01

文件权限问题

某天，一个客户告诉我他们无法读取数据。于是我开始了一整个下午的Trouble Shooting之旅，首先获取了客户的远程控制权限。

1. 确认版本 => 没有问题
2. 检查配置是否正确 => 没有问题
3. 查看日志 => 没有异常
4. ...

尽管检查了所有可能的原因，但就是无法读取数据。最后无意中发现tispark的jar包在linux上的权限设置有误，导致提交spark任务的用户没有权限读取。

原来，客户是手动将tispark的jar包拷贝到安装目录的，但用的linux用户不对。

02

分布式集群版本不一致

又有一天，一个客户告诉我出现了错误。

根据以往经验，这个错误通常是由于在分布式集群上使用了两个不同版本的jar包，在序列化和反序列化时会检测到前后类不一致，从而抛出错误。再加上用户提到是集群升级后出现的错误，基本可以确定用户在升级时没有替换所有的jar包，或者某些进程没有重启。

让客户自己排查一下，果然证实了我的猜测。

03

版本需要升级

又有一天，一个客户告诉我出现了错误。

这个Error Stack看起来有点眼熟，好像是之前修复过的一个bug。询问了一下客户使用的版本，果然是比较老的版本。让客户升级到最新版，问题就解决了。

StickerBaker

免费开源的AI贴纸头像生成工具

157

查看详情

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

[************......]

以上就是MarsTalk | Trouble Trouble Shooting的详细内容，更多请关注php中文网其它相关文章！