当遇到数据库内存告警，并且操作系统内存使用不足，需要分析内存占用的方法。
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