成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

Oracle數據庫內存耗盡,大頁惹的禍?

數據庫 Oracle
使用HugePages時,操作系統頁表(虛擬內存到物理內存的映射)變小,可以減少訪問頁表條目所需的系統資源量,從而提高系統性能。HugePage的大小從2MB到256MB不等,這取決于內核版本和硬件體系結構。

一、內存耗盡場景

問題現象:

Oracle數據庫服務器內存資源耗盡,數據庫無響應。

問題原因:

原linux環境沒有啟用HugePages,啟用HugePages后,內存使用率直線上漲,最終內存資源耗盡。

啟用HugePages明明是提高性能,為什么會導致內存資源耗盡呢?這和HugePages內存分配機制有關:

例如當前配置信息如下:

數據庫服務器總內存128GB,SGA分配75GB,PGA分配30GB,SGA+PGA占總內存82%。

通常啟用HugePages大頁時,會將HugePages設置為偏大于SGA值,例如76G。

但如果設置HugePages比SGA值小,會出現什么情況?

例如:將HugePages設置為70GB。

此時服務器內存最大會分出70GB給HugePages使用,但是由于HugePages<SGA,導致Oracle數據庫不會完全使用HugePages中的內存來分配給SGA,出現內存資源浪費,高并發、高負載等場景下可能會導致內存資源耗盡。

在官方文檔有這么一段描述:

Ensure that HugePages is configured properly as the system may run out of memory if excess HugePages is not used by the application.

確保HugePages配置正確,因為如果應用程序未使用過多的HugePage,系統可能會耗盡內存。

問題重現:

環境說明:

OS:Red Hat Enterprise Linux Server release 7.5 (Maipo)
DB:Oracle 11.2.0.4.0
內存:3692MB

參數:

sga_max_size=sga_target=1970MB
pga_aggregate_target=980MB
use_large_pages=TRUE

AMM內存管理和HugePages不兼容,如果內存啟用了AMM(Automatic Memory managed),需要先切換為ASMM(Automatic Shared Memory Managed)。

先備份參數文件:

SQL> show parameter spfile
SQL> ho cp /oracle/app/oracle/product/11.2/db/dbs/spfilecjc.ora /home/oracle/spfilecjc.ora.bak

將AMM轉換為ASMM:

alter system reset memory_target scope=spfile;
---alter system reset memory_max_target scope=spfile;
alter system set sga_max_size=1970M scope=spfile;
alter system set sga_target=1970M scope=spfile;
alter system set pga_aggregate_target=980M scope=spfile;

重啟數據庫:

SQL> shutdown immediate
SQL> startup

1.1 正確啟用HugePages方法:

啟動前,檢查基本信息

[root@cjc-db-01 ~]# grep Huge /proc/meminfo
AnonHugePages: 100352 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
[root@cjc-db-01 ~]# uname -sr
Linux 4.1.12-112.16.4.el7uek.x86_64
[root@cjc-db-01 ~]# cat /proc/meminfo|grep PageTables


PageTables: 38084 kB
[root@cjc-db-01 ~]# free -h
total        used        free      shared  buff/cache   available
Mem: 3.6G        490M        2.2G        289M        918M        1.9G
Swap: 2.0G          0B        2.0G

配置memlock

在/etc/security/limits.conf文件中設置memlock值,memlock設置以KB為單位。

當啟用HugePages內存時,最大鎖定內存限制應至少設置為當前服務器內存的90%。

禁用HugePages內存時,最大鎖定內存限制應設置為至少3145728 KB(3 GB)。

例如,如果安裝了64 GB RAM,則添加以下條目以增加最大鎖定內存地址空間:

* soft   memlock    60397977
* hard   memlock    60397977

也可以將memlock值設置為高于SGA要求的值,或者設置為unlimited

oracle soft memlock unlimited
oracle hard memlock unlimited

再次以oracle用戶身份登錄并運行ulimit-l命令以驗證新的memlock設置

[oracle@cjc-db-01 ~]$ ulimit -l
Unlimited

檢查并啟動實例

RAC:

檢查實例是啟動狀態

srvctl status instance -d dbname

如果沒啟動,手動啟動實例

srvctl start instance -d dbname -i instance_name -o open

單機:

SQL> select status from v$instance;

使用腳本為當前共享內存段計算hugepages配置的建議值:

root用戶下執行:

chmod +x hugepages_settings.sh
./hugepages_settings.sh

備注:腳本內容見末尾。

腳本來自My Oracle Support note 401749.1?。

例如:

[root@cjc-db-01 oracle]# ./hugepages_settings.sh
This script is provided by Doc ID 401749.1 from My Oracle Support
(http://support.oracle.com) where it is intended to compute values for
the recommended HugePages/HugeTLB configuration for the current shared
memory segments on Oracle Linux. Before proceeding with the execution please note following:
 * For ASM instance, it needs to configure ASMM instead of AMM.
 * The 'pga_aggregate_target' is outside the SGA and
   you should accommodate this while calculating the overall size.
 * In case you changes the DB SGA size,
   as the new SGA will not fit in the previous HugePages configuration,
   it had better disable the whole HugePages,
   start the DB with new SGA size and run the script again.
And make sure that:
 * Oracle Database instance(s) are up and running
 * Oracle Database 11g Automatic Memory Management (AMM) is not setup
   (See Doc ID 749851.1)
 * The shared memory segments can be listed by command:
     # ipcs -m
Press Enter to proceed...


Recommended setting: vm.nr_hugepages = 996

最終計算出的vm.nr_hugepages建議值為996,tmd數字不吉利。

其中996乘以2MB=1992MB > sga_target(1970MB)

執行腳本除了看vm.nr_hugepages,也要關注下其他內容:

在執行之前,請注意以下事項:

(1)對于ASM實例,需要配置ASMM而不是AMM。
(2)“pga_gaggregate_target”位于SGA之外,在計算總體大小時應考慮到這一點。
(3)如果更改了DB SGA的大小,因為新的SGA將不適合以前的HugePage配置,因此最好禁用整個HugePage,用新SGA大小啟動DB,然后再次運行腳本。
并確保:
(1)數據庫實例是啟動運行的;
(2)HugePages and Oracle Database Automatic Memory Management (AMM) on Linux (Doc ID 749851.1)
(3)共享內存段可以通過以下命令列出:
# ipcs -m

停止數據庫實例

RAC:
srvctl stop instance -d dbname -i instance_name -o immediate
單機:
SQL> shutdown immediate

設置vm.nr_hugepages內核參數

寫入配置文件,永久生效

vi /etc/sysctl.conf
vm.nr_hugepages=996
wq

# sysctl -w vm.nr_hugepages=<value from above> 臨時改變,重啟失效。

本次示例:996

sysctl -p

查詢:

[root@cjc-db-01 ~]# grep Huge /proc/meminfo
AnonHugePages: 98304 kB
HugePages_Total: 996
HugePages_Free: 996
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB

啟動實例

RAC:
srvctl start instance -d dbname -i instance_name -o open
單機:
SQL> startup

查看alert_cjc.log日志信息:

Starting ORACLE instance (normal)
************************ Large Pages Information *******************
Per process system memlock (soft) limit = UNLIMITED
Total Shared Global Region in Large Pages = 1986 MB (100%)
Large Pages used by this instance: 993 (1986 MB)
Large Pages unused system wide = 3 (6144 KB)
Large Pages configured system wide = 996 (1992 MB)
Large Page size = 2048 KB
********************************************************************

檢查可用的hugepages

如果配置沒生效,需要重啟服務器;

[root@cjc-db-01 ~]# grep Huge /proc/meminfo
AnonHugePages: 94208 kB
HugePages_Total: 996
HugePages_Free: 787
HugePages_Rsvd: 784
HugePages_Surp: 0
Hugepagesize: 2048 kB

PageTables變小了;

[root@cjc-db-01 ~]# cat /proc/meminfo|grep PageTables
PageTables: 30368 kB

查看內存使用

[root@cjc-db-01 ~]# free -h
total        used        free      shared  buff/cache   available
Mem: 3.6G        2.4G        765M        9.4M        477M        343M
Swap: 2.0G         20K        2.0G

1.2 錯誤啟用HugePages方法

如果將HugePages設置低于sga_target,例如1000MB,小于 sga_target(1970MB)。

vm.nr_hugepages值從996改為1000/2=500。

停庫:

SQL> shutdown immediate

修改參數:

vi /etc/sysctl.conf
#vm.nr_hugepages=996
vm.nr_hugepages=500
wq
[root@cjc-db-01 ~]# sysctl -p

啟庫:

SQL>startup

查看alert_cjc.log日志信息:

Starting ORACLE instance (normal)
************************ Large Pages Information *******************
Per process system memlock (soft) limit = UNLIMITED
Total Shared Global Region in Large Pages = 994 MB (50%)
Large Pages used by this instance: 497 (994 MB)
Large Pages unused system wide = 3 (6144 KB)
Large Pages configured system wide = 500 (1000 MB)
Large Page size = 2048 KB
RECOMMENDATION:
Total System Global Area size is 1986 MB. For optimal performance,
prior to the next instance restart:
1. Increase the number of unused large pages by
at least 493 (page size 2048 KB, total size 986 MB) system wide to
get 100% of the System Global Area allocated with large pages
********************************************************************

告警日志有如下建議:

系統全局區域的總大小為1986 MB。為了獲得最佳性能,在下一次實例重新啟動之前:

在系統范圍內將未使用的大頁面數量增加至少493個(頁面大小2048 KB,總大小986 MB),以獲得100%的系統全局區域分配有大頁面。

查看:

頁表比正確配置的偏大

[root@cjc-db-01 ~]# cat /proc/meminfo|grep PageTables
PageTables: 34900 kB

使用了少量的HugePages

[root@cjc-db-01 ~]# grep Huge /proc/meminfo
AnonHugePages: 43008 kB
HugePages_Total: 500
HugePages_Free: 431
HugePages_Rsvd: 428
HugePages_Surp: 0
Hugepagesize: 2048 kB
[root@cjc-db-01 ~]# free -h
total        used        free      shared  buff/cache   available
Mem: 3.6G        1.4G        1.3G        237M        859M        1.0G
Swap: 2.0G          0B        2.0G

二、use_large_pages參數說明

默認參數:TRUE

當系統的HugePage被使用盡,只有small pages的情況下,SGA也會繼續運行。此時,Oracle實例就運行在內存使用混合模式(Mixed Mode)下。

SQL> show parameter use_large_pages
NAME             TYPE   VALUE
------------------------------------ ----------- ------------------------------
use_large_pages          string   TRUE

除了TURE,還支持ONLY和AUTO。

其中ONLY表示:Oracle實例只會使用HugePage作為內存使用,如果系統在AMM模式或者HugePage用盡的時候,數據庫就不能啟動。

測試ONLY值:

先備份參數文件:

[oracle@cjc-db-01 ~]$ cd $ORACLE_HOME/dbs
[oracle@cjc-db-01 dbs]$ cp spfilecjc.ora spfilecjc.ora.bak

修改參數:

SQL> alter system set use_large_pages=only scope=spfile;

重啟數據庫:

SQL> shutdown immediate
SQL> startup

報錯如下:

ORA-27137: unable to allocate large pages to create a shared memory segment
Linux-x86_64 Error: 12: Cannot allocate memory
Additional information: 2063597568
Additional information: 1

告警信息如下:

Starting ORACLE instance (normal)
************************ Large Pages Information *******************
Parameter use_large_pages = ONLY
Per process system memlock (soft) limit = UNLIMITED
Large Pages unused system wide = 500 (1000 MB)
Large Pages configured system wide = 500 (1000 MB)
Large Page size = 2048 KB


ERROR:
Failed to allocate shared global region with large pages, unix errno = 12.
Aborting Instance startup.
ORA-27137: unable to allocate Large Pages to create a shared memory segment
ACTION:
Total System Global Area size is 1992 MB. Prior to next instance restart:
1. Increase the number of unused large pages (page size 2048 KB)
to at least 996 (1992 MB) to allocate 100% System Global Area
with large pages.
********************************************************************

恢復備份參數文件:

[oracle@cjc-db-01 dbs]$ mv spfilecjc.ora spfilecjc.ora.bak.1
[oracle@cjc-db-01 dbs]$ mv spfilecjc.ora.bak spfilecjc.ora

重新啟動數據庫:

SQL> shutdown immediate
SQL> startup

三、HugePages說明

HugePages是Linux內核2.6中集成的一個特性。

啟用HugePages可以使操作系統支持大于默認值(通常為4KB)的內存頁。

使用HugePages時,操作系統頁表(虛擬內存到物理內存的映射)變小,可以減少訪問頁表條目所需的系統資源量,從而提高系統性能。

HugePage的大小從2MB到256MB不等,這取決于內核版本和硬件體系結構。

對于Oracle數據庫,使用HugePages可以減少操作系統頁表狀態的維護,并提高Translation Lookaside Buffer(TLB)命中率。

四、何時啟用HugePages

適用于:具有大型SGA和或會話較多的數據庫。

許多文檔將HugePages在Linux上的使用描述為一種可能性,但沒有充分強調HugePage在某些數據庫配置中成為一種要求。

對于一個SGA較小或連接用戶數量較少的數據庫(較小的“會話”),配置HugePages不會有任何改進。

但是,對于具有大SGA(2Gb以上)和許多連接用戶(會話>500)的數據庫,為了減少操作系統級別的內存使用并提高數據庫的整體性能,必須配置HugePages。

每個會話的前臺進程將具有一個稱為PageTable的內存結構,該進程通過該內存結構訪問SGA。

簡而言之,由于Linux上的默認頁面大小很小(這是英特爾的限制),應用程序使用的內存非常大,因此頁面表變得太大,無法管理。

HugePages是為克服這一問題而開發的解決方案。它絕對不是內核錯誤。

對于使用大量SGA區域的Oracle數據庫,如果不是必要的要求,則使用HugePages是最佳實踐。

SGA越大,每個進程的PageTable就越大。每個進程都有這個PageTable,所以對于許多連接的會話,所有PageTable的總和將變得更大。

內存結構PageTables的總大小可以通過以下內容查看:

grep PageTables /proc/meminfo

“free”實用程序不會顯式顯示這種類型的內存,但會將其包含在“cache”或“buff/cache”下的文件系統緩存中。

具有大型SGA和或許多會話的數據庫必須配置HugePages。

對于性能和較小的內存占用空間,建議使用它。

它可以是具有相對低的sga_starget=2-5Gb但具有許多會話=1000-2000的數據庫,或者具有巨大的sga_tharget=200Gb且很少會話=500的數據庫。

在這些特定的數據庫配置中,PageTables可能會消耗機器上的額外內存,該內存可能等于或大于SGA的總大小。

PageTables內存被添加到該機器上數據庫消耗的SGA和總PGA內存中。

例如:

(1)數據庫配置

sga_target=25 GB
sessions= 500

在高峰時間(連接了近500個會話)PageTables消耗機器物理內存中的20Gb

at peak time (near 500 sessions connected) PageTables consumes 20Gb from the physical memory of the machine

grep PageTables /proc/meminfo
PageTables: 26365324 kB

因此,該數據庫在高峰時段將使用25Gb(sga)+20Gb(PageTables)+10Gb(總PGA)=55Gb。

So this database at peak times would use 25Gb (sga) + 20Gb (PageTables) + 10Gb (total PGA) = 55Gb .

一臺具有45Gb物理RAM的機器,我們通常認為它可以很容易地容納具有25Gb SGA和10Gb總PGA的數據庫,

將開始使用10Gb交換。性能下降,如果更多的用戶連接到數據庫,我們最終將沒有內存。

A machine with 45Gb physical RAM, which we normally think would accommodate easily a database with 25Gb SGA and 10Gb total PGA, will start swapping using 10Gb of swap.

Performance goes down and if more users connect to the database, we would end up without memory.

(2)數據庫配置

sga_target = 250G
sessions= 5000

a.在配置HugePages之前,我們看到209Gb的巨大“buff/cache”幾乎等于SGA

a. before configuring HugePages we see a huge 'buff/cache' of 209Gb almost equal to the SGA

free -g
total   used   free   shared   buff/cache   available
Mem: 503 118    175       201    209            181
Swap: 19 1     18

b.配置HugePages后,“buff/cache”下降95%,“空閑”內存顯著增加

b. after configuring HugePages, 'buff/cache' drops by 95% and 'free' memory increase considerably

free -g
total   used   free   shared   buff/cache   available
Mem: 503    210    283       0         10              291
Swap: 19 1      18

(3)數據庫配置

sga_target=2Gb
sessions=500

a.如果沒有HugePages,在500個連接會話的情況下,PageTables會消耗機器物理內存中的2.5Gb

a. without HugePages, with 500 connected sessions, PageTables consumes 2.5Gb from the physical memory of the machine

grep PageTables /proc/meminfo
PageTables: 2617248 kB

b.配置HugePages后,在500個連接會話的情況下,PageTables僅消耗機器物理內存中的200Mb

b. after configuring HugePages, with 500 connected sessions, PageTables consumes only 200Mb from the physical memory of the machine

grep PageTables /proc/meminfo
PageTables: 226364 kB

啟用HugePages后,系統使用更少的PageTables,從而減少了維護和訪問它們的開銷。

Huge pages仍然固定在內存中,不會被替換,因此內核交換守護進程在管理它們時沒有任何工作要做,內核也不需要為它們執行頁面表查找。

較少的頁面數量減少了執行內存操作所涉及的開銷,也降低了訪問頁面表時出現瓶頸的可能性。

如果沒有HugePages,操作系統會將每個4KB(通常為默認頁面大小)的內存作為一個頁面,當它被分配給SGA時,該頁面的生命周期(dirty, free、映射到進程等)會由操作系統內核保持最新,因此會產生性能問題。

所以:

IF
SGA >= 2GB AND sessions >= 500
THEN
enabling HugePages becomes a requirement on Linux 64-bit system.

五、使用HugePages性能提升多大

下面的性能測試來自大佬"徐sir的IT之路"公眾號的《如何正確的在AIX 7.x系統中開啟LargePage for Oracle》文章,原文鏈接如下:

如何正確的在AIX 7.x系統中開啟LargePage for Oracle

數據庫版本:oracle 11.2.0.4
操作系統:AIX 7.2
服務器配置:POWER S914,1CPU,128G內存
內存儲配置:SGA65G+PGA20G
磁盤:華為S5500V5 雙活,128G緩存,每個存儲上24塊SAS 1.8T盤,RAID10陣列,劃分了3塊600G磁盤,使用了華為的多路徑軟件。

(1)未開啟16M大頁時,500用戶swingbench OE v1模型測試結果

圖片

(2)開啟16M大頁后,500用戶swingbenchOE v1模型測試結果

圖片圖片

比較下TPS由3386提升到4444,總體提升約31%左右,測試僅供參考。

六、HugePages配置的限制

Restrictions for HugePages Configurations

HugePages有以下限制:

HugePages has the following limitations:

1.必須取消設置MEMORY_TARGET和MEMORY_MAX_TARGET初始化參數。

例如,要取消設置數據庫實例的參數,請使用命令ALTER SYSTEM RESET。

You must unset both the MEMORY_TARGET and MEMORY_MAX_TARGET initialization parameters.
For example, to unset the parameters for the database instance, use the command ALTER SYSTEM RESET.

2.自動內存管理(AMM)和HugePages不兼容。

Automatic Memory Management (AMM) and HugePages are not compatible.

使用AMM時,通過在/dev/shm下創建文件來分配整個SGA內存。

當Oracle數據庫使用AMM分配SGA時,不保留HugePage。

Oracle 19C使用HugePages,必須禁用AMM(11g也需要禁用AMM)。

When you use AMM, the entire SGA memory is allocated by creating files under /dev/shm.
When Oracle Database allocates SGA with AMM, HugePages are not reserved.
To use HugePages on Oracle Database 19c, You must disable AMM.

3.如果在32位環境中使用VLM,則不能將HugePages用于Database Buffer cache。

您可以將HugePage用于SGA的其他部分,如shared_pool、large_pool等。

VLM(buffer cache)的內存分配是使用共享內存文件系統(ramfs/tmpfs/shmfs)完成的。

內存文件系統不保留或使用HugePages。

If you are using VLM in a 32-bit environment, then you cannot use HugePages for the Database Buffer cache.
You can use HugePages for other parts of the SGA, such as shared_pool, large_pool, and so on.
Memory allocation for VLM (buffer cache) is done using shared memory file systems (ramfs/tmpfs/shmfs).
Memory file systems do not reserve or use HugePages.

4.除非系統管理員通過修改可用頁面數或修改池大小來更改HugePages配置,否則系統啟動后不會分配或釋放HugePages。

如果在系統啟動期間內存中沒有保留所需的空間,則HugePages分配失敗。

HugePages are not subject to allocation or release after system startup, unless a system administrator changes the HugePages configuration, either by modifying the number of pages available, or by modifying the pool size.
If the space required is not reserved in memory during system startup, then HugePages allocation fails.

5.確保HugePages配置正確,因為如果應用程序未使用過多的HugePage,系統可能會耗盡內存。

Ensure that HugePages is configured properly as the system may run out of memory if excess HugePages is not used by the application.

6.如果實例啟動時HugePages不足,并且初始化參數use_large_pages設置為only,則數據庫無法啟動,并且會顯示一條警報日志消息,提供有關HugePages的必要信息。

If there is insufficient HugePages when an instance starts and the initialization parameter use_large_pages is set to only, then the database fails to start and an alert log message provides the necessary information on Hugepages.

七、參考鏈接

官方文檔位置:

Home / Database / Oracle Database Online Documentation 11g, Release 2 (11.2) / Database Administration / Database Administrator's Reference / G.2 Overview of HugePages

11g版本:

https://docs.oracle.com/cd/E11882_01/server.112/e10839/appi_vlm.htm#UNXAR385

19C版本:

https://docs.oracle.com/en/database/oracle/oracle-database/19/unxar/administering-oracle-database-on-linux.html#GUID-95CAEFDE-489B-453A-B5D5-4461DABBEEAD

其他:

Oracle Linux: Shell Script to Calculate Values Recommended Linux HugePages / HugeTLB Configuration(Doc ID 401749.1)
Oracle Linux: HugePages What It Is... and What It Is Not... (Doc ID 361323.1)
When And Why To Use HugePages on Linux x86-64? (Doc ID 2314903.1)
https://mp.weixin.qq.com/s?__biz=MzU0NTU1MzI5MQ==&mid=2247487446&idx=1&sn=0f1824462605f8c32ca711a68dcfd0ab&chksm=fb6a6132cc1de824a17cdd5e5c4a6596f6e0bb5a59fd955415123b188170fd1efd87b0a06891&mpshare=1&scene=24&srcid=0306G78oREb2qf1UN3etAF2V&sharer_shareinfo=636c40a2be34d2f77a73a414678736fa&sharer_shareinfo_first=da8e314bc06332f4854601ead7b59776#rd

八、hugepages_settings.sh腳本內容

#!/bin/bash
#
# hugepages_settings.sh
#
# Linux bash script to compute values for the
# recommended HugePages/HugeTLB configuration
# on Oracle Linux
#
# Note: This script does calculation for all shared memory
# segments available when the script is run, no matter it
# is an Oracle RDBMS shared memory segment or not.
#
# This script is provided by Doc ID 401749.1 from My Oracle Support
# http://support.oracle.com
# Welcome text
echo "
This script is provided by Doc ID 401749.1 from My Oracle Support
(http://support.oracle.com) where it is intended to compute values for
the recommended HugePages/HugeTLB configuration for the current shared
memory segments on Oracle Linux. Before proceeding with the execution please note following:
 * For ASM instance, it needs to configure ASMM instead of AMM.
 * The 'pga_aggregate_target' is outside the SGA and
   you should accommodate this while calculating the overall size.
 * In case you changes the DB SGA size,
   as the new SGA will not fit in the previous HugePages configuration,
   it had better disable the whole HugePages,
   start the DB with new SGA size and run the script again.
And make sure that:
 * Oracle Database instance(s) are up and running
 * Oracle Database 11g Automatic Memory Management (AMM) is not setup
   (See Doc ID 749851.1)
 * The shared memory segments can be listed by command:
     # ipcs -m
Press Enter to proceed..."


read


# Check for the kernel version
KERN=`uname -r | awk -F. '{ printf("%d.%d\n",$1,$2); }'`


# Find out the HugePage size
HPG_SZ=`grep Hugepagesize /proc/meminfo | awk '{print $2}'`
if [ -z "$HPG_SZ" ];then
    echo "The hugepages may not be supported in the system where the script is being executed."
    exit 1
fi


# Initialize the counter
NUM_PG=0


# Cumulative number of pages required to handle the running shared memory segments
for SEG_BYTES in `ipcs -m | cut -c44-300 | awk '{print $1}' | grep "[0-9][0-9]*"`
do
    MIN_PG=`echo "$SEG_BYTES/($HPG_SZ*1024)" | bc -q`
    if [ $MIN_PG -gt 0 ]; then
        NUM_PG=`echo "$NUM_PG+$MIN_PG+1" | bc -q`
    fi
done


RES_BYTES=`echo "$NUM_PG * $HPG_SZ * 1024" | bc -q`


# An SGA less than 100MB does not make sense
# Bail out if that is the case
if [ $RES_BYTES -lt 100000000 ]; then
    echo "***********"
    echo "** ERROR **"
    echo "***********"
    echo "Sorry! There are not enough total of shared memory segments allocated for
HugePages configuration. HugePages can only be used for shared memory segments
that you can list by command:
    # ipcs -m
of a size that can match an Oracle Database SGA. Please make sure that:
 * Oracle Database instance is up and running
 * Oracle Database 11g Automatic Memory Management (AMM) is not configured"
    exit 1
fi


# Finish with results
case $KERN in
    '2.4') HUGETLB_POOL=`echo "$NUM_PG*$HPG_SZ/1024" | bc -q`;
           echo "Recommended setting: vm.hugetlb_pool = $HUGETLB_POOL" ;;
    '2.6') echo "Recommended setting: vm.nr_hugepages = $NUM_PG" ;;
    '3.8') echo "Recommended setting: vm.nr_hugepages = $NUM_PG" ;;
    '3.10') echo "Recommended setting: vm.nr_hugepages = $NUM_PG" ;;
    '4.1') echo "Recommended setting: vm.nr_hugepages = $NUM_PG" ;;
    '4.14') echo "Recommended setting: vm.nr_hugepages = $NUM_PG" ;;
    '5.4') echo "Recommended setting: vm.nr_hugepages = $NUM_PG" ;;
    *) echo "Kernel version $KERN is not supported by this script (yet). Exiting." ;;
esac


# End
責任編輯:武曉燕 來源: IT小Chen
相關推薦

2020-08-17 17:47:30

內存技術測試

2014-07-18 14:10:07

WIFI華為

2010-10-28 15:15:08

oracle內存參數

2010-04-06 12:39:15

Oracle數據庫

2013-09-24 15:19:28

甲骨文Oracle數據庫

2009-01-07 09:22:00

2009-07-30 18:22:14

OracleTimesTenIn-Memory D

2010-09-14 11:29:43

谷歌

2013-07-22 09:43:29

2010-12-21 09:50:57

Ping交換機端口端口故障

2013-01-15 10:30:45

Windows 8Metro

2010-01-12 09:25:17

Windows 7死機系統特效

2009-07-18 16:43:09

光纖鏈路故障接線端面臟污

2023-12-24 22:33:32

宕機Twitter馬斯克

2009-08-01 15:47:04

網線故障

2010-05-27 17:10:03

MySQL數據庫內存

2023-02-10 09:21:31

PG數據庫內存

2012-12-12 09:57:12

Chrome負載均衡

2010-07-08 09:53:57

SQL Server

2009-12-24 14:17:27

安全威脅Oracle數據庫
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 久久国产亚洲 | 国产精品大片 | 国产精品久久久久久久久久久久久 | 综合一区二区三区 | 成人在线播放 | 91观看| 久久久久网站 | av中文字幕在线 | 久久久国产一区二区三区 | 伊人网在线播放 | 免费黄色的视频 | 国产精品久久久久一区二区三区 | 久久综合伊人一区二区三 | 久久久激情视频 | 国产一区二区三区精品久久久 | 精品国模一区二区三区欧美 | 亚洲视频在线看 | 亚洲国产精品久久人人爱 | 国产精品亚洲精品久久 | 五月婷婷导航 | av毛片| 日产精品久久久一区二区福利 | 免费国产视频 | 天天操,夜夜爽 | 午夜播放器在线观看 | 欧美性精品 | 久久99精品国产麻豆婷婷 | 日本色综合 | 91久久精品国产91久久 | av男人的天堂在线 | 国产精品视频在线播放 | 色爱综合网 | 亚洲视频精品在线 | 成人18亚洲xxoo | 日韩精品一区二区三区免费观看 | 日本一二三区电影 | 欧美在线观看一区二区 | 91九色视频在线 | 一级aaaaaa毛片免费同男同女 | 国产一区二区三区在线 | 一区二区三区四区免费视频 |