3

为什么使用transparent HugePages存在风险

 1 year ago
source link: https://www.modb.pro/db/37684
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

为什么使用transparent HugePages存在风险昨天老白讨论了Hugepages对PAGETABLE的影响,从对Hugepage和PATABLE的分析来看,对于多进程架构的使用大量共享内存、会话数较多的系统来说,Hugepage可以有效的减少PageTable的大小,节约系统内存,降低TLB的搜索开销。另外由于Hugepage是不能swap的,因此把共享内存放入Hugepage在系统内存出现换页的时候不用担心共享内存被换页。这些好处对于单进程多线程架构的应用效果就没有那么好,换句话说,单进程多线程架构的应用共享内存使用Hugepage的好处没有多进程架构应用多。另外由于Hugepage是需要手工管理的,因此针对多线程架构(比如Mysql、达梦等)的系统,使用Hugepage要从管理便捷性和有限的提升性能上做出选择。还有一点是,普通的Hugepage是需要应用程序在分配内存的时候加以指定的,我们要让应用系统使用Hugepage必须修改应用中的内存分配模块,对于一些早期并未考虑Hugepage的应用来说,存在应用升级的需求。Transparent Hugepages(THP)技术是为了解决普通Hugepage管理的缺点而研发的一种新技术,Transparent Hugepages支持从2M到4G的大页(根据CPU和操作系统的双重支持,不同的系统会有所不同),并且使用Hugepages是透明的,不需要应用重新开发。似乎是十分棒的技术,那么为什么Oracle 11.2的官方里不建议使用LINUX 6开始支持的Transparent HugePages?为什么这个看似十分好的技术在Oracle数据库中要谨慎使用呢?这个问题是和Linux的实际物理内存使用有关的。我们可能分配了某个内存给某个进程使用。不过如果这个内存仅仅是分配了,但是没有实际使用,那么这个内存实际上还是没有真正被占用的。这一点对于普通内存块还是HUGEPAGE都是一样的。比如我们有一个系统:

modb_97c28a5c-17ec-11eb-80cc-38f9d3cd240d.png

当数据库实例启动前,HUGEPAGE全部是FREE的。然后我们启动数据库实例,这个数据库实例我们配置了7gb的SGA_TARGET,初始化的DB_CACHE加上SHARED POOL的大小大约是6.5GB:

modb_97d0d698-17ec-11eb-80cc-38f9d3cd240d.png

这时候我们来看下内存的情况:

modb_97e2af58-17ec-11eb-80cc-38f9d3cd240d.png

好像只有200多个页被使用了,其他页还是空闲状态。我们针对数据库进行加压,再看内存的变化:

modb_98014dfa-17ec-11eb-80cc-38f9d3cd240d.png

我们发现free的HUGEPAGE页面数量减少了。而且随着这个应用的持续运行,FREE的页面数趋于稳定,但是远远没有达到7GB或者6.5GB的大小。也就是说,虽然被ORACLE SGA占用的内存,如果没有真正被使用到,那么这部分内存实际上并没有从LINUX内核中获取到。只有真正使用到这部分内存的时候,linux才会真正分配这部分内存。

普通的HUGEPAGE是预先占用的,在操作系统中会直接占据一个连续的内存空间,虽然没有分配,但是是被保护起来的。而使用transparent huagepages的时候,物理内存中还没有实际把这部分内存保护起来。一旦Oracle的SGA要使用这部分内存的时候,如果物理内存中有足够的大页直接分配,则可以进行分配,如果无法实现分配那么就分配普通的4K页。为了确保THP能够尽可能分配大页,那么就需要在对LINUX的内存进行碎片整理和内存回收,从而确保内存中有可分配大页的连续内存空间,这些都是通过khugepaged等后台进程来实现的。当如果系统中无足够的大页可供分配的时候,就需要通过CACHE DROP或者SWAP的方式释放足够的内存给THP使用。因此在使用THP的系统中,经常会出现一些性能的毛刺,也就是说,如果在大规模内存压缩和碎片整理的时候,系统的整体性能会下降,khugepaged、kcompactd、defrag等进程会占用大量的CPU资源,使系统出现一定程度的卡顿,对于不同负载的系统这个卡顿可能持续数秒甚至数分钟。

在一个负载较大,会话数十分多,SGA十分庞大的系统中,遇到各种风险的机会较大,可能会导致一些性能问题,甚至导致RAC实例宕机。从一些常见的导致RAC集群故障的BUG上看,大多数都是与SWAP等导致CRS集群心跳超时有关。因此Oracle建议使用普通的HUGEPAGE管理,而不使用Transparent hugepages。

THP的另外一个缺点是如果我只使用很小的内存,但是分配了一个大页,那么就会造成内存的浪费。因此对于应用系统来说,使用THP还是要十分慎重。

modb_980fc858-17ec-11eb-80cc-38f9d3cd240d.png

把THP的参数设置为madvise是一种选择,设置为madvise的时候,普通的THP申请是关闭的,不过如果我们强制申请大页,是被允许的。最后一个THP的问题是换页,如果我们要把一个1GB的HUGEPAGE交换出去,那么将会是一个灾难,交换带来的各种开销可能会让你的系统卡顿几十秒。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK