记一次多线程溢出问题

解决问题也是会上瘾的。
按照惯例，先抛问题。

问题

我们线上环境，重新部署了数据处理流程的项目，但是，没过几天，大数据平台开始不正常了。表现出来的现象就是，ambari-agent节点失联，其他组件的节点挂了（hbase，hdfs），总之是各种预警。因为我是这边大数据的开发兼职运维（很惨），线上平台出现问题，赶紧去看了一波，系统性能，没问题。节点日志（后来看部分节点日志暴露了问题，所以日志真的很重要），也没查出什么问题。当时是真急，也是真惨，同时在该线上环境出现的还有其他任务的问题，比如es，redis这些特别慢。我们一直怀疑是该线上机器有问题，当然，现在发现，其实这批线上机器的很多配置不是我们配置的，确实是存在一些问题。我毕竟也不是运维出生，找运维查看，给的答案是没问题。没办法只能自己解决。

解决流程

很无奈，公司人手不够，干大数据开发的只有我一个，我不能将精力和时间都放在了该线上环境。只能先这么盯着，三天两头的这个大数据平台就出问题。一直到了前段时间，ambari节点又挂了，我刚好有些时间，在次查看了日志，发现了一个error（Connection to hdp1 was lost (details=can’t start new thread)，刚好自己也有点印象，当yarn上的任务也出现了一个(Exception in thread “main” java.lang.OutOfMemoryError: unable to create new native thread)类似的问题。心里猜测，这应该不是巧合。于是就去查了服务器线程相关的东西，并且通过和运维人员交谈也了解到，该环境的配置不是我们配置（因为服务在开发，测试和另外一个线上平台都部署了，并没有出现这个问题，所以当时是怀疑对象就是环境问题）。然后去查看了相关线程的配置。这里附上一个链接浅谈系统线程数限制。并且用该环境的配置和其他环境的做了对比，果然发现kernel.pid_max参数不一致，该参数在其他环境配的是655350，该环境的为32768。使用pstree -p|wc -l 查看，发现部分大数据节点的机器线程数据确实很高，并且是不断增大的。为了验证自己的想法，我写了一个脚本，结合crontab定时监控着线程数，并且为了查到罪魁祸首的进程，使用ps -Lf pid | wc -l 命令打印了具体每个进程的线程数。终于找到了具体的进程。以大数据任务了的进程，该进程主要的任务是去kafka读取数据，hbase读取数据，调用算法，最后写数据到es。最后发现是调用算法流程中启用了多线程没有关闭，而任务是spark stream任务，就是说，每一批任务过来都会启动一波线程，但是不关闭。所以线程就一直增加。

总结

该问题主要是方面，第一是服务器参数配置问题。这也是造成该问题难以排除的原因。多个环境配置不一致，其他环境任务执行的很正常（当然还是会出现，只是因为周期较长，所以没关注），该环境频繁的出现了。第二个就是程序问题，多线程没有一个关闭的过程