Alluxio异常排查二
接着上篇，保险客户的问题。
问题分析
负责这个客户的研发，突然有一天找我说，客户卡死的问题需要看一下。好在客户可以 dump 线程状态出来的。从客户那边 dump 了5个线程快照，每个间隔2秒。可是从 dump 的线程状态上，并没有发现有卡死的线程存在，每个线程做的事情在下一个 dump 文件都会变化。无从下手，于是我再次尝试还原问题，可是这次没有成功。尝试多次都以失败告终。 但是，有一点可以确定的，肯定还是线程锁定问题，因为从 dump 中看到快照中多数线程在等待锁。因此我们给客户打了一个补丁，定期清空 MEM 空间的内容。这个做法的确有效果，但是问题没有根本解决。 这时候手中唯一的信息就是5 dump 文件了。于是我找了2个同事，我们结合着代码和 dump 文件，进行了一次代码会议。
- 首先确定客户卡顿的时候，有大量数据再向 MEM 中写入。同时有大量读取到计算操作
- 数据导入操作没有问题，没有 netty 超时。这让我们预先排除类似国税客户的肯能性。
- dump 中没有线程卡死的。
- dump 中绝大多数都是在等待锁，这一点很关键。我们推断应该有线程在等待锁。
- 所有我把 dump 中全部等待的地方都做了一次代码 review。
最终发现问题竟然和税务客户的问题发生是同一个地方，但是不同的问题，情况比较复杂，这是一个 bug。
- 系统非常繁忙，大量写入操作占据了 MEM 的大多数空间，读取操作需要从 HDD 将数据 promote 到 MEM 中。
- 这种情况下read 操作需要先从 MEM 换出一部分 block 后，再把需要读取到 block promote 到 MEM 中。
- 在做换出操作的时候，需要给 block 上写锁。
- 此时这个锁是非公平锁，也就是说不保证先到先得。
- 由于写锁是独占锁，而读锁是共享锁。
- 导致线程上写锁非常困难。因为这个 block一直有读取的操作存在，那么上写锁的线程一直等待。
- 但是注意，这个写锁是可以获取成功的，只是缓慢。慢多少，依据读取情况，如果一直有读取到存在，那么等价与饥饿到卡死。
- 更重要的是一个文件缓慢影响不大，但是一个操作涉及很多文件就会表现出卡死的现象。因为计算涉及很多文件。而导入数据都是一个个文件，因此计算会卡住，而写入正常。
解决方案
Trylock
我们增加了 trylock 的方法可以缓解资源竞争的情况。但是无法彻底解决这个问题。 设想一种极端的情况。MEM 中的 block 一直被读取，那么其它任何读取HDD 的操作的 promote 将永远失败。 目前 trylock 代码已经提交社区，但是一直没有 merge，这部分代码很核心并且有些年老，和社区沟通，他们也觉得需要进行重构。
减少 MEM 的压力
如下图所示，我们彻底改变了我们对于 Alluxio 的使用模式。
正如在上一篇排查一开头所说的，我们非常依赖和信任 Alluxio 的 MEM。这里问题的根源在于太过于依赖 MEM 了。导致 MEM 的压力太大，同时这部分代码的鲁棒性还不足，在大压力的情况下就会出现很多问题。因此我们做了下面的改动
- 将持久数据的写操作直接搬离 Alluxio
- 将临时数据的写操作放到 HDD 层
- 将 MEM 留给计算
- 数据首次，从 UFS 拉取到 MEM 中
- 增加一个promote 控制组件。只有达到热点标准的数据再被拉取到 MEM 中，这样避免反复的换入换出。
总结
- 之所以遇到问题，是由于前期缺少充分的压力测试。而难以解决问题，是因为对于代码不够了解。
- 以后不管是第三方工程，还是引入的框架工具，只有是核心依赖的，必须要彻底搞清楚。
- 代码审核会议非常有用