技术组件优化分析:原理、方法与实战分享

这篇具有很好参考价值的文章主要介绍了技术组件优化分析:原理、方法与实战分享。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

对一个固定的技术组件的分析优化思路,即组件不是我们开发的,但又要分析优化它,怎么办?

当数据库的CPU并没有全部用完,而是只用了几颗的时候,如何具体定向?将用到查看数据库本身线程栈的方法,这和前面直接看trx表有所不同。

1 场景运行数据

对于支付前查询订单列表接口,先看第一次运行的性能场景结果:

技术组件优化分析:原理、方法与实战分享

从运行的场景数据来看,这接口TPS一开始还挺高,达800。但响应时间也增加,瓶颈已出现。只要知道瓶颈在哪,就能知道这个接口有无优化空间。

2 架构图

技术组件优化分析:原理、方法与实战分享

可见,当前接口的逻辑为:Gateway - Order - Member,其中也使用到MySQL和Redis。

3 拆分响应时间

  • Gateway:
    技术组件优化分析:原理、方法与实战分享
  • Order:
    技术组件优化分析:原理、方法与实战分享
  • Member:
    技术组件优化分析:原理、方法与实战分享

从响应时间分布看,Gateway(网关)消耗时间长。接下来从Gateway下手,分析到底哪消耗了时间。

4 第一阶段

4.1 全局监控分析

先看这个接口的全局监控:

技术组件优化分析:原理、方法与实战分享

由于Gateway消耗的响应时间长,看过全局监控视图后,要判断Gateway在哪个worker:

[root@k8s-master-2 ~]# kubectl get pods -o wide | grep gateway
gateway-mall-gateway-757659dbc9-tdwnm       1/1     Running     0          3d16h   10.100.79.96     k8s-worker-4   <none>           <none>
[root@k8s-master-2 ~]#

在worker-4,同时在全局监控图上可看到,虽然Gateway只消耗70%CPU,但它还是消耗最多响应时间。那就看Gateway的线程状态,在处理什么。

4.2 定向监控分析

先看一下线程的CPU消耗:

技术组件优化分析:原理、方法与实战分享

通过上图可看,Gateway有两类重要工作线程:

  • reactor-http-epoll

    reactor-http-epoll线程的设置最好与CPU个数一致。当前reactor-http-epoll线程4个,而这个worker有6C,所以还能增加两个

  • boundedElastic

    有边界的弹性线程池,默认为CPU核x10,也没啥可优化

再持续看一会儿Gateway服务中的线程所消耗的时间比例,看方法级的时间消耗有没有异常的情况,即比例非常高的:

技术组件优化分析:原理、方法与实战分享

当前的执行方法也都没啥异常。

现在我们就把线程增加到6个,看能不能把CPU用高一点。如果CPU用多了之后,仍然是Gateway消耗的时间长,那就只有再继续加CPU。

性能项目中,不要轻易给出加CPU这样的建议。一定要在你分析了逻辑后,确定没有其他优化空间,再给这样的建议。

4.3 优化效果

技术组件优化分析:原理、方法与实战分享

通过回归测试,看到TPS有一点增加,只是在图的后半段(由于在测试过程中,Gateway重启过,前面的TPS就当是预热了)增加的并不明显,大概有50多TPS的样子。不过,也算是有了效果。

还没结束,查看各Worker的过程中,还发现DB里有两个CPU使用率很高。

优化效果不咋样,重新开始分析。

5 二阶段

5.1 全局监控分析

技术组件优化分析:原理、方法与实战分享

DB所在的worker-1也没啥大的资源消耗。

文章中经常用这个界面看全局监控数据。但这不是只看这界面。当我在这界面中看不到明显问题点时,也会去看命令像top/vmstat,这和我一直说的全局监控的完整计数器有关。因此,你要有全局监控计数器的视图,然后才能真正看全第一层的计数器。

再看DB所在的worker上的top数据:

bash-4.2$ top      
top - 09:57:43 up 3 days, 17:54,  0 users,  load average: 4.40, 3.57, 3.11
Tasks:  11 total,   1 running,   9 sleeping,   1 stopped,   0 zombie
%Cpu0  :  8.0 us,  4.7 sy,  0.0 ni, 84.3 id,  0.0 wa,  0.0 hi,  2.2 si,  0.7 st
%Cpu1  :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  6.5 us,  4.4 sy,  0.0 ni, 85.5 id,  0.0 wa,  0.0 hi,  2.2 si,  1.5 st
%Cpu3  :  7.8 us,  5.7 sy,  0.0 ni, 83.7 id,  0.0 wa,  0.0 hi,  2.1 si,  0.7 st
%Cpu4  : 96.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  4.0 si,  0.0 st
%Cpu5  :  7.0 us,  4.0 sy,  0.0 ni, 84.9 id,  0.0 wa,  0.0 hi,  2.6 si,  1.5 st
KiB Mem : 16265992 total,  1203032 free,  6695156 used,  8367804 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  9050344 avail Mem 


  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                      
    1 mysql     20   0 8272536   4.7g  13196 S 248.8 30.5   6184:36 mysqld 

有两个CPU的使用率高,就定向分析DB。

5.2 定向监控分析

可在DB上又不是所有CPU使用率都高,所以,要看DB线程到底在做啥。有了上面的进程信息后,再深入线程级:

bash-4.2$ top -Hp 1
top - 09:56:40 up 3 days, 17:53,  0 users,  load average: 3.05, 3.30, 3.01
Threads:  92 total,   2 running,  90 sleeping,   0 stopped,   0 zombie
%Cpu0  :  5.4 us,  2.9 sy,  0.0 ni, 89.2 id,  0.0 wa,  0.0 hi,  2.2 si,  0.4 st
%Cpu1  : 99.7 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.3 st
%Cpu2  :  5.4 us,  3.2 sy,  0.0 ni, 88.2 id,  0.0 wa,  0.0 hi,  2.5 si,  0.7 st
%Cpu3  :  6.3 us,  4.2 sy,  0.0 ni, 87.0 id,  0.0 wa,  0.0 hi,  2.1 si,  0.4 st
%Cpu4  : 96.3 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  3.7 si,  0.0 st
%Cpu5  :  4.0 us,  2.5 sy,  0.0 ni, 91.0 id,  0.0 wa,  0.0 hi,  1.8 si,  0.7 st
KiB Mem : 16265992 total,  1205356 free,  6692736 used,  8367900 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  9052664 avail Mem 


  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND                                                                       
  311 mysql     20   0 8272536   4.7g  13196 R 99.9 30.5  18:20.34 mysqld                                                                        
  241 mysql     20   0 8272536   4.7g  13196 R 99.7 30.5   1906:40 mysqld                                                                        
  291 mysql     20   0 8272536   4.7g  13196 S  3.3 30.5  15:49.21 mysqld                                                                        
  319 mysql     20   0 8272536   4.7g  13196 S  3.0 30.5  11:50.34 mysqld                                                                        
  355 mysql     20   0 8272536   4.7g  13196 S  3.0 30.5  13:01.53 mysqld                                                                        
  265 mysql     20   0 8272536   4.7g  13196 S  2.7 30.5  18:17.48 mysqld                                                                        
  307 mysql     20   0 8272536   4.7g  13196 S  2.7 30.5  16:47.77 mysqld                                                                        
  328 mysql     20   0 8272536   4.7g  13196 S  2.7 30.5  15:34.92 mysqld                                                                        
  335 mysql     20   0 8272536   4.7g  13196 S  2.7 30.5   8:55.38 mysqld                                                                        
  316 mysql     20   0 8272536   4.7g  13196 S  2.3 30.5  14:38.68 mysqld                                                                        
  350 mysql     20   0 8272536   4.7g  13196 S  2.3 30.5  10:37.94 mysqld                                                                        
  233 mysql     20   0 8272536   4.7g  13196 S  2.0 30.5  14:19.32 mysqld                                                                        
  279 mysql     20   0 8272536   4.7g  13196 S  2.0 30.5  19:51.80 mysqld                                                                        
  318 mysql     20   0 8272536   4.7g  13196 S  2.0 30.5  11:34.62 mysqld                                                                        
  331 mysql     20   0 8272536   4.7g  13196 S  2.0 30.5  11:46.94 mysqld                                                                        
  375 mysql     20   0 8272536   4.7g  13196 S  2.0 30.5   1:29.22 mysqld                                                                        
  300 mysql     20   0 8272536   4.7g  13196 S  1.7 30.5  17:45.26 mysqld                                                                        
  380 mysql     20   0 8272536   4.7g  13196 S  1.7 30.5   1:24.32 mysqld            

只有两个MySQL的线程在使用CPU。接下来查SQL!虽然可能就是SQL的问题,但建议你找到相应证据。

gstack(装了GDB后就有的命令)打印这两个MySQL的栈,看具体函数。把那两个PID(311、241)的栈拿出来之后,看到:

Thread 59 (Thread 0x7f1d60174700 (LWP 241)):
#0  0x000055a431fefea9 in JOIN_CACHE::read_record_field(st_cache_field*, bool) ()
#1  0x000055a431ff01ca in JOIN_CACHE::read_some_record_fields() ()
#2  0x000055a431ff070f in JOIN_CACHE::get_record() ()
#3  0x000055a431ff2a92 in JOIN_CACHE_BNL::join_matching_records(bool) ()
#4  0x000055a431ff18f0 in JOIN_CACHE::join_records(bool) ()
#5  0x000055a431e397c0 in evaluate_join_record(JOIN*, QEP_TAB*) ()
#6  0x000055a431e3f1a5 in sub_select(JOIN*, QEP_TAB*, bool) ()
#7  0x000055a431e37a90 in JOIN::exec() ()
#8  0x000055a431eaa0ba in handle_query(THD*, LEX*, Query_result*, unsigned long long, unsigned long long) ()
#9  0x000055a43194760d in execute_sqlcom_select(THD*, TABLE_LIST*) ()
#10 0x000055a431e6accf in mysql_execute_command(THD*, bool) ()
#11 0x000055a431e6d455 in mysql_parse(THD*, Parser_state*) ()
#12 0x000055a431e6e3b6 in dispatch_command(THD*, COM_DATA const*, enum_server_command) ()
#13 0x000055a431e6fc00 in do_command(THD*) ()
#14 0x000055a431f33938 in handle_connection ()
#15 0x000055a4320e66d4 in pfs_spawn_thread ()
#16 0x00007f1e8f1fcdd5 in start_thread () from /lib64/libpthread.so.0
#17 0x00007f1e8d3cc02d in clone () from /lib64/libc.so.6
Thread 41 (Thread 0x7f1d585e0700 (LWP 311)):
#0  0x000055a4319dbe44 in Item_field::val_int() ()
#1  0x000055a4319fb839 in Arg_comparator::compare_int_signed() ()
#2  0x000055a4319fbd9b in Item_func_eq::val_int() ()
#3  0x000055a431ff24ab in JOIN_CACHE::check_match(unsigned char*) ()
#4  0x000055a431ff26ec in JOIN_CACHE::generate_full_extensions(unsigned char*) ()
#5  0x000055a431ff2ab4 in JOIN_CACHE_BNL::join_matching_records(bool) ()
#6  0x000055a431ff18f0 in JOIN_CACHE::join_records(bool) ()
#7  0x000055a431e397c0 in evaluate_join_record(JOIN*, QEP_TAB*) ()
#8  0x000055a431e3f1a5 in sub_select(JOIN*, QEP_TAB*, bool) ()
#9  0x000055a431e37a90 in JOIN::exec() ()
#10 0x000055a431eaa0ba in handle_query(THD*, LEX*, Query_result*, unsigned long long, unsigned long long) ()
#11 0x000055a43194760d in execute_sqlcom_select(THD*, TABLE_LIST*) ()
#12 0x000055a431e6accf in mysql_execute_command(THD*, bool) ()
#13 0x000055a431e6d455 in mysql_parse(THD*, Parser_state*) ()
#14 0x000055a431e6e3b6 in dispatch_command(THD*, COM_DATA const*, enum_server_command) ()
#15 0x000055a431e6fc00 in do_command(THD*) ()
#16 0x000055a431f33938 in handle_connection ()
#17 0x000055a4320e66d4 in pfs_spawn_thread ()
#18 0x00007f1e8f1fcdd5 in start_thread () from /lib64/libpthread.so.0
#19 0x00007f1e8d3cc02d in clone () from /lib64/libc.so.6

两个execute_sqlcom_select函数,即两个select语句。接着往上看栈,还可看到JOIN函数。既然是select语句中的JOIN,直接找SQL语句。

直接查innodb_trx表,看正在执行SQL有没有消耗时间长的。你也许会执行show processlist之类的命令,但为看全SQL,建议直接查trx表。

由于我们使用的thread_handling是默认的one-thread-per-connection,os的线程和MySQL里的线程都是一一对应。所以,这里直接查trx表不会有误判。

查找innodb_trx表,看到这两个SQL消耗时间长:

-- sql1
SELECT
	count(*)
FROM
	oms_order o
LEFT JOIN oms_order_item ot ON o.id = ot.order_id
WHERE
	o. STATUS = 0
AND o.create_time < date_add(NOW(), INTERVAL - 120 MINUTE)
LIMIT 0,
 1000


-- sql2:
SELECT
	o.id,
	o.order_sn,
	o.coupon_id,
	o.integration,
	o.member_id,
	o.use_integration,
	ot.id ot_id,
	ot.product_name ot_product_name,
	ot.product_sku_id ot_product_sku_id,
	ot.product_sku_code ot_product_sku_code,
	ot.product_quantity ot_product_quantity
FROM
	oms_order o
LEFT JOIN oms_order_item ot ON o.id = ot.order_id
WHERE
	o. STATUS = 0
AND o.create_time < date_add(NOW(), INTERVAL - 120 MINUTE)

想看SQL慢,就看SQL执行计划(MySQL执行计划看不清楚,还可看Profile信息):

技术组件优化分析:原理、方法与实战分享

技术组件优化分析:原理、方法与实战分享

全表扫描。

支付前查询订单列表这个接口并没有用到这俩SQL。到代码看下这两个SQL的生成过程,反向查找到:

 @Scheduled(cron = "0 0/20 * ? * ?")
    private void cancelTimeOutOrder(){
        Integer count = portalOrderService.cancelTimeOutOrder();
        LOGGER.info("取消订单释放锁定库存:{}",count);
    }

这是个定时计划,每20分钟执行一次。原来是定时任务调用了这两个批量的查询语句,导致两个CPU使用率达到100%,并且持续了一段时间。

像这样的定时任务,要格外关注,注意把它和实时业务分开部署和处理,减少批量业务对实时业务的资源争用。若放在一起处理,要控制好要批量查询的数据量级,让SQL查询更合理。

由于数据库可用的CPU较多,这定时任务对TPS并没有产生明显影响,在这里我们不用做什么处理,以后注意分开就好。

6 总结

虽然优化没有让TPS明显增加,但因为分析的技术细节不一样,也完整记录了分析过程。

一阶段分析不同点在于,对一个成熟固定组件,要想优化它,就要去了解它的架构,找到相关性能参数。因为实际性能项目中,面对这样的组件,往往没有时间去纠结内部的实现,需要非常快速地作出判断。如时间允许,慢慢折腾。

理解一个技术组件的原理,并没有想像中的那么高不可攀、深不可测,只要耐心看下去,总会成长。

二阶段分析,由某几个CPU高的现象分析到了具体的SQL问题。这个过程虽然简单,但从这问题,可以看出这系统还有很多优化空间,如主从分离、定时任务拆为单独的服务等等。

不过,性能分析中,重点仍是分析思路。

FAQ

为什么要看全部的全局监控计数器?

也可能存在关联系统影响导致性能差?在性能分析中没有“可能”。其实这个问题要问的是一个思路,而不是原因。

因为一个全局监控方法可能不能包含所有性能计数器,要知道自己想看什么计数器,知道计数器可以通过哪些工具来查看,使用全部是为了不漏点存在问题的任何可能性。

单CPU高时,如何定位具体的问题点?你有什么思路?

单cpu高,可以先查看cpu在跑哪些线程,找到对应高效耗线程,然后再去使用工具查看这些线程在干什么,从而定位问题。
CPU使用率高,也可以使用perf抓去调用函数?也同样是问思路。不过cpu使用率,应该先看是哪个计数器,再确定后续的思路,而不是直接用perf去看系统调用。

一切性能问题,都能通过jstack pid找到线索

那要看是不是和代码有关的问题。
jstack是查看栈信息的,也就是代码的执行逻辑。文章来源地址https://www.toymoban.com/news/detail-409440.html

到了这里,关于技术组件优化分析:原理、方法与实战分享的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【深入浅出Spring原理及实战】「源码调试分析」深入源码探索Spring底层框架的的refresh方法所出现的问题和异常

    阅读Spring官方文档,了解Spring框架的基本概念和使用方法。 下载Spring源码,可以从官网或者GitHub上获取。 阅读Spring源码的入口类,了解Spring框架的启动过程和核心组件的加载顺序。 阅读Spring源码中的注释和文档,了解每个类和方法的作用和用法。 调试Spring源码,可以通过

    2023年04月23日
    浏览(49)
  • 技术分享 | EdgeX 规则引擎 eKuiper 实战

    关于2022 EdgeX中国挑战赛 2022 EdgeX中国挑战赛暨中关村国际前沿科技创新大赛EdgeX专题赛正式拉开帷幕。大赛由北京市科委、中关村管委会指导,由Linux基金会主办,由阿里云、百度智能云、EMQ、GSMA 5G IN、英特尔、InnoSpace、中科创达、VMware、紫竹ET孵化器等联合承办单位共同支持

    2024年04月22日
    浏览(28)
  • 人工智能实战:Stable Diffusion技术分享

    背景 Stable Diffusion是计算机图形学和可视化领域中的一项重要技术。在这篇分 享中 ,我们将深入探讨稳定扩散的原理、关键要素和实施步骤 ,通过了解Stable Diffusion的流程化 ,我们可以提升自身的设计能力和创造力 ,为公司 和个人注入更多的价值和创意。 美术制定 美术风

    2024年01月19日
    浏览(47)
  • 技术分享|ueditor漏洞利用&源码分析超详细分析

    UEditor是一款基于web技术的所见即所得富文本编辑器,广泛应用于各种web应用中。但是,近年来,由于其漏洞导致的安全问题也受到了广泛关注。本文将详细介绍ueditor的漏洞利用及其C#版本的源码解析。 ueditor的漏洞主要存在于其上传功能中,攻击者可以利用上传漏洞将恶意脚

    2024年02月09日
    浏览(47)
  • 微服务服务间调用组件Feign使用介绍、原理、优化技巧

    Feign是一个声明式的Web Service客户端。它让微服务之间的调用变得更简单。Feign具有可插拔式的注解支持,包括Feign 注解和JAX-RS注解。Feign还支持可插拔的编码器和解码器。Spring Cloud增加了对Spring MVC注解的支持,并且也支持Spring WebFlux。 Feign可以与Eureka和Ribbon组合使用以支持负载均

    2024年02月06日
    浏览(75)
  • 大数据存储组件TiDB原理+实战篇

    1.TiDB引入 1.1.数据库技术发展简史 ​ 数据库技术产生于20世纪60年代末70年代初,其主要主要研究如何存储,使用和管理数据。随着计算机硬件和软件的发展,数据库技术也不断地发展。数据库技术在理论研究和系统开发上都取得了辉煌的成就。 从数据管理的角度看,数据库

    2024年02月02日
    浏览(37)
  • Elasticsearch 底层技术原理以及性能优化实践

    Elasticsearch是一个基于Lucene库的开源搜索引擎,支持分布式、多租户和全文搜索功能。它使用了RESTful API接口可以简化对Elasticsearch的集成和扩展。 Elasticsearch广泛应用于全文搜索、日志存储和分析、安全事件检测、业务指标分析等领域。 Elasticsearch是一个分布式系统由多个节点

    2024年02月08日
    浏览(40)
  • 大话AI绘画技术原理与算法优化

    博主很长一段时间都没有发文,确实是在忙一些技术研究。 如标题所示,本篇博文主要把近段时间的研究工作做一个review。 看过各种相关技术的公关文章,林林总总,水分很多。 也确实没有多少人能把一些技术细节用一些比较通俗的语言阐述清楚。 故此,再一次冠以大话为

    2024年02月01日
    浏览(27)
  • Mysql优化原理分析

    一张表生成三个文件 xxx.frm:存储表结构 xxx.MYD:存储表数据 xxx.MYI:存储表索引 索引文件和数据文件是分离的(非聚集) select * from t where t.col1 = 30; 先去t.MYI文件查找30对应的索引所在磁盘文件地址,去t.MYD文件找出对应磁盘文件地址的数据 一张表生成两个文件 xxx.frm:存储表

    2024年02月10日
    浏览(48)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包