首页 > 其他分享 >openGauss学习笔记-216 openGauss性能调优-确定性能调优范围-硬件瓶颈点分析-CPU

openGauss学习笔记-216 openGauss性能调优-确定性能调优范围-硬件瓶颈点分析-CPU

时间:2024-02-08 20:31:57浏览次数:26  
标签:20 性能 omm gaussdb 调优 5.4 openGauss CPU 0.0%

openGauss学习笔记-216 openGauss性能调优-确定性能调优范围-硬件瓶颈点分析-CPU

获取openGauss节点的CPU、内存、I/O和网络资源使用情况,确认这些资源是否已被充分利用,是否存在瓶颈点。

216.1 CPU

通过top命令查看openGauss内节点CPU使用情况,分析是否存在由于CPU负载过高导致的性能瓶颈。 top命令经常用来监控linux的系统状况,是常用的性能分析工具,能够实时显示系统中各个进程的资源占用情况。

参数解释:

  • d:number代表秒数,表示top命令显示的页面更新一次的间隔。默认是5秒。
  • b:以批次的方式执行top。
  • n:与b配合使用,表示需要进行几次top命令的输出结果。
  • p:指定特定的pid进程号进行观察。

216.2 查看CPU状况

查询服务器CPU的使用情况主要通过以下方式:

在所有存储节点,逐一执行top命令,查看CPU占用情况。执行该命令后,按“1”键,可查看每个CPU核的使用率。

top - 17:05:04 up 32 days, 20:34,  5 users,  load average: 0.02, 0.02, 0.00
Tasks: 124 total,   1 running, 123 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.0%us,  0.3%sy,  0.0%ni, 69.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  0.3%us,  0.3%sy,  0.0%ni, 69.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.3%us,  0.3%sy,  0.0%ni, 69.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  0.3%us,  0.3%sy,  0.0%ni, 69.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8038844k total,  7165272k used,   873572k free,   530444k buffers
Swap:  4192924k total,     4920k used,  4188004k free,  4742904k cached

   PID USER  PR  NI  VIRT  RES  SHR  S   %CPU %MEM   TIME+  COMMAND                                                        
 35184 omm   20   0  822m 421m 128m  S    0    5.4   5:28.15 gaussdb                                                        
     1 root   20   0 13592  820  784 S    0    0.0   1:16.62 init            

分析时,请主要关注进程占用的CPU利用率。

其中,统计信息中“us”表示用户空间占用CPU百分比,“sy”表示内核空间占用CPU百分比,“id”表示空闲CPU百分比。如果“id”低于10%,即表明CPU负载较高,可尝试通过降低本节点任务量等手段降低CPU负载。

216.3 性能参数分析

1、使用“top -H”命令查看CPU,显示内容如下所示。

    14 root      20   0     0    0    0 S    0  0.0   0:16.41 events/3                  
top - 14:22:49 up 5 days, 21:51,  2 users,  load average: 0.08, 0.08, 0.06
Tasks: 312 total,   1 running, 311 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.3%us,  0.7%sy,  0.0%ni, 95.0%id,  2.4%wa,  0.5%hi,  0.2%si,  0.0%st
Mem:   8038844k total,  5317668k used,  2721176k free,   180268k buffers
Swap:  4192924k total,        0k used,  4192924k free,  2886860k cached

   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                 
  3105 root      20   0 50492  11m 2708 S    3  0.1  22:22.56 acc-snf
  4015 gdm       20   0  232m  23m  11m S    0  0.3  11:34.70 gdm-simple-gree           
 51001 omm  20   0 12140 1484  948 R    0  0.0   0:00.94 top
 54885 omm  20   0  615m 396m 116m S    0  5.1   0:09.44 gaussdb
     1 root      20   0 13592  944  792 S    0  0.0   0:08.54 init

2、根据查询结果中“Cpu(s)”分析是系统CPU(sy)还是用户CPU(us)占用过高。

  • 如果是系统CPU占用过高,需要查找异常系统进程进行处理。

  • 如果是“USER”为omm的openGauss进程CPU占用过高,请根据目前运行的业务查询内容,对业务SQL进行优化。请根据以下步骤,并结合当前正在运行的业务特征进行分析,是否该程序处于死循环逻辑。

    a. 使用“top -H -p pid”查找进程内占用的CPU百分比较高的线程,进行分析。

    top -H -p 54952
    

    查询结果如下所示,top中可以看到占用CPU很高的线程,下面以线程54775为主,分析其为何占用CPU过高。

    top - 14:23:27 up 5 days, 21:52,  2 users,  load average: 0.04, 0.07, 0.05
    Tasks:  13 total,   0 running,  13 sleeping,   0 stopped,   0 zombie
    Cpu(s):  0.9%us,  0.4%sy,  0.0%ni, 97.3%id,  1.1%wa,  0.2%hi,  0.1%si,  0.0%st
    Mem:   8038844k total,  5322180k used,  2716664k free,   180316k buffers
    Swap:  4192924k total,        0k used,  4192924k free,  2889860k cached
    
       PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                  
     54775 omm  20   0  684m 424m 131m S    0  5.4   0:00.32 gaussdb                   
     54951 omm  20   0  684m 424m 131m S    0  5.4   0:00.84 gaussdb                   
     54732 omm  20   0  684m 424m 131m S    0  5.4   0:00.24 gaussdb                   
     54758 omm  20   0  684m 424m 131m S    0  5.4   0:00.00 gaussdb                   
     54759 omm  20   0  684m 424m 131m S    0  5.4   0:00.02 gaussdb                   
     54773 omm  20   0  684m 424m 131m S    0  5.4   0:02.79 gaussdb                   
     54780 omm  20   0  684m 424m 131m S    0  5.4   0:00.04 gaussdb                   
     54781 omm  20   0  684m 424m 131m S    0  5.4   0:00.21 gaussdb                   
     54782 omm  20   0  684m 424m 131m S    0  5.4   0:00.02 gaussdb                   
     54798 omm  20   0  684m 424m 131m S    0  5.4   0:16.70 gaussdb                   
     54952 omm  20   0  684m 424m 131m S    0  5.4   0:07.51 gaussdb                   
     54953 omm  20   0  684m 424m 131m S    0  5.4   0:00.81 gaussdb                   
     54954 omm  20   0  684m 424m 131m S    0  5.4   0:06.54 gaussdb                   
    

    b. 使用“gstack ”查看进程内各线程的函数调用栈。查找上一步骤中占用CPU较高的线程ID对应的线程号。

    gstack 54954
    

    查询结果如下所示,其中线程ID54775对应线程号是10。

    192.168.0.11:~ # gstack 54954
    Thread 10 (Thread 0x7f95a5fff710 (LWP 54775)):
    #0  0x00007f95c41d63c6 in poll () from /lib64/libc.so.6
    #1  0x0000000000d3d2d3 in WaitLatchOrSocket(Latch volatile*, int, int, long) ()
    #2  0x000000000095ed25 in XLogPageRead(XLogRecPtr*, int, bool, bool) ()
    #3  0x000000000095f6dd in ReadRecord(XLogRecPtr*, int, bool) ()
    #4  0x000000000096aef0 in StartupXLOG() ()
    #5  0x0000000000d5607a in StartupProcessMain() ()
    #6  0x00000000009e19f9 in AuxiliaryProcessMain(int, char**) ()
    #7  0x0000000000d50135 in SubPostmasterMain(int, char**) ()
    #8  0x0000000000d504ec in MainStarterThreadFunc(void*) ()
    #9  0x00007f95c79b85f0 in start_thread () from /lib64/libpthread.so.0
    #10 0x00007f95c41df84d in clone () from /lib64/libc.so.6
    #11 0x0000000000000000 in ?? ()
    

标签:20,性能,omm,gaussdb,调优,5.4,openGauss,CPU,0.0%
From: https://blog.51cto.com/shuchaoyang/9644139

相关文章

  • RAPTOR:递归摘要与树形检索的结合,提升RAG检索性能
    RAPTOR:递归摘要与树形检索的结合,提升RAG检索性能来源:ICLR'24https://arxiv.org/pdf/2401.18059.pdf随着LLM技术的发展,RAG的价值也来越明显,可以视作LLM应用、落地的一个主要方向。RAG通过结合检索系统和生成模型,在生成回答时先从外部知识库种检索相关信息,辅助LLM进行更......
  • 扒开源安卓性能测试工具moblieperf源码——开发属于你自己的性能稳定性测试工具
    moblieperf下载和使用moblieperf由阿里巴巴开源的Android性能测试工具下载:官方源码地址mobileperfgithub使用:使用pycharm打开下载的项目使用只需要修改配置文件config.conf即可运行采集:a.mac、linux在mobileperf工具根目录下执行shrun.sh;b.windows双击run.bat配置......
  • 再聊阴影裁剪与高性能视锥剔除
    【USparkle专栏】如果你深怀绝技,爱“搞点研究”,乐于分享也博采众长,我们期待你的加入,让智慧的火花碰撞交织,让知识的传递生生不息!一、实际需求因为项目的树与草都采用ComputeShader剔除的GPUInstance绘制,所以需要自己实现阴影投递物的裁剪方法。也就是每一帧具体让哪些物体绘......
  • 基于 GPU 渲染的高性能空间包围计算
    空间包围检测在计算机图形学、虚拟仿真、工业生产等有着广泛的应用。现代煤矿开采过程中,安全一直是最大的挑战之一。地质空间中存在诸多如瓦斯积聚、地质构造异常、水文条件不利等隐蔽致灾因素,一旦被触发,可能引发灾难性的后果。因此在安全生产过程中有效的管理和规避各隐蔽致灾因素......
  • 软件测试学习笔记丨性能分析系统级别指标 io cpu mem net
    io指标监控命令iostat命令描述:监控系统设备的IO负载情况命令演示:iostatio指标监控命令df命令描述:列出⽂件系统的整体磁盘空间使⽤情况命令演示:df-hcpu指标监控命令uptime命令描述:用于显示系统总共运行了多长时间和系统的平均负载命令演示:uptimecpu指标监控命令cat/......
  • 性能最接近 GPT4,开源AI模型 “泄露”
    近期开源AI社区发生了一场大事件,一位用户在HuggingFace平台上传了一系列文件,包含一个看似新的开源大型语言模型“miqu-1-70b”。这一模型被认为是最接近OpenAI的GPT-4,引发了广泛关注和猜测。不少用户则在社交平台X(原名Twitter)上分享了测试比较,miqu和Mixtral模型的能力......
  • 解密 ARMS 持续剖析:如何用一个全新视角洞察应用的性能瓶颈?
    作者:饶子昊、杨龙应用复杂度提升,根因定位困难重重随着软件技术发展迭代,很多企业软件系统也逐步从单体应用向云原生微服务架构演进,一方面让应用实现高并发、易扩展、开发敏捷度高等效果,但另外一方面也让软件应用链路变得越来越长,依赖的各种外部技术越来越多,一些线上问题排查起来变得......
  • 软件测试学习笔记丨基本性能监控系统使用
    基本性能监控系统组成Collectd+InfluxdDB+GrafanaCollectd是一个守护(daemon)进程,用来定期收集系统和应用程序的性能指标,同时提供了以不同的方式来存储这些指标值的机制;InfluxDB开源的、高性能的时序型数据库Grafana一个非常酷的数据可视化平台,常常应用于显示监控数据,支持多......
  • 解密 ARMS 持续剖析:如何用一个全新视角洞察应用的性能瓶颈?
    作者:饶子昊、杨龙应用复杂度提升,根因定位困难重重随着软件技术发展迭代,很多企业软件系统也逐步从单体应用向云原生微服务架构演进,一方面让应用实现高并发、易扩展、开发敏捷度高等效果,但另外一方面也让软件应用链路变得越来越长,依赖的各种外部技术越来越多,一些线上问题排查起来......
  • 读了啥:JVM内存调优
    读了啥周志明的深入理解Java虚拟机中的调优案例。第一个案例背景一个网站部署在JVM上,而Java堆大小固定在了12G,但是总会出现长时间无法响应的情况。使用了吞吐量优先收集器:可能是ParallelScavenge和ParallelOld收集器。问题网站直接从磁盘拷贝文档到堆内存中,文档过大导致......