如何查看KingbaseES数据库占用操作系统内存情况

当遇到数据库内存告警,并且操作系统内存使用不足,需要分析内存占用的方法。

KingbaseES数据库使用操作系统缓存机制,大量的内存很可能被BUFFER/CACHE占用了。

从free命令可以看到总共有2.5G多内存,使用了291MB,free剩下1.7GB多,BUFF/CACHE占了474MB。available有1.3GB多,当前这台数据库服务器的内存是充足的。
从这个例子上,我们看free命令结果的时候,不应该只关注free,看available更为准确。
因为,free是未使用过的物理内存,而available是可提供数据库使用的内存总量,如下,如果 free>available则认为free内存是可用内存。反之则用公式,available = free + buff/chche

[root@localhost ~]# free -mt
              total        used        free      shared  buff/cache   available
Mem:           2542         291        1776         113         474        1322
Swap:          2815           0        2815
Total:         5358         291        4592

cat /proc/meminfo可以更详细的看到OS的内存情况,我们可以关注MemFree,MemAvailable,Dirty,PageTables,AnonHugePages。
Dirty是FILE CACHE中尚未写入磁盘的脏数据,如果这个指标持续较高,那么说明OS的回写机制或者磁盘存在性能问题,需要检测磁盘写效率。 PageTalbes如果比较大,对于数据库来说,很可能是配置了较大的shared_buffers,而且没有启用HugePages,这时候hugepages的作用就凸显出来了,hugepages通常是2MB,使用大页可以减少内存碎片。
AnonHugePages指标大于零说明没有关闭透明大页,已经使用了透明大页,对于KingbaseES、Oracle等数据库来说,
透明大页的缺点明显,会引起内存碎片,建议关闭。我们还需要关注的是SWAP的使用率,如果FREE内存很大,但是SWAP使用率超过20%,很可能是OS的NUMA方面的配置不正确,没有全局分配内存。
如果KingbaseES数据库所在服务器的空闲内存不足,首先通过这些机制分析OS内存是否真的存在问题,如果存在问题,我们还可以继续在OS层面查找并改正配置。另外内存不足问题有时候需要结合查看操作系统日志。

[root@localhost ~]# cat /proc/meminfo
MemTotal: 2603040 kB
MemFree: 1819084 kB
MemAvailable: 1353924 kB
Buffers: 1368 kB
Cached: 432656 kB
SwapCached: 0 kB
Active: 268764 kB
Inactive: 391776 kB
Active(anon): 228484 kB
Inactive(anon): 114104 kB
Active(file): 40280 kB
Inactive(file): 277672 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 2883580 kB
SwapFree: 2883580 kB
Dirty: 20 kB
Writeback: 0 kB
AnonPages: 226564 kB
Mapped: 198536 kB
Shmem: 116072 kB
Slab: 51380 kB
SReclaimable: 31712 kB
SUnreclaim: 19668 kB
KernelStack: 4256 kB
PageTables: 19132 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 4185100 kB
Committed_AS: 2031324 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 12624 kB
VmallocChunk: 34359720960 kB
HardwareCorrupted: 0 kB
AnonHugePages: 67584 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 53184 kB
DirectMap2M: 2775040 kB

如果存在服务器内存所剩无几,可以使用如下命令查出rss使用最高的20个进程

ps -aux --sort -rss | head -20

然后找出内存使用率高的进程查看,通过进程号在数据库中查看是否对应会话正在执行复杂sql或内存溢出或其他原因。
查看有性能问题的sql执行计划,判断是否有必要进行调优。
通过如下语句查看数据库会话信息

select * from sys_stat_activity where pid=''

如果大量进程都占用差不多的内存,很可能是数据库并发执行某个或某类sql。
这时候需要排查是否某类sql或某条sql并发量太大,同时使用了排序等占用内存太大。

VSS(virtual set size)虚拟内存(包含共享库占用的内存)
RSS(Resident set size)实际使用物理内存(包含共享库占用的内存)
RSS是最常用的内存指标,表示进程占用的物理内存大小。但是,将各进程的RSS值相加,
通常会超出整个系统的内存消耗,这是因为RSS中每个进程都包含了各进程间共享的内存,因此存在重叠部分。
PSS(Proportional set size)实际使用的物理内存(比例分配共享库占用的内存)
USS(Unique set size ) 进程独自占用的物理内存(不包含共享库占用的内存)
与RSS相比,PSS会更准确一些,它将共享内存的大小进行平均后,再分摊到各进程上去。
USS则是PSS中自己的部分,它只计算了进程独自占用的内存大小,不包含任何共享的部分。
一般来说内存占用大小有如下规律:VSS >= RSS >= PSS >= USS

posted @ 2024-04-03 17:02  KINGBASE研究院  阅读(34)  评论(0编辑  收藏  举报