性能调优过程发现的问题

1.硬件不足问题，cpu和内存超过90%，是因为系统的架构做了修改（spark和tomcat共享内存，因此造成服务器硬件不足）

 

2.spark集群配置的session共享问题，导致 用户多进行并发时，部分用户登录失败。

 

3、两台服务器负载不均衡问题，并发下，两台服务器使用资源相差特别多，运维人员修改了负载均衡的参数搞定此问题。

 

4、10小时稳定测试中发现的问题如下:

     a：服务器的日志级别太低，导致5天跑满了40GB的空间，导致重启。

     b： 链接满了，导致断开了一些而失败，因为链接不用后不会立即释放掉，需要隔一段时间再释放。

     c：ubantu系统的打开文件数超过了最大值，导致运行4到5个小时候，保存项目功能总是失败，因为保存项目时，需要将数据写入到spark的数据，写入时便需要open文件，

        还有一共可能就是open的文件数太多没有close掉。

5、开发写的udf（user defind function）方法，效率太低，导致分析台拖拽字段后的出图时间太慢，因为字段太多时候，每个字段要经过一次udf算法，

    通过计算一个null的string类型 警告过udf算法后就要经过1-2s的时间。

6、spark集群数据库的时间类型的字段落地成了string类型，这样拖拽字段时候增加了一个再把string转换成时间类型的过程的参数。

    后来开发修改后已经提升了时间类型的字段的拖拽出图时间50%左右。

7.挖掘流程：代码写的有问题。

      内进行一个预测功能，就new一个sparksession，这样spark便于mysql数据库连接一次，导致超过链接次数而失败，

      现在已经无session改用context，sparkcontext有个队列会自动分配与删除executor(运行计算spark)，一个driver只会有一个sparkcontext示例。

 

 

 

8、7/0版本时候优化数据库添加索引，提升了很多性能问题。。

 

9、落地2千万的mysql数据库的数据时候，发现spark的任务队列中多了一个show的任务，耗时2分多钟，按道理讲保存项目过程只需要一个save的任务，