首页 > 其他分享 >想要硬件设备更快，你需要了解这些性能问题！

想要硬件设备更快，你需要了解这些性能问题！

时间：2023-04-29 23:32:51浏览次数：48  
标签：20 0.0 性能 CPU 硬件 Setting 想要 root cpu

1 前言

完整的性能分析案例的第一部分，打开首页接口做压力场景，分析性能问题。将看到各种基础硬件设施层面的性能问题，如由虚机超分导致的性能问题、CPU运行模式下的性能问题、IO高、硬件资源耗尽但TPS很低的问题等。

如你从零开始做一个完整项目，这些问题很可能是你首先要面对的。把它们解决好，是性能分析人员必备的一种能力。不同计数器采集的数据，分析链路不同，而这个分析链路就是我一直强调的证据链。

有些性能问题其实并没有那么单一，而且不管性能问题出在哪里，都必须处理。

2 架构图

每次分析性能瓶颈前，都画这图，看该接口涉及哪些服务和技术组件，对性能分析会有大帮助。

想要硬件设备更快，你需要了解这些性能问题！_List

可清楚看到打开首页的逻辑：User - Gateway(Redis)- Portal - (Redis,MySQL)。

3 代码逻辑

做打开首页的基准场景前，先看接口的代码实现逻辑，从代码可见接口在做哪些。根据这些动作，可分析它们的后续链路。

代码逻辑简单，就是列出首页上的各种信息，然后返回一个JSON。

public HomeContentResult contentnew() {
         HomeContentResult result = new HomeContentResult();
         if (redisService.get("HomeContent") == null) {
             //首页广告
             result.setAdvertiseList(getHomeAdvertiseList());
             //品牌推荐
             result.setBrandList(homeDao.getRecommendBrandList(0, 6));
             //秒杀信息
             result.setHomeFlashPromotion(getHomeFlashPromotion());
             //新品推荐
             result.setNewProductList(homeDao.getNewProductList(0, 4));
             //人气推荐
             result.setHotProductList(homeDao.getHotProductList(0, 4));
             //专题推荐
             result.setSubjectList(homeDao.getRecommendSubjectList(0, 4));
             redisService.set("HomeContent", result);
         }
         Object homeContent = redisService.get("HomeContent");
         // result = JSON.parseObject(homeContent.toString(), HomeContentResult.class);
         result = JSONUtil.toBean(JSONUtil.toJsonPrettyStr(homeContent), HomeContentResult.class);
 
         return result;
 }

共调用6个方法，都是直接到数据库里做查询而已。

4 确定压力数据

上10个线程试运行，看在一个个线程递增过程中，TPS趋势。运行后的结果：

想要硬件设备更快，你需要了解这些性能问题！_List_02

可见，一开始，一个线程会产生40 TPS。请思考：若执行一个场景，且该场景能压出打开首页接口的最大TPS，应如何持续执行策略呢？

对此，先看Portal应用节点所在机器的硬件使用情况，了解TPS趋势和资源使用率的关系。该机器的情况如下（我跳过了Gateway所在节点）：

想要硬件设备更快，你需要了解这些性能问题！_List_03

可见，当前Portal节点所在机器8C 16G（虚拟机），且该机器基本无压力。

4.1 确定压力工具的线程数

先不计算其他资源，只考虑8C 16G。若TPS线性增长，则当该机器CPU使用率达 100%时，TPS大概就800。因此，压力工具中的线程数应置：

想要硬件设备更快，你需要了解这些性能问题！_响应时间_04

因为压力过程中，各种资源消耗都会增加一些响应时间，TPS和资源使用率间的等比关系应该做不到。这些也都属于正常的响应时间损耗。

4.2 递增策略如何设置

希望递增时间能增加得慢些，以便查看各环节性能数据的反应。根据性能分析决策树，这样的场景，不少计数器需分析查看，所以设置30s上一个线程，即递增周期600s。

确定压力参数后，试运行场景就能在JMeter置如下值：

<stringProp name="ThreadGroup.num_threads">20</stringProp>
         <stringProp name="ThreadGroup.ramp_time">600</stringProp>
         <boolProp name="ThreadGroup.scheduler">true</boolProp>
         <stringProp name="ThreadGroup.duration">700</stringProp>

置好试运行参数后，就可在这样场景进一步设置足够线程来运行，以达到资源使用率最大化。

难道不用更高的线程？

  • 若你想做正常场景，确实无需用更高线程
  • 若你就是想知道压力线程加多会咋样，那你能试试。我在性能场景执行时，也经常各种方式压着玩

但确实有个情况要我们真的增加更多压力：你的响应时间已增加了，可加得又不多，TPS也不再上升。这时，拆分响应时间较难，特别是当一些系统很快时，响应时间可能只是几ms间。就要多加线程，让响应时间慢的地方更清晰表现，也就更易拆分时间。

通过压力场景的递增设置（前面算的只需20个线程即可达到最大值，而这，我把压力线程置100启动场景，是为了看到递增到更大压力时的TPS趋势及响应时间的增加，更易做时间拆分），我们看到接口响应时间确实在慢慢增加，且随线程数增加，响应时间很快上升到几百ms。这是个明显瓶颈，自然不能接受。

想要硬件设备更快，你需要了解这些性能问题！_sed_05

来分析这响应时间究竟消耗在哪。

5 拆分时间

就按打开首页的逻辑：User - Gateway(Redis)- Portal - (Redis,MySQL)，借助SkyWalking把响应时间具体拆分：

想要硬件设备更快，你需要了解这些性能问题！_响应时间_06

User —Gateway之间的时间消耗：

想要硬件设备更快，你需要了解这些性能问题！_List_07

User - Gateway之间的时间消耗慢慢上升到150ms左右。

Gateway响应时间：

想要硬件设备更快，你需要了解这些性能问题！_响应时间_08

gateway上也消耗150ms，说明user到gateway间的网络并无多少时间消耗，在ms级。

Gateway —Portal之间的时间消耗：

想要硬件设备更快，你需要了解这些性能问题！_sed_09

在Portal上，响应时间只消耗50ms左右。再到Portal看下。

Portal响应时间：

想要硬件设备更快，你需要了解这些性能问题！_List_10

Portal响应时间50ms左右，和上面看到的时间一致。

通过上述对响应时间的拆分，可确定是Gateway消耗了响应时间，并且这时间达到近100ms。

下一步定位目标就是Gateway。

6 定位Gateway上的响应时间消耗

6.1 第一阶段：分析st cpu

既然Gateway响应时间消耗高，就查这台主机把时间消耗在哪了。

分析逻辑仍是：

  • 先看全局监控
  • 后看定向监控

全局监控要从架构开始看起，再确定某节点的资源消耗。看全局监控时，从最基础查起，而分析过程中最基础的就是os。

top看到Gateway节点的资源情况：

想要硬件设备更快，你需要了解这些性能问题！_List_11

st cpu。st cpu指虚拟机被宿主机上的其他应用或虚拟机抢走的CPU，高达15%，得查看st cpu异常原因。

mpstat看宿主机（运行Gateway的虚拟机所在的物理机）上的资源表现：

想要硬件设备更快，你需要了解这些性能问题！_List_12

可见CPU还有20%没有用完，说明宿主机还有空间。不过，宿主机的CPU使用率已经不小了，而消耗这些宿主机的就只有虚拟机里的应用。所以，我们要查一下是不是某个虚拟机的CPU消耗特别高。宿主机上的KVM列表如下：

[root@dell-server-3 ~]# virsh list --all
  Id    名称                         状态
 ----------------------------------------------------
  12    vm-jmeter                      running
  13    vm-k8s-worker-8                running
  14    vm-k8s-worker-7                running
  15    vm-k8s-worker-9                running
 
 [root@dell-server-3 ~]#

可以看到，在这个宿主机上跑了四个虚拟机，那我们就具体看一下这四个虚拟机的资源消耗情况。

  • vm-jmeter
top - 23:42:49 up 28 days,  8:14,  6 users,  load average: 0.61, 0.48, 0.38
 Tasks: 220 total,   1 running, 218 sleeping,   1 stopped,   0 zombie
 %Cpu0  :  6.6 us,  3.5 sy,  0.0 ni, 88.5 id,  0.0 wa,  0.0 hi,  0.0 si,  1.4 st
 %Cpu1  :  6.5 us,  1.8 sy,  0.0 ni, 88.2 id,  0.0 wa,  0.0 hi,  0.4 si,  3.2 st
 KiB Mem :  3880180 total,   920804 free,  1506128 used,  1453248 buff/cache
 KiB Swap:  2097148 total,  1256572 free,   840576 used.  2097412 avail Mem 
 
   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                  
  7157 root      20   0 3699292 781204  17584 S  27.8 20.1   1:09.44 java                                                                                                                     
     9 root      20   0       0      0      0 S   0.3  0.0  30:25.77 rcu_sched                                                                                                                
   376 root      20   0       0      0      0 S   0.3  0.0  16:40.44 xfsaild/dm-
  • vm-k8s-worker-8
top - 23:43:47 up 5 days, 22:28,  3 users,  load average: 9.21, 6.45, 5.74
 Tasks: 326 total,   1 running, 325 sleeping,   0 stopped,   0 zombie
 %Cpu0  : 20.2 us,  3.7 sy,  0.0 ni, 60.7 id,  0.0 wa,  0.0 hi,  2.9 si, 12.5 st
 %Cpu1  : 27.3 us,  7.4 sy,  0.0 ni, 50.2 id,  0.0 wa,  0.0 hi,  3.7 si, 11.4 st
 %Cpu2  : 29.9 us,  5.6 sy,  0.0 ni, 48.5 id,  0.0 wa,  0.0 hi,  4.9 si, 11.2 st
 %Cpu3  : 31.2 us,  5.6 sy,  0.0 ni, 47.6 id,  0.0 wa,  0.0 hi,  4.5 si, 11.2 st
 %Cpu4  : 25.6 us,  4.3 sy,  0.0 ni, 52.7 id,  0.0 wa,  0.0 hi,  3.6 si, 13.7 st
 %Cpu5  : 26.0 us,  5.2 sy,  0.0 ni, 53.5 id,  0.0 wa,  0.0 hi,  4.1 si, 11.2 st
 %Cpu6  : 19.9 us,  6.2 sy,  0.0 ni, 57.6 id,  0.0 wa,  0.0 hi,  3.6 si, 12.7 st
 %Cpu7  : 27.3 us,  5.0 sy,  0.0 ni, 53.8 id,  0.0 wa,  0.0 hi,  2.3 si, 11.5 st
 KiB Mem : 16265688 total,  6772084 free,  4437840 used,  5055764 buff/cache
 KiB Swap:        0 total,        0 free,        0 used. 11452900 avail Mem 
 
   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                  
 13049 root      20   0 9853712 593464  15752 S 288.4  3.6  67:24.22 java                                                                                                                     
  1116 root      20   0 2469728  57932  16188 S  12.6  0.4 818:40.25 containerd                                                                                                               
  1113 root      20   0 3496336 118048  38048 S  12.3  0.7 692:30.79 kubelet                                                                                                                  
  4961 root      20   0 1780136  40700  17864 S  12.3  0.3 205:51.15 calico-node                                                                                                              
  3830 root      20   0 2170204 114920  33304 S  11.6  0.7 508:00.00 scope                                                                                                                    
  1118 root      20   0 1548060 111768  29336 S  11.3  0.7 685:27.95 dockerd                                                                                                                  
  8216 techstar  20   0 2747240 907080 114836 S   5.0  5.6   1643:33 prometheus                                                                                                               
 21002 root      20   0 9898708 637616  17316 S   3.3  3.9 718:56.99 java                                                                                                                     
  1070 root      20   0 9806964 476716  15756 S   2.0  2.9 137:13.47 java                                                                                                                     
 11492 root      20   0  441996  33204   4236 S   1.3  0.2  38:10.49 gvfs-udisks2-vo
  • vm-k8s-worker-7
top - 23:44:22 up 5 days, 22:26,  3 users,  load average: 2.50, 1.67, 1.13
 Tasks: 308 total,   1 running, 307 sleeping,   0 stopped,   0 zombie
 %Cpu0  :  4.2 us,  3.5 sy,  0.0 ni, 82.3 id,  0.0 wa,  0.0 hi,  1.7 si,  8.3 st
 %Cpu1  :  6.2 us,  2.7 sy,  0.0 ni, 82.8 id,  0.0 wa,  0.0 hi,  1.4 si,  6.9 st
 %Cpu2  :  5.2 us,  2.8 sy,  0.0 ni, 84.0 id,  0.0 wa,  0.0 hi,  1.0 si,  6.9 st
 %Cpu3  :  4.5 us,  3.8 sy,  0.0 ni, 81.2 id,  0.0 wa,  0.0 hi,  1.4 si,  9.2 st
 %Cpu4  :  4.4 us,  2.4 sy,  0.0 ni, 83.3 id,  0.0 wa,  0.0 hi,  1.4 si,  8.5 st
 %Cpu5  :  5.5 us,  2.4 sy,  0.0 ni, 84.5 id,  0.0 wa,  0.0 hi,  1.0 si,  6.6 st
 %Cpu6  :  3.7 us,  2.7 sy,  0.0 ni, 85.6 id,  0.0 wa,  0.0 hi,  0.7 si,  7.4 st
 %Cpu7  :  3.1 us,  1.7 sy,  0.0 ni, 84.7 id,  0.0 wa,  0.0 hi,  1.4 si,  9.0 st
 KiB Mem : 16265688 total,  8715820 free,  3848432 used,  3701436 buff/cache
 KiB Swap:        0 total,        0 free,        0 used. 12019164 avail Mem 
 
   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                  
 18592 27        20   0 4588208 271564  12196 S  66.9  1.7 154:58.93 mysqld                                                                                                                   
  1109 root      20   0 2381424 105512  37208 S   9.6  0.6 514:18.00 kubelet                                                                                                                  
  1113 root      20   0 1928952  55556  16024 S   8.9  0.3 567:43.53 containerd                                                                                                               
  1114 root      20   0 1268692 105212  29644 S   8.6  0.6 516:43.38 dockerd                                                                                                                  
  3122 root      20   0 2169692 117212  33416 S   7.0  0.7 408:21.79 scope                                                                                                                    
  4132 root      20   0 1780136  43188  17952 S   6.0  0.3 193:27.58 calico-node                                                                                                              
  3203 nfsnobo+  20   0  116748  19720   5864 S   2.0  0.1  42:43.57 node_exporter                                                                                                            
 12089 techstar  20   0 5666480   1.3g  23084 S   1.3  8.5  78:04.61 java                                                                                                                     
  5727 root      20   0  449428  38616   4236 S   1.0  0.2  49:02.98 gvfs-udisks2-vo
  • vm-k8s-worker-9
top - 23:45:23 up 5 days, 22:21,  4 users,  load average: 12.51, 10.28, 9.19
 Tasks: 333 total,   4 running, 329 sleeping,   0 stopped,   0 zombie
 %Cpu0  : 20.1 us,  7.5 sy,  0.0 ni, 43.3 id,  0.0 wa,  0.0 hi, 13.4 si, 15.7 st
 %Cpu1  : 20.1 us, 11.2 sy,  0.0 ni, 41.4 id,  0.0 wa,  0.0 hi, 11.9 si, 15.3 st
 %Cpu2  : 23.8 us, 10.0 sy,  0.0 ni, 35.4 id,  0.0 wa,  0.0 hi, 14.2 si, 16.5 st
 %Cpu3  : 15.1 us,  7.7 sy,  0.0 ni, 49.1 id,  0.0 wa,  0.0 hi, 12.2 si, 15.9 st
 %Cpu4  : 22.8 us,  6.9 sy,  0.0 ni, 40.5 id,  0.0 wa,  0.0 hi, 14.7 si, 15.1 st
 %Cpu5  : 17.5 us,  5.8 sy,  0.0 ni, 50.0 id,  0.0 wa,  0.0 hi, 10.6 si, 16.1 st
 %Cpu6  : 22.0 us,  6.6 sy,  0.0 ni, 45.1 id,  0.0 wa,  0.0 hi, 11.0 si, 15.4 st
 %Cpu7  : 19.2 us,  8.0 sy,  0.0 ni, 44.9 id,  0.0 wa,  0.0 hi,  9.8 si, 18.1 st
 KiB Mem : 16265688 total,  2567932 free,  7138952 used,  6558804 buff/cache
 KiB Swap:        0 total,        0 free,        0 used.  8736000 avail Mem 
 
   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                  
 24122 root      20   0 9890064 612108  16880 S 201.0  3.8   1905:11 java                                                                                                                     
  2794 root      20   0 2307652 161224  33464 S  57.7  1.0   1065:54 scope                                                                                                                    
  1113 root      20   0 2607908  60552  15484 S  13.8  0.4   1008:04 containerd                                                                                                               
  1109 root      20   0 2291748 110768  39140 S  12.8  0.7 722:41.17 kubelet                                                                                                                  
  1114 root      20   0 1285500 108664  30112 S  11.1  0.7 826:56.51 dockerd                                                                                                                  
    29 root      20   0       0      0      0 S   8.9  0.0  32:09.89 ksoftirqd/4                                                                                                              
     6 root      20   0       0      0      0 S   8.2  0.0  41:28.14 ksoftirqd/0                                                                                                              
    24 root      20   0       0      0      0 R   8.2  0.0  41:00.46 ksoftirqd/3                                                                                                              
    39 root      20   0       0      0      0 R   8.2  0.0  41:08.18 ksoftirqd/6                                                                                                              
    19 root      20   0       0      0      0 S   7.9  0.0  39:10.22 ksoftirqd/2                                                                                                              
    14 root      20   0       0      0      0 S   6.2  0.0  40:58.25 ksoftirqd/1

很显然，worker-9的si（中断使用的CPU）和st（被偷走的CPU）都不算低。那这种情况就比较奇怪了，虚拟机本身都没有很高的CPU使用率，为什么st还这么高呢？难道CPU只能用到这种程度？

接着查。

第二阶段：查看物理机CPU运行模式

在这个阶段，我们要查一下服务里有没有阻塞。就像前面提到的，我们要从全局监控的角度，来考虑所查看的性能分析计数器是不是完整，以免出现判断上的偏差。不过，我去查看了线程栈的具体内容，看到线程栈中并没有Blocked啥的，那我们就只能再回到物理机的配置里看了。

那对于物理机CPU，我们还有什么可看的呢？即使你盖上被子蒙着头想很久，从下到上把所有的逻辑都理一遍，也找不出什么地方会有阻塞。那我们就只有看宿主机的CPU运行模式了。

-- 物理机器1
 [root@hp-server ~]# cpupower frequency-info
 analyzing CPU 0:
   driver: pcc-cpufreq
   CPUs which run at the same hardware frequency: 0
   CPUs which need to have their frequency coordinated by software: 0
   maximum transition latency:  Cannot determine or is not supported.
   hardware limits: 1.20 GHz - 2.10 GHz
   available cpufreq governors: conservative userspace powersave ondemand performance
   current policy: frequency should be within 1.20 GHz and 2.10 GHz.
                   The governor "conservative" may decide which speed to use
                   within this range.
   current CPU frequency: 1.55 GHz (asserted by call to hardware)
   boost state support:
     Supported: yes
     Active: yes
 
 -- 物理机器2
 [root@dell-server-2 ~]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
 powersave
 [root@dell-server-2 ~]# cpupower frequency-info
 analyzing CPU 0:
   driver: intel_pstate
   CPUs which run at the same hardware frequency: 0
   CPUs which need to have their frequency coordinated by software: 0
   maximum transition latency:  Cannot determine or is not supported.
   hardware limits: 1.20 GHz - 2.20 GHz
   available cpufreq governors: performance powersave
   current policy: frequency should be within 1.20 GHz and 2.20 GHz.
                   The governor "powersave" may decide which speed to use
                   within this range.
   current CPU frequency: 2.20 GHz (asserted by call to hardware)
   boost state support:
     Supported: no
     Active: no
     2200 MHz max turbo 4 active cores
     2200 MHz max turbo 3 active cores
     2200 MHz max turbo 2 active cores
     2200 MHz max turbo 1 active cores
 
 -- 物理机器3
 [root@dell-server-3 ~]# cpupower frequency-info
 analyzing CPU 0:
   driver: intel_pstate
   CPUs which run at the same hardware frequency: 0
   CPUs which need to have their frequency coordinated by software: 0
   maximum transition latency:  Cannot determine or is not supported.
   hardware limits: 1.20 GHz - 2.20 GHz
   available cpufreq governors: performance powersave
   current policy: frequency should be within 1.20 GHz and 2.20 GHz.
                   The governor "powersave" may decide which speed to use
                   within this range.
   current CPU frequency: 2.20 GHz (asserted by call to hardware)
   boost state support:
     Supported: no
     Active: no
     2200 MHz max turbo 4 active cores
     2200 MHz max turbo 3 active cores
     2200 MHz max turbo 2 active cores
     2200 MHz max turbo 1 active cores
 
 -- 物理机器4
 [root@lenvo-nfs-server ~]# cpupower frequency-info
 analyzing CPU 0:
   driver: acpi-cpufreq
   CPUs which run at the same hardware frequency: 0
   CPUs which need to have their frequency coordinated by software: 0
   maximum transition latency: 10.0 us
   hardware limits: 2.00 GHz - 2.83 GHz
   available frequency steps:  2.83 GHz, 2.00 GHz
   available cpufreq governors: conservative userspace powersave ondemand performance
   current policy: frequency should be within 2.00 GHz and 2.83 GHz.
                   The governor "conservative" may decide which speed to use
                   within this range.
   current CPU frequency: 2.00 GHz (asserted by call to hardware)
   boost state support:
     Supported: no
     Active: no

没有一个物理机是运行在performance模式。

CPU运行模式

想要硬件设备更快，你需要了解这些性能问题！_List_13

既然我们是性能分析人员，那自然要用performance模式了，所以我们把CPU模式修改如下：

-- 物理机器1
 [root@hp-server ~]# cpupower -c all frequency-set -g performance
 Setting cpu: 0
 Setting cpu: 1
 Setting cpu: 2
 Setting cpu: 3
 Setting cpu: 4
 Setting cpu: 5
 Setting cpu: 6
 Setting cpu: 7
 Setting cpu: 8
 Setting cpu: 9
 Setting cpu: 10
 Setting cpu: 11
 Setting cpu: 12
 Setting cpu: 13
 Setting cpu: 14
 Setting cpu: 15
 Setting cpu: 16
 Setting cpu: 17
 Setting cpu: 18
 Setting cpu: 19
 Setting cpu: 20
 Setting cpu: 21
 Setting cpu: 22
 Setting cpu: 23
 Setting cpu: 24
 Setting cpu: 25
 Setting cpu: 26
 Setting cpu: 27
 Setting cpu: 28
 Setting cpu: 29
 Setting cpu: 30
 Setting cpu: 31
 [root@hp-server ~]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
 performance
 [root@hp-server ~]#
 
 -- 物理机器2
 [root@dell-server-2 ~]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
 powersave
 [root@dell-server-2 ~]# cpupower -c all frequency-set -g performance
 Setting cpu: 0
 Setting cpu: 1
 Setting cpu: 2
 Setting cpu: 3
 Setting cpu: 4
 Setting cpu: 5
 Setting cpu: 6
 Setting cpu: 7
 Setting cpu: 8
 Setting cpu: 9
 Setting cpu: 10
 Setting cpu: 11
 Setting cpu: 12
 Setting cpu: 13
 Setting cpu: 14
 Setting cpu: 15
 [root@dell-server-2 ~]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
 performance
 [root@dell-server-2 ~]#
 
 -- 物理机器3
 [root@dell-server-3 ~]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
 powersave
 [root@dell-server-3 ~]#  cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
 powersave
 [root@dell-server-3 ~]# cpupower -c all frequency-set -g performance
 Setting cpu: 0
 Setting cpu: 1
 Setting cpu: 2
 Setting cpu: 3
 Setting cpu: 4
 Setting cpu: 5
 Setting cpu: 6
 Setting cpu: 7
 Setting cpu: 8
 Setting cpu: 9
 Setting cpu: 10
 Setting cpu: 11
 Setting cpu: 12
 Setting cpu: 13
 Setting cpu: 14
 Setting cpu: 15
 [root@dell-server-3 ~]#  cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
 performance
 [root@dell-server-3 ~]#
 
 -- 物理机器4
 [root@lenvo-nfs-server ~]# cpupower -c all frequency-set -g performance
 Setting cpu: 0
 Setting cpu: 1
 Setting cpu: 2
 Setting cpu: 3
 [root@lenvo-nfs-server ~]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
 performance
 [root@lenvo-nfs-server ~]#

在我们一顿操作猛如虎之后，性能会怎么样呢？

结果，性能并没有好起来，因为图和一开始的那张场景运行图一样。

在这里我们要知道，以上的分析过程说明不止是这个问题点，还有其他资源使用有短板我们没有找到。没办法，我们只能接着查。

总结

通过压力工具中的曲线，判断瓶颈存在。然后通过SkyWalking拆分响应时间。

在确定了响应时间消耗点之后，我们又开始了两个阶段的分析：第一个阶段的证据链是从现象开始往下分析的，因为st cpu是指宿主机上的其他应用的消耗导致了此虚拟机的cpu资源被消耗，所以，我们去宿主机上去查了其他的虚拟机。这里我们要明确CPU资源应该用到什么样的程度，在发现了资源使用不合理之后，再接着做第二阶段的判断。

在第二阶段中，我们判断了CPU运行模式。在物理机中，如果我们自己不做主动的限制，CPU的消耗是没有默认限制的，所以我们才去查看CPU的运行模式。

但是，即便我们分析并尝试解决了以上的问题，TPS仍然没什么变化。可见，在计数器的分析逻辑中，虽然我们做了优化动作，但系统仍然有问题。只能说我们当前的优化手段，只解决了木桶中的最短板，但是其他短板，我们还没有找到。

这些问题不解决，下一个问题也不会出现。所以，本文的分析优化过程也很有价值。

FAQ

  1. 为什么我们看到虚拟机中st cpu高，就要去查看宿主机上的其他虚拟机？如果在宿主机上看到st cpu高，我们应该做怎样的判断？
  2. CPU的运行模式在powersave时，CPU的运行逻辑是什么？

“只考虑 8C16G 的配置情况。如果 TPS 是线性增长的话，那么当该机器的 CPU 使用率达到 100% 的时候，TPS 大概就是 800 左右。”这里的TPS 800是怎么得到的？

根据资源来计算的。因为40TPS时，图上面的CPU使用率，也才5%左右，要用到100%的话，不是有20倍吗？所以是40x20。

全局监控、定向监控，这个监控的时机是怎么把握的？是跑脚本之前，将两者都监控起来。发现性能问题，先看全局监控，再去看定向监控？

先做全局监控就可以 。

标签：20,0.0,性能,CPU,硬件,Setting,想要,root,cpu
From： https://blog.51cto.com/u_11440114/6237181

相关文章

  • 年轻人，想要学到答案，请先学会提问
    本文不想指责谁，而是传授一些个人经验，帮助你更容易得到答案，如果你经常发现问题问了没人理，那可能不是社区的问题，而是你的提问方法的问题。其实，注明黑客Raymond老早之前就写过一篇文章《提问的智慧》，被翻译成了很多语言，中文简体的版本在这里：https://github.com/ryanhanwu/How-To-Ask......
  • HPL：多进程CPU性能测试
    使用HPL进行CPU性能测试CPU型号为：AMDRyzen75800H，本次实验使用两台Linux虚拟机测试，每个虚拟机分配一个CPU。理论浮点峰值＝CPU主频×CPU核数×CPU每周期执行浮点运算的次数本机CPU的基准频率为3.2GHZ，加速频率为4.4GHZghz。CPU有8核16线程（一个核虚拟成2个CPU），CPU单个周期浮点计算......
  • efcore性能调优
    性能调优——EFCore调优按下硬件、网络不提，我们单表从程序层面对系统的性能进行优化，翻来覆去无外乎三个方面缓存异步sql本片文章，我们针对.netcoreweb项目的efcore框架进行性能优化。1.EFCore框架已经本地缓存机制memorycache，所以我们访问一个接口，二次访......
  • 分类模型的性能评估指标总结
    机器学习中所用模型的好坏需要通过一些量化的指标来评估。对于分类模型，是通过：1）精度（Accuracy）；2）准确率（Precision）；3）召回率（Recall）；4）F1分数；5）ROC（Receiveroperatingcharacteristiccurve）曲线；6）AUC（AreaUnderCurve）曲线来实现的。二分类模型对于二分类问题，通常将两个类别称为正类和负类。......
  • 【性能】JDK和Jmeter的安装与配置
    一、JDK环境配置1.下载JDK官网下载地址：http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-javase7-521261.html    选择对应系统的安装包，下载后安装，安装中记录JDK安装的地址，之后一直点击下一步到完成就可以。2.配置JDK环境 ......
  • 关于json文件想要添加注释怎么处理
    json格式本身不支持注释，json的本意就是极简的通用数据传输。加了备注就不是极简了。1.注释用来说明这个key做什么用2.希望添加注释之后，不会影响原本的交互逻辑。比较好的方法是：json文件里面额外增加一个key"key_comment"用来描述这个key的作用。但是如果本来json文件只是一个......
  • 十个最好的Java性能故障排除工具
    推荐十个最好的Java性能故障排除工具：1.jconsole是随着JDK1.5而推出的。这是一个Java监测和管理控制台-JMX兼容的图形工具来监测Java虚拟机。它能够同时监测本地和远程的JVMs。详情可查看：jconsole工具介绍2.VisualVM集成了几个现有的JDK软件工具，轻量级内存和CPU信息概要能力。......
  • Core i7正式揭开面纱 性能完全测试
    虽然要到本月17日才会正式发布,但IntelCorei7系列四核心处理器的NDA保密协议已于今天中午到期,日本PCWatch再次凭借时差优势第一个发布了完整的评测.有关Corei7系列我们已经相当熟悉了.它们基于Intel的新一代微架构Nehalem,开发代号Bloomfield,首批登场的将有三款型号,具体规......
  • Java程序性能优化
    一、避免在循环条件中使用复杂表达式在不做编译优化的情况下，在循环中，循环条件会被反复计算，如果不使用复杂表达式，而使循环条件值不变的话，程序将会运行的更快。例子：importjava.util.Vector;classCEL{voidmethod(Vectorvector){for(inti=0;i<vector.si......
  • Linux基础17 运维核心职责与工作内容, 服务器介绍, 硬件介绍, 系统介绍, 机房介绍
    运维的核心职责1.数据不丢失。 2.业务7*24小时运行(不宕机) 3.提升用户体验度（性能的优化）2.运维的平时工作内容 1.日常服务器的维护，紧急故障的处理。 2.代码上线，gitlab+Jenkins。shell脚本。 3.项目：备份、迁移、升级。rsync 4.日常服务器监控，zabbix 5.梳理总结文档。画图。 6.领......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99