kingbaseES 优化之操作系统瓶颈排查

标签：操作系统查看瓶颈 0.00 排查内存磁盘 kingbaseES CPU

针对操作系统性能瓶颈的判断和排查是数据库优化工作的一项重要技能，尤其是针对实例整体优化

操作系统的性能瓶颈排查无外乎四个方面

CPU、内存、磁盘、网络

针对这四个方面整理了一些相关心得和大家分享。

在判断系统瓶颈之前首先我们要知道操作系统资源的极限值在哪里

收集系统信息

首先CPU

我们更关心的时CPU处理线程数和使用率可以通过lscpu 收集cpu相关信息

比如：cpu型号，物理核数、NUMA节点数、厂商等等信息

[kingbase@localhost bin]$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 1
On-line CPU(s) list: 0
Thread(s) per core: 1
Core(s) per socket: 1
座： 1
NUMA 节点： 1
厂商 ID： GenuineIntel
CPU 系列： 6
型号： 126
型号名称： Intel(R) Core(TM) i5-1035G1 CPU @ 1.00GHz
步进： 5
CPU MHz： 1190.387
BogoMIPS： 2380.77
超管理器厂商： KVM
虚拟化类型：完全
L1d 缓存： 48K
L1i 缓存： 32K
L2 缓存： 512K
L3 缓存： 6144K
NUMA 节点0 CPU： 0
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc pni pclmulqdq monitor ssse3 cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase avx2 invpcid rdseed clflushopt arch_capabilities

磁盘

磁盘我们需要区分

磁盘的类型（不同磁盘类型针对的数据库参数配置和磁盘调度规则不一样）

网络

网络需要确认的就是网络带宽，有两个部分1、服务器网卡速率. 2、交换机带宽

1、ethtool 网卡可以查看速率

2、lspci -vvv | grep -i ethernet 10-Gigabit 是万兆 Gigabit 是千兆

交换机需要和客户确认，最终网络带宽以两项中的最小速率为准。

内存需要收集的就是内存大小，通过free -g top都可以查看这里就不过多讲解

在了解了服务器各个硬件的整体情况之后，下一步就是如何判断数据库运行期间的资源瓶颈可能在哪里。

瓶颈判断

--cpu瓶颈判断方法

cpu判断是否有瓶颈可以通过 top 、htop 、mpstat

首先可以通过top 执行查看CPU整体的使用情况

%Cpu(s): 1.7 us, 1.3 sy, 0.0 ni, 97.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st

关注点包括

us 普通用户cpu使用百分比

sy 系统用户cpu使用百分比

id 空闲cou百分比

wa 等待百分比

然后通过通过 top 1 或者htop 查看各个processor 的使用情况如下。查看指标和top类似

如果发现有个别processor 使用率不正常，可以使用mpstat查看

[kingbase@localhost bin]$ mpstat -P 0 2 4
Linux 3.10.0-862.el7.x86_64 (localhost.localdomain) 2023年06月16日 x86_64 (1 CPU)

11时27分31秒 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
11时27分33秒 0 1.51 0.00 1.01 0.00 0.00 0.00 0.00 0.00 0.00 97.49
11时27分35秒 0 2.02 0.00 1.01 0.00 0.00 0.00 0.00 0.00 0.00 96.97
11时27分37秒 0 1.01 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 98.99
11时27分39秒 0 1.51 0.00 1.01 0.00 0.00 0.00 0.00 0.00 0.00 97.49
平均时间: 0 1.51 0.00 0.76 0.00 0.00 0.00 0.00 0.00 0.00 97.73

一般确认CPU存在问题的情况如下

1、us+sy使用率90%以上但是 wait占比超高95% ，说明cpu 队列中有严重的等待

2、sys使用超过了95%，数据库用户使用率只有5%不到，说明操作系统正在频繁的进行操作。严重损耗了COU资源

针对这些情况，我们下一步可以通过perf top 查看以下系统现在的热点函数，根据热点函数确认系统正在进行的操作，然后进行进一步优化。

--IO是否有瓶颈判断方法

IO判断指令也有很多，但是指标基本一样，这里以iostat为例

iostat -x 1 --每隔1秒钟打印IO情况

比较重要的参数分析指标：

• %util：io 的使用率，主要看是否已经接近或者超过 100%

如果%util 接近 100%，说明产生的 I/O 请求太多，I/O 系统已经满负荷，该磁盘可能存在瓶颈。

• svctm: 时间，主要说明磁盘本身的读写性能快慢，比如 tpcc 测试一般盘阵服务时间在 0.25ms 左右。如果太大那就是磁盘性能问题，不过 CPU/内存的负荷也会对其有点影响。

• await: 主要说明平均每次 IO 响应时间，一般小于 5ms。

– 其中 svctm 一般要小于 await (因为等待时间会算入 svctm)，await 的大小一般取决于服务时间 (svctm)

以及 I/O 队列的长度（avgqu-sz）和 I/O 请求的发出模式。

– 如果 svctm 比较接近 await，说明 I/O 几乎没有等待时间；

– 如果 await 远大于 svctm，说明 I/O 队列太长，应用得到的响应时间变慢。

– 如果响应时间超过了用户可以容许的范围，这时可以考虑更换更快的磁盘，调整内核 IO 调度的

elevator 算法，优化应用，或者升级 CPU。

– 例如：对于 tpcc 一般采用 deadline 方式比较合适（IO 调度算法默认是 cfq）

针对机械盘建议采用 deadline 算法。

固态盘采用NOOP算法。

iotop指令可以看到当前操作系统有哪些线程再进行io操作，再iostat确认IO到瓶颈后，我们可以通过iotop查看具体的操作。

常用指令：iotop -o

相同功能指令还有

pidstat -dl -U kingbase -p ALL 1

pidstat -d -l -p ALL 1 |grep kingbase

--网络情况分析方法

sar -n DEV 1 --查看网络传输速率等信息

sar -n EDEV 1 --查看网络传输失败情况

主要分析：

• 查看 rxbyt/s 和 txbyt/s 的收发字节数是否已经达到了瓶颈。需要注意的是，网络的性能取决于源端和目的端以及中间设备（网线、路由器、交换机等）的整体表现。例如：源端和目的端都是千兆网卡，但是它们之间的交换机为百兆，则两端的网络传输上限只能是百兆。为了更准确的了解网络性能的真实表现，可以通过 scp 或者 iperf 来做测试。

--内存瓶颈分析方法

在操作系统层面我们主要分析是否是用到了swap

常用指令top

主要分析：

• swap 是否被使用，如果使用了那就会拖累性能，消耗 cpu 和 io 时间。例如：测试 tpcc 时有几个 g 的 swap 使用，导致峰值上不去，然后调整了 shared_buffers，变小一些, 然后就不用交换分区了，然后峰值就上去了。原因是一些临时的数据可能比较多的情况，然后放不下内存就用了交换分区。

• 空闲内存是否比较少，一般来说如果空闲内存/物理内存 >70%，内存性能优，如果小于 20%，则性能差，需要添加内存。

• 如果内存用的很少，查询比较慢, 而且数据量很大，并且很多 io，那可以考虑调大 shared_buffers, 提高命中率。

数据库层面给也有相关视图

针对命中率的视图可以查看

全局对象的sys_stdio_user_tables和 sys_stdio_user_indexes

如果确认了慢sql可以查看 sys_stat_statements

这里主要以介绍操作系统层面性能问题查看方法为主，数据库层面如何排查性能问题将会在后续文章中整理

标签：操作系统,查看,瓶颈,0.00,排查,内存,磁盘,kingbaseES,CPU
From： https://www.cnblogs.com/kingbase/p/17561104.html