DolphinScheduler项目管理页面加载缓慢？这样优化

问题征象

有时候，Apache DolphinScheduler项目管理页面会发生加载不出来的问题，浏览器查看为[http://ip:12345/dolphinscheduler/projects?pageSize=10&pageNo=1&searchVal=]请求超时。

办理思路

• 查看海豚运行日志（未发现非常）
  

1. tail /home/dolphinscheduler/api-server/logs/dolphinscheduler-api.log

复制代码

• 尝试重启海豚的api-server模块
  

1. sh /home/dolphinscheduler/bin/dolphinscheduler-daemon.sh stop api-server
2. sh /home/dolphinscheduler/bin/dolphinscheduler-daemon.sh start api-server

复制代码

效果：还是加载不出来

• 尝试请求超时连接发现请求能出数据，但是要十多秒
  
  
  
  
• 尝试查看源码，可能是慢查询
  代码位置
  
  
  
  
• 使用arthas查看运行情况
  

1. curl -O https://arthas.aliyun.com/arthas-boot.jar
2. java -jar arthas-boot.jar
3. #找dolphinscheduler-api的那个就是，我的是第一个就看到了

复制代码

查看运行状况，查看是那里运行时间长。可以看到是queryProjectListPaging方法。

1. trace org.apache.dolphinscheduler.api.service.impl.ProjectServiceImpl queryProjectListPaging -n 1

复制代码

进入queryProjectListPaging方法

尝试运行sql，发现没有很慢。

1. select * from t_ds_project p
2.                   where 1=1  and p.id  in(1,2,3,5,6,8,9,12,13,14,16,17,19,21,22,23,25,26)
3.                   group by p.id
4.                   order by p.id desc

复制代码

尝试运行海运再运行中的sql，这里使用了arthas加上https://ctbots.com/#/arthas/parseMybatisSql辅助获取运行的sql。

• 获得慢sql，进行分析
  

1. select
3.     p.id, p.name, p.code, p.description, p.user_id, p.flag, p.create_time, p.update_time
5.         ,
6.     u.user_name as user_name,
7.     (SELECT COUNT(*) FROM t_ds_process_definition AS def WHERE def.project_code = p.code) AS def_count,
8.     (SELECT COUNT(*) FROM t_ds_process_definition_log def, t_ds_process_instance inst WHERE def.code =
9.                                                                                             inst.process_definition_code and def.version = inst.process_definition_version AND def.project_code = p.code
10.                                                                                         AND inst.state=1 ) as inst_running_count
11. from t_ds_project p
12.          left join t_ds_user u on u.id=p.user_id
13. where 1=1
15.   and p.id  in
16.       (1, 2, 3, 5, 6, 8, 9, 12, 13, 14, 16, 17, 19, 21, 22, 23, 25, 26)
17. group by p.id,u.user_name
18. order by p.id desc LIMIT 100

复制代码

通过explain分析sql可知是inst_running_count这里查询慢。查看t_ds_process_definition表就28万多数据，t_ds_process_definition_log表有1千数据。
由此可知是日志数据太多了。尝试优化这个查询，给t_ds_process_instance加索引

1. create index qwl_diy_index
2.     on t_ds_process_instance (process_definition_code, process_definition_version, state);

复制代码

添加后验证，确实是快了。页面也恢复正常了。

原文链接：https://blog.csdn.net/weixin_41673092/article/details/144510764

本文由 白鲸开源 提供发布支持！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。