页面树结构

版本比较

标识

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

...

1、背景说明

某用户使用smartbi实现了内部的实训平台,近期举办了实训大赛,平台使用的人较多,Smartbi服务近内存和CPU的消耗很大,过段时间平台就会崩掉,每天都要重启好多次。针对项目中经常遇到的CPU占用告警问题问题排查的思路整理及相关工具的介绍。Image Removed

2、问题说明

2、环境说明

Smartbi、MySQL知识库和业务库、挖掘引擎等相关组件都部署在一台服务器上。

最初服务器配置是32核128G,宕机后又升级到64核256G,虽然硬件配置提升了,但是只延缓了宕机的频率,依然并没有杜绝掉宕机的现象。比较常见的情况是用户服务器的CPU一段时间内持续高占用不释放,导致运维平台持续告警,用户想要我们分析一下具体的原因以及给出必要的解决方案。

Image Added

3、问题分析

3.1

...

第一步:定位占用CPU高的进程

根据上图展示的阿里云ECS服务器监控情况来看,整个服务器运行压力比较大,内存使用率和系统负载都很高。使用Top命令确定是哪个进程占用了系统的大部分CPU,比较常见的是Smartbi的Tomcat进程占用资源最多的情况。

需要使用Top命令确定是那些服务占用了系统的资源,经排查发现是Smartbi的Tomcat进程占用资源最多,确定了是哪个进程占用了CPU后就需要分析是进程的哪一个线程占用了CPU。

下面需要对Smartbi的Tomcat进程做进一步分析。

Image RemovedImage Added

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

3.2

...

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

方法说明:

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

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

3.2.1.1

...

定位高占用线程

命令:top -H -p pid

其中pid为Tomcat进程号,比如上图的20334

Image Removed

可以查看到很多线程占用CPU比较高,如果需要查看线程具体执行的代码逻辑需要通过如下操作

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

注:其中pid为Tomcat进程号

Image Added

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

命令:printf "%x\n" tid

注:其中tid为Tomcat线程号

Image Added

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

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

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

Image Added

3.2.2

...

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

方法说明:

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

如果此时Smartbi页面可以正常访问,可以使用Smartbi内置的JSP页面来查看哪些线程占用CPU比较多。劣势:必须是Smartbi应用占用了CPU且必须Smartbi能访问时也能使用。

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

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

Image RemovedImage Added

3.2.3

...

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

通过arthas工具监控发现Smartbi存在大量线程CPU使用率非常高。优势:操作简单方便快捷,且可以分析ETL、OLAP和Tomcat。

Image Removed

Image Removed

3.2试试

经排查这些线程主要是对tx_processdag表进行全表遍历,tx_processdag大约有2.5万条记录,单独执行需要20s+才能够执行完毕,存在很大性能瓶颈。

     

配置文件位置

在不同的操作系统上,​​my.cnf​​ 文件的位置可能有所不同:

Windows: 通常位于 MySQL 安装目录下的 ​​my.ini​​ 文件。

Linux: 通常位于 ​​/etc/my.cnf​​ 或 ​​/etc/mysql/my.cnf​​,可以通过如下命令查看配置文件的查找路径

...

Image Removed

mysqld 默认会从 /etc/my.cnf、/etc/mysql/my.cnf、/usr/local/mysql/etc/my.cnf ~/.my.cnf 多个文件依次读取配置。

注1:如果某个参数在多个文件都有配置,那么就以最后读取到的那个参数值为准。

注2:可以使用命令行参数 defaults-file 指定配置文件,指定这个参数后,MySQL 只会从这个文件中读取配置项,需要注意,defaults-file 在所有命令行参数中必须排在最前面才有效。

注3:如果有多个配置文件,查看当前生效的配置及使用配置文件位置的SQL语句

...

SELECT
info.VARIABLE_NAME,
info.VARIABLE_SOURCE,
info.VARIABLE_PATH,
gv.VARIABLE_VALUE,
info.MIN_VALUE,
info.MAX_VALUE,
info.SET_TIME,
info.SET_USER,
info.SET_HOST
FROM
( SELECT * FROM `performance_schema`.variables_info WHERE length( variable_path )!= 0 ) info
LEFT JOIN `performance_schema`.global_variables gv ON info.VARIABLE_NAME = gv.VARIABLE_NAME
ORDER BY
info.VARIABLE_SOURCE DESC

Image Removed

3、MySQL配置文件结构

my.cnf​​(my.ini)文件是一个文本文件,每个配置项都包含在一个特定的节(section)中,每个节由方括号 ​​[ ]​​ 包围,表示该节下的配置项适用于哪个组件或服务。常见的节包括:

[mysqld]​​: 针对 MySQL 服务器的配置

​​[client]​​: 针对所有客户端程序的配置

[mysql]​​: 针对 ​​mysql​​ 命令行工具的配置

3.1 [mysqld]配置

这是 MySQL 服务器的主要配置部分。

3.1.1 基本设置

...

3.1.2 性能优化

...

innodb_buffer_pool_size = 1G

...

interactive_timeout = 1800

...

max_allowed_packet=512M

...

3.1.3 日志设置(非必需)

...

3.1.4 安全性设置(非必需)

...

3.1.5 复制设置(非必需)

...

3.2 [client]配置

这是客户端程序的配置部分,主要是为了给mysql 客户端命令配置相关参数,此处配置了,在命令行中就不需要再次指定了

...

如下截图所示,因为在client中配置了user,链接时直接指定-p 输入密码即可,不用再执行-uroot参数了。

另执行[\s]命令可以看到当前的连接信息情况。

Image Removed

3.3 [mysql]配置

这是 MySQL 命令行工具的配置部分的配置,很少使用到,了解一下即可,基本不用配置。

4、MySQL知识库调优基线配置说明

公司内部使用的MySQL知识库的参数配置的基线也是基于my.cnf的调优配置(基本的调优配置如下),详情参考下方链接说明。

...

【内部】6.3_MYSQL8知识库调优配置基线劣势:需要运行shell脚本,有些安全要求高的项目可能会被禁止。

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

Image Added

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

Image Added

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

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

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

系统监控-线程

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

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

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

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

4.1 ETL导致的CPU占用告警

Image Added

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

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

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

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

Image Added

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

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

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

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

Image Added

EPPR-92170【南网云景】递归获取子孙节点逻辑性能优化
EPPR-91535【南网云景】smarbti节点高cpu占用问题
EPPR-90023【南网云景】单目录节点过多,加载超时