首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

Linux|大内存页(HugePage)的三三两两

最近有同事问了几个关于大内存页(HugePage)的问题,就顺便复习并拓展的看了下相关的内容,根据自己的理解做个简单总结,如有纰漏欢迎指正。...大部分处理器默认的页大小是4KB,也有8KB、16KB或者64KB,显而易见这样的页太小了,尤其是在云和虚拟化中,这样的页大小将大大降低相应速度,因此就引入了HugePage的概念,将页扩大到2M甚至1G...,目前Linux常用的HugePage大小为2M和1GB。...Linux的HugePage Linux是如何查看大页的配置?...可以直接查看/proc/meminfo中的Mem和HugePage相关内容,如下的结果中一共有2G的内存,大页是2M的页,但是没有任何可以使用的大页(HugePages_Total=0): $ grep

2.3K20

Linux中的HugePage对数据库服务来说为什么如此重要:以PG为例

Linux中的HugePage对数据库服务来说为什么如此重要:以PG为例 用户经常因为OOM killer造成数据库崩溃问题来找我们寻求帮助。...此处不专注解释HugePage背后的理论和概念,而是专注于影响分析。...解决方案:启用HugePage 这种臃肿的页表和相关问题的解决方案是使用HugePages。可以通过查看PG进程的VmPeak来计算出应该为HugePage分配多少内存。...使用HugePage “ON”进行测试 在PG启动前创建好HugePages。PG只是分配并使用他们。所以启动前后free结果不会有变化。...如果他们已经可用,PG会将其共享内存分配到这些HugePage中。PG的shared_buffers是共享内存的最大占用者。

1.2K40

hugepage设置导致的数据库事故(r4笔记第28天)

Change PGA from 10G to 20G Change Buffer Cache from 20G to 40G Change Shared pool from 10G to 20G HugePage...从头开始来看,出现kswapd3的的原因是由于内存使用紧张导致的,那么300G左右的内存,设置了60G左右的Hugepage,怎么还不够用呢,从Hugepage的情况来看一下。...怎么能够证明在hugepage的设置出现问题呢, 一个原因就是客户发送的变更清单,HugePage from 60 GB to 120GB ,清单上说需要变更为60G到120G,但是从目前的情况来看,似乎这个变更没有设置或是没有生效...这个时候还是得靠日志,数据库启动的时候会产生一些hugepage相关的信息。 正常情况下,如果hugepage设置正常,可以从数据库的日志中我们发现如下的一段内容。...最后和客户商量,他们把SGA,PGA的大小都恢复到原有的值,保证能够稳定运行的前提下,稍后再安排做hugepage的优化。最后把这个库failover到另外一台server中,再次查看就没有问题了。

69440
领券