DolphinScheduler项目管理页面加载缓慢？这样优化
http://openwrite-whaleops.oss-cn-zhangjiakou.aliyuncs.com/31504_6153FB552E2B4F429616522F7384CA04问题征象
有时候，Apache DolphinScheduler项目管理页面会发生加载不出来的问题，浏览器查看为[http://ip:12345/dolphinscheduler/projects?pageSize=10&pageNo=1&searchVal=]请求超时。
http://openwrite-whaleops.oss-cn-zhangjiakou.aliyuncs.com/31504_2BE67CD321134CAD9271B624CF0DE460
办理思路
[*]查看海豚运行日志（未发现非常）
tail /home/dolphinscheduler/api-server/logs/dolphinscheduler-api.loghttp://openwrite-whaleops.oss-cn-zhangjiakou.aliyuncs.com/31504_3C176A1506F7478D9228D6BEB15CDD40
[*]尝试重启海豚的api-server模块
sh /home/dolphinscheduler/bin/dolphinscheduler-daemon.sh stop api-server
sh /home/dolphinscheduler/bin/dolphinscheduler-daemon.sh start api-server效果：还是加载不出来
[*]尝试请求超时连接发现请求能出数据，但是要十多秒
http://openwrite-whaleops.oss-cn-zhangjiakou.aliyuncs.com/31504_F544FE5070DC4A8D9C4596BC28FC8AC2
[*]尝试查看源码，可能是慢查询
代码位置
http://openwrite-whaleops.oss-cn-zhangjiakou.aliyuncs.com/31504_2D26061D49F3445C9A7DCDED560432B5
[*]使用arthas查看运行情况
curl -O https://arthas.aliyun.com/arthas-boot.jar
java -jar arthas-boot.jar
#找dolphinscheduler-api的那个就是，我的是第一个就看到了查看运行状况，查看是那里运行时间长。可以看到是queryProjectListPaging方法。
trace org.apache.dolphinscheduler.api.service.impl.ProjectServiceImpl queryProjectListPaging -n 1http://openwrite-whaleops.oss-cn-zhangjiakou.aliyuncs.com/31504_DFD0BC6B13364EC3AEFF26E0F19DB1EE
进入queryProjectListPaging方法
http://openwrite-whaleops.oss-cn-zhangjiakou.aliyuncs.com/31504_61DC171686C64DE3B254D076AAE5E36B
尝试运行sql，发现没有很慢。
select * from t_ds_project p
where 1=1and p.idin(1,2,3,5,6,8,9,12,13,14,16,17,19,21,22,23,25,26)
group by p.id
order by p.id desc尝试运行海运再运行中的sql，这里使用了arthas加上https://ctbots.com/#/arthas/parseMybatisSql辅助获取运行的sql。
http://openwrite-whaleops.oss-cn-zhangjiakou.aliyuncs.com/31504_79B62042FCAB4C2F8989C2AFECDD3F32
http://openwrite-whaleops.oss-cn-zhangjiakou.aliyuncs.com/31504_4538443F772447118F147CA073089F63
[*]获得慢sql，进行分析
select
p.id, p.name, p.code, p.description, p.user_id, p.flag, p.create_time, p.update_time
,
u.user_name as user_name,
(SELECT COUNT(*) FROM t_ds_process_definition AS def WHERE def.project_code = p.code) AS def_count,
(SELECT COUNT(*) FROM t_ds_process_definition_log def, t_ds_process_instance inst WHERE def.code =
inst.process_definition_code and def.version = inst.process_definition_version AND def.project_code = p.code
AND inst.state=1 ) as inst_running_count
from t_ds_project p
left join t_ds_user u on u.id=p.user_id
where 1=1
and p.idin
(1, 2, 3, 5, 6, 8, 9, 12, 13, 14, 16, 17, 19, 21, 22, 23, 25, 26)
group by p.id,u.user_name
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加索引
create index qwl_diy_index
on t_ds_process_instance (process_definition_code, process_definition_version, state);添加后验证，确实是快了。页面也恢复正常了。
http://openwrite-whaleops.oss-cn-zhangjiakou.aliyuncs.com/31504_0B44738680C34EE68B5BE20B941AE34C
原文链接：https://blog.csdn.net/weixin_41673092/article/details/144510764
本文由 白鲸开源 提供发布支持！
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]