Spark&Mysql bug分析

Spark&Mysql bug分析

今天在看到spark与mysql结合使用文档，想起来去年年底处理的一个bug。

bug：

“Can not connect to MySQL server. Too many connections”
在运行一段时间后，出现这个问题。之前解决方案是临时重启mysql。。。。。。。
后面这个问题就交给了我。。。。。。。

解决步骤：

1.确定方向：查看服务器数据库设置的最大连接数，发现是100。

2.问题再现：再模拟同时多次数据库操作，同时使用JProfiler工具观察，发现connection对象非常大。

3.着手解决：查看代码，发现mysql连接是开发人员封装的utils。怀疑是工具类中的conn未正确关闭；

4.解决测试：使用已有的c3p0连接池替换utils。并模拟问题测试，不再出现。

5.发现问题：虽然不再出现Too many connections，但发现有的spark job速度明显的慢了许多。

问题优化：

1.分析业务逻辑，查看mysql，发现共有6个database，共有500张左右table，与spark相关table大约有300左右table。大部分数据为1s接受一次，综合来看，先将最大连接数修改为1200，并增大open_files_limit值。
2.查看mysql慢查询日志并结合之前的bug，发现有3条sql语句较慢，有的甚至长达10s左右。合理规划慢sql索引，合理修改sql语句。避免慢查询出现。
3.将代码中foreach循环写入mysql修改为foreachPartitions写入（也就是批量写入mysql）   。

总结：

1.项目中尽量使用已成熟的技术，减少自己封装代码的使用。
2.需结合业务合理使用mysql。

问题发现：

刚刚提到有的spark job变慢了。
1.查看已提交代码，未发现spark代码有太大的变化。
2.询问，老员工，得知设备数量增加多台。
3.和老员工一起进行业务分析，得出数据量大概增加了40%左右。
4.那么数据量变大了，为什么有的spark job会比之前慢了许多了。
5.查看系统的CPU利用率，发现有的节点很低。
6.增加partition数，以及executor数量。
7.持续观察一周，性能有所改善。

优化：

适当减少executor占用的CPU core数。
增加集群节点，合理设置executor数，partition数以及每个executor占用CPU core数。