开启大页与否对CacheBuffer的影响的学习
背景
最近遇到数据库压力较高的场景.
原厂工程师到位后修改了几个参数(自己以为参数没问题)
然后最近一周环境就比较正常了.
这个地方很打脸, 自己没有进行详细的调查.
分析思考问题的思路和方向出现了问题.
基于这个情况, 自己特别想知道, 为啥修改参数之前内存使用量波动很大
但是关闭了numa 关闭了透明大页 打开了大页之后 内存波动为什么会减少
尤其是 cache buffer 的使用量从很大变成了几乎没有.
验证开启大页与否的情况
不开启大页 使用200个jmeter进程连接数据库 插入简单数据
[oracle@oracle12c ~]$ ipcs -m
------------ 共享内存段 --------------
键 shmid 拥有者 权限 字节 连接数 状态
0x00000000 32768 oracle 600 12177408 544
0x00000000 65537 oracle 600 13388218368 272
0x00000000 98306 oracle 600 21377024 272
0xbda99060 131075 oracle 600 32768 272
[oracle@oracle12c ~]$ free -g
total used free shared buff/cache available
Mem: 30 1 14 12 13 15
Swap: 7 0 7
发现shared 尤其是 buff/cache 其实是比较高的.
开启大页同步验证
HugePages_Total: 6410
HugePages_Free: 9
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 13127680 kB
DirectMap4k: 210816 kB
DirectMap2M: 7129088 kB
DirectMap1G: 28311552 kB
然后内存段的相关信息
[root@oracle12c ~]# free -g
total used free shared buff/cache available
Mem: 30 14 14 0 1 15
Swap: 7 0 7
[root@oracle12c ~]# ipcs -m
------------ 共享内存段 --------------
键 shmid 拥有者 权限 字节 连接数 状态
0x00000000 32768 oracle 600 12582912 272
0x00000000 65537 oracle 600 13388218368 272
0x00000000 98306 oracle 600 23068672 272
0xbda99060 131075 oracle 600 32768 272
对比结论
发现开启大页后, Oracle启动起来内存都进入了大页内.
都变成了 used 内存 不像最开始的 不开启大页时 used内存显示较少.
开启大页 13G内存( 12.8G的SGA区域). 不开启大页 1G在用.
同样的, 开启大页启动速度感觉会变慢.
怀疑不开启大页时懒惰式的内存加载.
开启大页是 必须全量申请的内存加载.
开启大页时的启动速度 : 24秒左右
不开启大页时的启动速度: 15秒左右(第二次更快, 第一次刚启动会慢一些)
理论上开启大页的性能会好很多. 通过今天的实验对这一块有了更加深入的认识.
另外发现, 针对共享段的连接数. 每一个新连接都会增加 4个连接数(四个不同的共享段)
增加段大小能够减少类似的连接数, 可以简单计算, 如果段大小为百分之一的SGA区域大小, 那么一个用户要产生 至少103个链接.
(假定除了 Database Buffers 都可以放到一个段内, 但是几乎不现实 )
更多的连接数 肯定会带来类似于 epoll 惊群或者是轮询性能下降的问题. 所以很多参数修改都有他必然的意义. 需要重视.
标签:大页,600,CacheBuffer,开启,与否,272,内存,oracle
From: https://www.cnblogs.com/jinanxiaolaohu/p/17786494.html