页面树结构

版本比较

标识

  • 该行被添加。
  • 该行被删除。
  • 格式已经改变。

...

针对项目中经常遇到的无法访问问题排查的思路整理及相关工具的介绍。

...

2、问题排查

比较常见的情况是用户服务器的CPU一段时间内持续高占用不释放,导致运维平台持续告警,用户想要我们分析一下具体的原因以及给出必要的解决方案。

Image Removed

3、问题分析

...

无法访问问题一般分为以下几种情况,不同情况排查的思路略有差异,需要区别对待。

2.1

...

场景1:从来没有访问成功过场景

使用Top命令确定是哪个进程占用了系统的大部分CPU,比较常见的是Smartbi的Tomcat进程占用资源最多的情况。

确定了是哪个进程占用了CPU后就需要分析是进程的哪一个线程占用了CPU。

Image Removed

3.2 第二步:定位消耗CPU高的代码逻辑

3.2.1 方法1 通过top查看CPU消耗

方法说明:

优势:不依赖任何外部工具,且可以分析ETL、OLAP和Tomcat。

劣势:手动打命令转化慢,可能线程瞬间就运行完毕了,则无法捕捉到。

3.2.1.1 定位高占用线程

命令:top -Hbp pid | awk '/java/ && $9>50'

注:其中pid为Tomcat进程号

Image Removed

3.2.1.2 将高占用进程的线程号转换成16进制

命令:printf "%x\n" tid

注:其中tid为Tomcat线程号

Image Removed

3.2.1.3  jstack查看进程信息-定位到代码

命令:jstack pid | grep "xxx" -A 30

注:其中pid为Tomcat进程号,"xxx"为线程号的16进制码

Image Removed

3.2.2 方法2 通过listthread.jsp查看CPU消耗

方法说明:

优势:操作简单方便快捷。

劣势:必须是Smartbi应用占用了CPU且必须Smartbi能访问时也能使用。

访问地址举例:http://proj.smartbi.com.cn:30001/smartbi/vision/monitor/listthreads.jsp 

加载此界面完成后Ctrl+S保存网页内容发回分析,可分析是哪个线程占用过高的CPU,线程的堆栈也可以看到。

Image Removed

3.2.3 方法3 通过基线Tomcat内置工具

优势:操作简单方便快捷,且可以分析ETL、OLAP和Tomcat。

劣势:需要运行shell脚本,有些安全要求高的项目可能会被禁止。

工具地址:【内部】6.2_JVM和Tomcat调优配置基线

Image Removed

命令:./1_show-busy-java-threads.sh

Image Removed

3.3 第三步:根据代码情况判断引起CPU高占用的原因

如果已经定位到了具体因为CPU高的代码,可以反馈研发以及结合现场产品使用的场景定位出具有的原因。(比如是因为数据库问题导致的线程等待)

注:如果确定了是Smartbi产品CPU占用高,还可以结合CPU采样和线程进一步分析具体的原因。

系统监控-线程

image2021-8-26_14-16-31.pngImage Removed

系统监控-性能(CPU采样)

image2021-8-26_14-22-42.pngImage Removed

4、其他原因导致CPU高问题

4.1 ETL导致的CPU占用告警

Image Removed

某项目反馈CPU使用率突然飙升,经排查发现是因为ETL执行引擎占用了较高的CPU

检查ETL配置发现执行引擎中配置了14核(一共16核)导致的问题,这个是ETL本身机制问题导致的。

注意:ETL运行原理是基于分配的CPU进行使用,如果job比较多且数据量大就会把所分配的CPU全部占用

ETL建议的CPU和内存比例为1:4 ,目前内存是32g,建议配置8核CPU。

Image Removed

4.2 V11旧版本BUG导致的性能问题

某项目客户反馈生产服务cpu使用率到99.6%了,严重影响项目使用。

经排查发现是因为客户使用的是2024年10月份版本的Smartbi(发现对t_permission_detail表有大量的访问操作)

针对这个问题在2024年11月产品已经做了优化,通过升级新版本可以避免这个问题。

Image Removed

EPPR-92170【南网云景】递归获取子孙节点逻辑性能优化
EPPR-91535【南网云景】smarbti节点高cpu占用问题
EPPR-90023【南网云景】单目录节点过多,加载超时说明:一般来说首次安装部署时遇到这种情况比较多,一般都是由于安全要求导致的端口没开放导致的,此时的排查思路主要针对于网络或端口进行排查。

2.2 场景2:之前正常突然间不正常场景

说明:如果之前正常突然间不正常了,一般都是由于应用挂了或者请求太多被操作系统丢弃导致,此时的排查思路主要针对服务器端应用状态进行排查。

3、排查步骤

3.1 第一步:确定服务器服务正常

服务器断通过curl命令查看请求是否正常,在服务器端执行如下命令。

下方以smartbi应用为例,其他各组件连通性测试详见文档最后部分说明。

命令:curl -iL http://10.10.101.79:8017/smartbi/vision/noop.jsp

Image Added



3.2 第二步:检查网络是否联通。

如果已经确定服务本身正常,则需要验证当前客户端到服务器直接网络是否是联通的,在客户端执行如下命令。

命令:ping 10.10.101.79 -t

Image Added

说明:通过ping命令重点查看响应时间和TTL 来判断网络情况

1)TTL可以判断出发起网络请求服务器到目标服务器之间经过几次跳转(Windows 是128,Linux 是 64),每增加一个网络设备则TTL减1,从而判断是否有未知的安全设备。

2)通过响应时间来判断网络质量,是否比较快。

3.3 第三步:检查端口是否通畅

在客户端执行如下命令

命令1:telnet 10.10.101.79 7017

Image Added

如果没有安装telnet命令,可以使用ssh 命令测试端口连通性。

命令2:ssh -v -p 7017 10.10.101.79

Image Added

3.4 第四步:判断请求是否正常

通过命令行的方式模拟浏览器端请求,排除因为浏览器问题导致的无法访问问题,需要在客户端执行如下命令。

下方以smartbi应用为例,其他各组件连通性测试详见文档最后部分说明。

命令:curl -iL http://10.10.101.79:8017/smartbi/vision/noop.jsp

Image Added

4、CURL测试Smartbi各组件连通性命令

4.1  smartbi 服务

命令:curl -i http://10.10.101.79:18080/smartbi/vision/noop.jsp

Image Added

4.2 olap 服务

命令:curl -i http://10.10.101.79:18081/smartbiolap/ping.jsp

Image Added

4.3 导出引擎服务

命令:curl -i http://10.10.101.79:3003/test

Image Added

4.4 ETL引擎

命令:curl -i http://10.10.101.79:8899/api/v1/server/check

Image Added

4.5 SmartbiMpp(clickhouse)

命令:curl -i http://10.10.101.79:8123

Image Added

4.6 mysql数据库连接(telnet命令没有情况下)

命令:curl -iL http://10.10.101.79:6688/

如果能联通则会返回服务器版本信息(比如:8.0.3),如果无法联通则会返回连接拒绝

Image Added