• 售前

  • 售后

热门帖子
入门百科

Linux中大内存页Oracle数据库优化的方法

[复制链接]
爱最爱我爱的爱y 显示全部楼层 发表于 2021-10-25 20:03:12 |阅读模式 打印 上一主题 下一主题
前言
PC Server发展到本日,在性能方面有着长足的进步。64位的CPU在数年前都已经进入到寻常的家用PC之中,更别说是更高端的PC Server;在Intel和AMD两大处理器巨头的积极下,x86 CPU在处理本领上不断提升;同时随着制造工艺的发展,在PC Server上可以大概安装的内存容量也越来越大,现在到处可见数十G内存的PC Server。正是硬件的发展,使得PC Server的处理本领越来越强大,性能越来越高。而在稳固性方面,搭配PCServer和Linux操作体系,同样可以大概满重要业务体系所需要的稳固性和可靠性。当然在资本方面,引用一位在行业软件厂商的网友的话来说,“如果不用PC Server改用小型机,那我们赚什么钱啊?”。不管从初期的购买,运行期的能耗和维护资本,PC Server都比相同处理本领的小型机便宜许多。正是在性能和资本这两个重要因素的影响下,运行在PC Server上的数据库越来越多。笔者所服务的一些客户,甚至把高端的PCServer虚拟化成多台机器,在每台虚拟机上跑一套Oracle数据库,这些数据库不乏承载着重要的生产体系。
毫无疑问,在PC Server上运行Oracle数据库,最得当的操作体系无疑是Linux。作为与UNIX极为类似的操作体系,在稳固性、可靠性和性能方面有着与UNIX同样优异的表现。但是Linux在内存分页处理机制上与AIX、HP-UX等操作体系相比有一个显着的缺陷,而这个缺陷在利用较大SGA的Oracle数据库上表现尤为显着,严肃时对数据库性能有着显着的负面影响,甚至会导致数据库完全制止相应。而本文就将从一个案例来详述这种缺陷,并利用Linux下的大内存页来办理这一标题。
一、案例的引入
客户的一套体系,出现了严肃的性能标题。在标题出现时,体系基本不可利用,应用上全部的业务操作完全失去相应。体系的数据库是运行在RHEL 5.2 (Red Hat Enterprise Linux Server release 5 (Tikanga))下的Oracle 10.2.0.4 Oracle Database,CPU为4颗4核至强处理器(Intel(R)Xeon(R) CPU E7430 @ 2.13GHz),也就是逻辑CPU为16,内存32GB。故障期间,数据库服务器的CPU长期保持在100%。甚至将应用的全部Weblogic Server都关闭之后,数据库服务器的CPU利用率在数分钟之内都一直是100%,然后徐徐下降,大约需要颠末20分钟才会下降到正常的空闲状态,由于这个时间全部的应用都已经关闭,只有非常低的CPU利用率才是正常的状态。据这套体系的数据库维护人员反映,这种情况已经出现多次,就算是重启数据库之后,过不了一两天,如许的故障同样会出现。同时这套体系最近也没做过大的变动。
笔者在接到接到故障陈诉后,通过SSH连接到数据库数据库都非常慢,需要差不多1分钟才能连接上去。先简朴的看一下服务器的性能状况,发展IO极低、内存剩余还比力多,至少另有1GB以上,也没有page in / page out。而最显着的征象就是CPU利用率相称地高,一直保持在100%,同时CPU利用率的SYS部门,均在95%以上。而操作体系运行队列也一直在200以上。服务器内存的利用情况如下:
  1. $cat/proc/meminfo
  2. MemTotal: 32999792 kB
  3. MemFree: 1438672 kB
  4. Buffers: 112304 kB
  5. Cached: 23471680 kB
  6. SwapCached: 1296 kB
  7. Active: 19571024 kB
  8. Inactive: 6085396 kB
  9. HighTotal: 0 kB
  10. HighFree: 0 kB
  11. LowTotal: 32999792 kB
  12. LowFree: 1438672 kB
  13. SwapTotal: 38371320 kB
  14. SwapFree: 38260796 kB
  15. Dirty: 280 kB
  16. Writeback: 0kB
  17. AnonPages: 2071192 kB
  18. Mapped: 12455324 kB
  19. Slab: 340140 kB
  20. PageTables: 4749076 kB
  21. NFS_Unstable: 0 kB
  22. Bounce: 0 kB
  23. CommitLimit: 54871216kB
  24. Committed_AS: 17226744 kB
  25. VmallocTotal:34359738367 kB
  26. VmallocUsed: 22016 kB
  27. VmallocChunk:34359716303 kB
复制代码
从征象上看,SYS CPU高是分析标题的一个重要线索。
在以最快的速率相识了一下操作体系层面的性能情况之后,立刻通过Sqlplus连接到数据库,检察数据库内部的性能信息:
(注:以下数据关于SQL、服务器名称、数据库名称等相干信息颠末处理。)
  1. SQL> select sid,serial#,program,machine,sql_id,eventfrom v$session where type='USER' and status='ACTIVE';
  2. SID SERIAL# PROGRAM MACHINE SQL_ID EVENT
  3. -------------------- ------------------------------ ---------- -------------
  4. 519 4304 xxx_app1 0gc4uvt2pqvpu latch: cache buffers chains
  5. 459 12806 xxx_app1 0gc4uvt2pqvpu latch: cache buffers chains
  6. 454 5518 xxx_app1 15hq76k17h4ta latch: cache buffers chains
  7. 529 7708 xxx_app1 0gc4uvt2pqvpu latch: cache buffers chains
  8. 420 40948 xxx_app1 0gc4uvt2pqvpu latch: cache buffers chains
  9. 353 56222 xxx_app1 f7fxxczffp5rx latch: cache buffers chains
  10. 243 42611 xxx_app1 2zqg4sbrq7zay latch: cache buffers chains
  11. 458 63221 xxxTimer.exe APPSERVER 9t1ujakwt6fnf local write wait
  12. ...为节省篇幅,省略部分内容...
  13. 409 4951 xxx_app1 7d4c6m3ytcx87 read by other session
  14. 239 51959 xxx_app1 7d4c6m3ytcx87 read by other session
  15. 525 3815 xxxTimer.exe APPSERVER 0ftnnr7pfw7r6 enq: RO -fast object reu
  16. 518 7845 xxx_app1 log file sync
  17. 473 1972 xxxTimer.exe APPSERVER 5017jsr7kdk3b log file sync
  18. 197 37462 xxx_app1 cbvbzbfdxn2w7 db file sequential read
  19. 319 4939 xxxTimer.exe APPSERVER 6vmk5uzu1p45m db file sequentialread
  20. 434 2939 xxx_app1 gw921z764rmkc latch: shared pool
  21. 220 50017 xxx_app1 2zqg4sbrq7zay latch: library cache
  22. 301 36418 xxx_app1 02dw161xqmrgf latch: library cache
  23. 193 25003 oracle@xxx_db1 (J001) xxx_db1 jobq slave wait
  24. 368 64846 oracle@xxx_db1 (J000) xxx_db1 jobq slave wait
  25. 218 13307 sqlplus@xxx_db1 (TNS V1-V3) xxx_db1 5rby2rfcgs6b7 SQL*Net message to client
  26. 435 1883 xxx_app1 fd7369jwkuvty SQL*Net message from client
  27. 448 3001 xxxTimer.exe APPSERVER bsk0kpawwztnwSQL*Net message from dblink
  28. SQL>@waitevent
  29. SID EVENT SECONDS_IN_WAIT STATE
  30. ----------------------------------- --------------- -------------------
  31. 556 latch: cache buffers chains 35 WAITED KNOWN TIME
  32. 464 latch:cache buffers chai ns 2 WAITING
  33. 427 latch:cache buffers chai ns 34 WAITED SHORT TIME
  34. 458 localwrite wait 63 WAITING
  35. 403 writecomplete waits 40 WAITING
  36. 502 writecomplete waits 41 WAITING
  37. 525 enq:RO - fast object reuse 40 WAITING
  38. 368 enq:RO - fast object reu se 23 WAITING
  39. 282 db file sequential read 0 WAITING
  40. 501 dbfile sequential read 2 WAITED SHORT TIME
  41. 478 db file sequential read 0 WAITING
  42. 281 db file sequential read 6 WAITED KNOWN TIME
  43. 195 db file sequential read 4 WAITED KNOWN TIME
  44. 450 db file sequential read 2 WAITED KNOWN TIME
  45. 529 db file sequential read 1 WAITING
  46. 310 dbfile sequential read 0 WAITED KNOWN TIME
  47. 316 db filesequential read 89 WAITED SHORT TIME
  48. 370 db file sequential read 1 WAITING
  49. 380 db file sequential read 1 WAITED SHORT TIME
  50. 326 jobq slave wait 122 WAITING
  51. 378 jobq slave wait 2 WAITING
  52. 425 jobq slave wait 108 WAITING
  53. 208 SQL*Net more data from db 11 WAITED SHORT TIME link
  54. 537 Streams AQ: waiting for t 7042 WAITING ime management or cleanup tasks
  55. 549 Streams AQ: qmn coordinat 1585854 WAITING or idle wait
  56. 507 Streams AQ: qmn slave idl 1585854 WAITING e wait
  57. 430 latch free 2 WAITED KNOWN TIME
  58. 565 latch:cache buffers lru 136 WAITED SHORT TIME chain
复制代码
从数据库中的运动以及等候变乱来看,并没有太大的异常。值得注意的是,在数据库服务器CPU利用率长期在100%,或物理内存耗尽并伴有大量的交换内存换入换出时,需要仔细地诊断数据库中的性能征象,好比某类较多的等候变乱,是由CPU或内存不足导致的结果还是由于这些数据库中的特定的运动才是Root Cause引起CPU过高或内存耗尽。
从上面的数据来看,运动会话并不是特别多,不到50个,加上后台进程的数量,与操作体系中高达200的运行相比,存在不小的差别。数据库中重要有三类的非空闲等候变乱,IO相干的等候如db file sequential read,database link相干的SQL*Net more data from dblink以及latch 相干的等候变乱。在这三类种,通常只有latch这类等候变乱才会引起CPU的利用率增长。
通过分析对比AWR陈诉,在故障期间和正常期间,从数据库运动来说,没有特别显着的差别。但是在体系统计上,差别较大:
  1. StatisticName 1st 2nd Value
  2. ----------------------------------- -------------- -------------- ------------------------
  3. BUSY_TIME 3,475,776 1,611,753
  4. IDLE_TIME 2,266,224 4,065,506
  5. IOWAIT_TIME 520,453 886,345
  6. LOAD -67 -3
  7. NICE_TIME 0 0
  8. NUM_CPU_SOCKETS 0 0
  9. PHYSICAL_MEMORY_BYTES 0 0
  10. RSRC_MGR_CPU_WAIT_TIME 0 0
  11. SYS_TIME 1,802,025 205,644
  12. USER_TIME 1,645,837 1,381,719
复制代码
上面的数据中,是来自于包罗故障时间段的1小时(1st)和正常时间段1小时(2nd)的AWR的对比数据。对于故障分析来说,特别是故障时间比力短的情况下,1小时的AWR陈诉会不够准确地反映故障期间的性能情况。但是我们在Trouble Shooting之时,主要的是需要从各种数据中,确定方向。正如前面提到,SYS部门的CPU利用率过高是一个很重要的线索,而数据库内部的其他性能数据相差不大的情况下,可以先从CPU这一点动手。
二、操作体系中CPU利用分析
那么,在操作体系中,SYS和USER这两个差别的利用率代表着什么?大概说二者有什么区别?
简朴来说,CPU利用率中的SYS部门,指的是操作体系内核(Kernel)利用的CPU部门,也就是运行在内核态的代码所斲丧的CPU,最常见的就是体系调用(SYS CALL)时斲丧的CPU。而USER部门则是应用软件自己的代码利用的CPU部门,也就是运行在用户态的代码所斲丧的CPU。好比Oracle在实行SQL时,从磁盘读数据到db buffer cache,需要发起read调用,这个read调用重要是由操作体系内核包罗装备驱动步伐的代码在运行,因此斲丧的CPU盘算到SYS部门;而Oracle在解析从磁盘中读到的数据时,则只是Oracle自己的代码在运行,因此斲丧的CPU盘算到USER部门。
那么SYS部门的CPU重要会由哪些操作或是体系调用产生呢:
1. I/O操作,好比读写文件、访问外设、通过网络传输数据等。这部门操作一样平常不会斲丧太多的CPU,由于重要的时间斲丧会在IO操作的装备上。好比从磁盘读文件时,重要的时间在磁盘内部的操作上,而斲丧的CPU时间只占I/O操作相应时间的少部门。只有在过高的并发I/O时才大概会使SYS CPU有所增长。
2. 内存管理,好比应用进程向操作体系申请内存,操作体系维护体系可用内存,交换空间换页等。其实与Oracle类似,越大的内存,越频仍的内存管理操作,CPU的斲丧会越高。
3. 进程调理。这部门CPU的利用,在于操作体系中运行队列的长短,越长的运行队列,表明越多的进程需要调理,那么内核的负担也就越高。
4. 其他,包罗进程间通讯、信号量处理、装备驱动步伐内部一些运动等等。
从体系故障时的性能数据来看,内存管理和进程调理这两项大概是引起SYS CPU很高的原因。但是运行队列高达200以上,很大概是由于CPU利用率高导致的结果,而不是由于运行队列高导致了CPU利用率高。从数据库里面来看运动会话数不是特别高。那么接下来,需要关注是否是由于体系内存管理方面的标题导致了CPU利用率过高?
回首本文开始部门收集的/proc/meminfo中体系内存方面数据,可以发现一项重要的数据:
  1. PageTables: 4749076 kB
复制代码
从数据可以看到,PageTables内存到达了4637MB。PageTables在字面意思上是指“页面表”。简朴地说,就是操作体系内核用于维护进程线性虚拟地址和实际物理内存地址对应关系的表格。
当代盘算机对于物理内存,通常是将其以页(Page Frame)为单元举行管理和分配,在 x86处理器架构上,页面大小为4K。运行在操作体系上的进程,可访问的地址空间称为虚地址空间,跟处理器位数有关。对于32位的x86处理器,进程的可访问地址空间为4GB。在操作体系中运行的每一个进程,都有其独立的虚地址空间或线性地址空间,而这个地址空间同样也是按页(Page)举行管理,在Linux中,页大小通常为4KB。进程在访问内存时,由操作体系和硬件共同,负责将进程的虚拟地址转换成为物理地址。两个差别的进程,其相同的虚拟线性地址,指向的物理内存,大概相同,好比共享内存;也大概差别,好比进程的私有内存。
下图是关于虚拟地址和物理内存对应关系的表现图:

假设有两个进程A、B,分别有一个内存指针指向的地址为0x12345(0x表现16进制数),好比一个进程fork或clone出另一个进程,那么这2个进程就会存在指向相同内存地址的指针的情况。进程在访问0x12345这个地址指向的内存时,操作体系将这个地址转换为物理地址,好比A进程为0x23456,B进程为0x34567,二者互不影响。那么这个物理地址是什么时间得来?对于进程私有内存(大部门情况均是如此)来说,是进程在向操作体系请求分配内存时得来。进程向操作体系请求分配内存时,操作体系将空闲的物理内存以Page为单元分配给进程,同时给进程产生一个虚拟线程地址,在虚拟地址和物理内存地址之间建立 映射关系,这个虚拟地址作为结果返回给进程。
Page Table(页表)就是用于操作体系维护进程虚拟地址和物理内存对应关系的数据结构。下图是一个比力简朴情况下的Page Table表现图:

下面简朴地描述在32位体系下,页大小为4K时,操作体系是如作甚进程的虚拟地址和实际物理地址之间举行转换的。
1. 目次表是用于索引页表的数据结构,每个目次项占32位,即4字节,存储一个页表的位置。目次表刚好占用1页内存,即4KB,可以存储1024个目次项,也就是可以存储1024个页表的位置。
2. 页表项(Page Table Entry)大小为4字节,存储一个物理内存页起始地址。每个页表同样占用4K内存,可以存储1024个物理内存页起始地址。由于物理内存页起始地址以4KB为单元对齐,所以32位中,只需要20位来表现地址,其他12位用于其他用途,好比表现这1内存页是只读还是可写等等。
3. 1024个页表,每个页表1024个物理内存页起始地址,合计就是1M个地址,每个地址指向的物理内存页大小为4KB,合计为4GB。
4. 操作体系及硬件将虚拟地址映射为物理地址时,将虚拟地址的31-22这10位用于从目次项中索引到1024个页表中的一个;将虚拟地址的12-21这10位用于从页表中索引到1024个页表项中的一个。从这个索引到的页表项中得到物理内存页的起始地址,然后将虚拟地址的0-11这12位用作4KB内存页中的偏移量。那么物理内存页起始地址加上偏移量就是进程所需要访问的物理内存的地址。
再看看目次表和页表这2种数据结构占用的空间会有多少。目次表固定只有4KB。而页表呢?由于最多有1024个页表,每个页表占用4KB,因此页表最多占用4MB内存。
实际上32位Linux中的进程通常不会那么大的页表。进程不大概用完全部的4GB大小地址空间,甚至有1GB虚拟地址空间分给了内核。同时Linux不会为进程一次性建立那么大的页表,只有进程在分配和访问内存时,操作体系才会为进程建立相应地址的映射。
这里只描述了最简朴情况下的分页映射。实际上页表目次连同页表一共有四级。同时在32位下启用PAE或64位体系,其页表结构比上面的表现图更复杂。但无论怎么样,最后一级即页表的结构是一致的。
在64位体系中,Page Table(页表)中的页表项,与32位相比,大小从32位变为64位。那么这会有多大的影响?如果一个进程,访问的物理内存有1GB,即262144个内存页,在32位体系中,页表需要262144*4/1024/1024=1MB,而在64位体系下,页表占用的空间增长1倍,即为2MB。
那再看看对于Linux体系中运行的Oracle数据库,又是怎么样一番情形。本文案例中数据库的SGA大小12GB,如果一个OracleProcess访问到了全部的SGA内存,那么其页表大小会是24MB,这是一个惊人的数字。这里忽略掉PGA,由于均匀下来每个进程的PGA不高出2M,与SGA相比着实太小。从AWR陈诉来看,有300个左右的会话,那么这300个连接的页表会到达7200MB,只不外并不是每个进程都会访问到SGA中全部的内存。而从meminfo检察到的Page Tables大小到达4637MB,这么大的Page Table空间,正是300个会话,SGA大小到达12GB的结果。
体系中显然不会只有Page Table这唯一的内存管理数据结构,另有其他一些数据结构用于管理内存。这些过大的内存管理结构,无疑会大大增长操作体系内核的负担和对CPU的斲丧。而在负载变化或其他原因导致内存需求大幅变化,好比多进程同时申请大量的内存,大概引起CPU在短时间内到达高峰,从而引起标题。
三、利用大内存页来办理标题
固然没有确实的证据,也没有充足长的时间来收集充足的证据来证明是过大的Page Table导致了标题,那需要面临多次半小时以上的体系不可用故障。但是从现在来看,这是最大的可疑点。因此,决定先利用大内存页来调优体系的内存利用。
大内存页是一种统称,在低版本的Linux中为Large Page,而当前主流的Linux版本中为Huge Page。下面以Huge Page为例来阐明Huge Page的优点及如何利用。
利用大内存页有哪些长处:
1. 减少页表(Page Table)大小。每一个Huge Page,对应的是连续的2MB物理内存,如许12GB的物理内存只需要48KB的Page Table,与原来的24MB相比减少许多。
2. Huge Page内存只能锁定在物理内存中,不能被交换到交换区。如许避免了交换引起的性能影响。
3. 由于页表数量的减少,使得CPU中的TLB(可理解为CPU对页表的CACHE)的掷中率大大进步。
4. 针对Huge Page的页表,在各进程之间可以共享,也低落了Page Table的大小。实际上这里可以反映出Linux在分页处理机制上的缺陷。而其他操作体系,好比AIX,对于共享内存段如许的内存,进程共享相同的页表,避免了Linux的这种标题。像笔者维护的一套体系,连接数寻常都是5000以上,实例的SGA在60GB左右,要是按Linux的分页处理方式,体系中大部门内存都会被页表给用掉。
那么,怎么样为Oracle启用大内存页(Huge Page)?以下是实施步调。由于案例中涉及的数据库在过一段时间后将SGA调解为了18G,这里就以18G为例:
1、查抄/proc/meminfo,确认体系支持HugePage:
  1. HugePages_Total: 0
  2. HugePages_Free: 0
  3. HugePages_Rsvd: 0
  4. Hugepagesize: 2048 kB
复制代码
HugePages Total表现体系中设置的大内存页页面数。HugePages Free表现没有访问过的大内存页面数,这里free容易引起误解,这在稍后有所解释。HugePages Rsvd表现已经分配但是还未利用的页面数。Hugepagesize表现大内存页面大小,这里为2MB,注意在有的内核设置中大概为4MB。
好比HugePages总计11GB,SGA_MAX_SIZE为10GB,SGA_TARGET为8GB。那么数据库启动后,会根据SGA_MAX_SIZE分配HugePage内存,这里为10GB,真正Free的HugePage内存为11-10=1G。但是SGA_TARGET只有8GB,那么会有2GB不会被访问到,则HugePage_Free为2+1=3GB,HugePage_Rsvd内存有2GB。这里实际上可以给其他实例利用的只有1GB,也就是真正意义上的Free只有1GB。
2. 计划要设置的内存页数量。到现在为止,大内存页只能用于共享内存段等少量类型 的内存。一旦将物理内存用作大内存页,那么这些物理内存就不能用作其他用途,好比作为进程的私有内存。因此不能将过多的内存设置为大内存页。我们通常将大内存页用作Oracle数据库的SGA,那么大内存页数量:
  1. HugePages_Total=ceil(SGA_MAX_SIZE/Hugepagesize)+N
复制代码
好比,为数据库设置的SGA_MAX_SIZE为18GB,那么页面数可以为ceil(18*1024/2)+2=9218。
这里加上N,是需要将HugePage内存空间设置得比SGA_MAX_SIZE稍大,通常为1-2即可。我们通过ipcs -m命令检察共享内存段的大小,可以看到共享内存段的大小实际上比SGA_MAX_SIZE约大。如果服务器上有多个Oracle实例,需要为每个实例考虑共享内存段多出的部门,即N值会越大。另外,Oracle数据库要么全部利用大内存页,要么完全不利用大内存页,因此不合适的HugePages_Total将造成内存的浪费。
除了利用SGA_MAX_SIZE盘算,也可以通过ipcs -m所获取的共享内存段大小盘算出更准确的HugePages_Total。
  1. HugePages_Total=sum(ceil(share_segment_size/Hugepagesize))
复制代码
3. 修改/etc/sysctl.conf文件,增长如下行:
  1. vm.nr_hugepages=9218
复制代码
然后实行sysctl –p命令,使设置生效。
这里vm.nr_hugepages这个参数值为第2步盘算出的大内存页数量。然后查抄/proc/meminfo,如果HugePages_Total小于设置的数量,那么表明没有充足的连续物理内存用于这些大内存页,需要重启服务器。
4. 在/etc/security/limits.conf文件中增长如下行:
  1. oracle soft memlock 18878464
  2. oracle hard memlock 18878464
复制代码
这里设定oracle用户可以锁定内存的大小 ,以KB为单元。
然后重新以oracle用户连接到数据库服务器,利用ulimit -a命令,可以看到:
  1. max lockedmemory (kbytes, -l) 18878464
复制代码
这里将memlock设置为unlimited也可以。
5. 如果数据库利用MANUAL方式管理SGA,需要改为AUTO方式,即将SGA_TARGET_SIZE设置为大于0的值。对于11g,由于HugePage只能用于共享内存,不能用于PGA,所以不能利用AMM,即不能设置MEMORY_TARGET为大于0,只能分别设置SGA和PGA,SGA同样只能是AUTO方式管理。
6. 最后启动数据库,查抄/proc/meminfo中检察HugePages_Free是否已经减少。如果已经减少,表明已经利用到HugePage Memory。
不外检察出故障数据库服务器上的/proc/meminfo时发现,居然没有HugePage相干的信息,sysctl -a检察全部体系参数也没有找到vm.nr_hugepages这个参数。这是由于Linux内核没有编译进HugePage这个特性。我们需要利用其他的内核来启用HugePage。
检察/boot/grub/grub.conf:
  1. # grub.confgenerated by anaconda
  2. # Note thatyou do not have to rerun grub after making changes to this file
  3. #NOTICE: You have a /boot partition. This means that
  4. # all kerneland initrd paths are relative to /boot/, eg.
  5. # root(hd0,0)
  6. # kernel/vmlinuz-version ro root=/dev/VolGroup00/LogVol00
  7. # initrd/initrd-version.img
  8. #boot=/dev/cciss/c0d0
  9. default=0
  10. timeout=5
  11. splashimage=(hd0,0)/grub/splash.xpm.gz
  12. hiddenmenu
  13. title Red HatEnterprise Linux Server (2.6.18-8.el5xen) with RDAC
  14. root (hd0,0)
  15. kernel /xen.gz-2.6.18-8.el5
  16. module /vmlinuz-2.6.18-8.el5xen roroot=/dev/VolGroup00/LogVol00 rhgb quiet
  17. module /mpp-2.6.18-8.el5xen.img
  18. title Red HatEnterprise Linux Server (2.6.18-8.el5xen)
  19. root (hd0,0)
  20. kernel /xen.gz-2.6.18-8.el5
  21. module /vmlinuz-2.6.18-8.el5xen roroot=/dev/VolGroup00/LogVol00 rhgb quiet
  22. module /initrd-2.6.18-8.el5xen.img
  23. title Red HatEnterprise Linux Server-base (2.6.18-8.el5)
  24. root (hd0,0)
  25. kernel /vmlinuz-2.6.18-8.el5 roroot=/dev/VolGroup00/LogVol00 rhgb quiet
  26. module/initrd-2.6.18-8.el5.img
复制代码
发现这个体系利用的内核带有"xen"字样,我们修改这个文件,将default=0改为default=2,大概将前面2种内核用#号屏蔽掉,然后重启数据库服务器,发现新的内核已经支持HugePage。
数据库启用大内存页之后,本文描述的性能标题甚至是在增大了SGA的情况下也没有出现。观察/proc/meminfo数据,PageTables占用的内存一直保持在120M以下,与原来相比,减少了4500MB。据观察,CPU的利用率也较利用HugePages之前有所下降,而体系运行也相称地稳固,至少没有出现因利用HugePage而产生的BUG。
测试表明,对于OLTP体系来说,在运行Oracle数据库的Linux上启用HugePage,数据库处理本领和相应时间均有差别水平的进步,最高甚至可以到达10%以上。
四、小结
本文以一个案例,先容了Linux操作体系下大内存页在性能提升方面的作用,以及如何设置相应的参数来启用大内存页。在本文最后,笔者发起在Linux操作体系中运行Oracle数据库时,启用大内存页来避免本文案例遇到的性能标题,或进一步进步体系性能。可以说,HugePage是少数不需要额外代价就能提升性能的特性。另外值得高兴的是,新版本的Linux内核提供了Transparent Huge Pages,以便运行在Linux上的应用能更广泛更方便地利用大内存页,而不仅仅是只有共享内存这类内存才能利用大内存页。对于这一特性引起的变化,让我们拭目以待。
文章泉源:《Oracle DBA手记 3》Linux大内存页Oracle数据库优化 作者:熊军
配图泉源: http://2.bp.blogspot.com/-o1ihxahkl0o/VQFhFj2lHwI/AAAAAAAAAV4/egUhLwaYtmc/s1600/oracle_linux.png
总结
以上就是这篇文章的全部内容了,渴望本文的内容对各人的学习大概工作具有肯定的参考学习代价,如果有疑问各人可以留言交换,谢谢各人对脚本之家的支持。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x

帖子地址: 

回复

使用道具 举报

分享
推广
火星云矿 | 预约S19Pro,享500抵1000!
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

草根技术分享(草根吧)是全球知名中文IT技术交流平台,创建于2021年,包含原创博客、精品问答、职业培训、技术社区、资源下载等产品服务,提供原创、优质、完整内容的专业IT技术开发社区。
  • 官方手机版

  • 微信公众号

  • 商务合作