Shulou(Shulou.com)05/31 Report--

This article mainly introduces how to configure HugePages memory in Oracle, which is very detailed and has certain reference value. Friends who are interested must finish it!

Configure Hugepages for the oracle server

1.1. check whether the current system is equipped with the value HugePages.

In the following query, several values related to HugePages are all 0, indicating that the current value HugePages is not assigned, and then you can see that Hugepagesize is 2MB.

$grep Huge / proc/meminfo

HugePages_Total: 0

HugePages_Free: 0

HugePages_Rsvd: 0

Hugepagesize: 2048 kB

1.2.Modification of user's memlock restrictions (root operation)

It is realized by modifying the / etc/security/limits.conf value file.

The value of this parameter is usually slightly smaller than the current installed system memory. If your current system memory is 64GB, you can set it as follows

* soft memlock 664377747

* hard memlock 664377747

The above settings are set in kb and will not degrade system performance. At a minimum, the matching value should be slightly greater than the sum of all the SGA on the system.

Use ulimit-l to verify the setting

1.3.Disallow AMM (Oracle 11g)

If the current version of Oracle is 10g, you can skip this step.

If the current version of Oracle is 11g, AMM needs to be disabled because the AMM (Automatic Memory Management) feature is not compatible with Hugepages.

ALTER SYSTEM RESET memory_target SCOPE=SPFILE

ALTER SYSTEM RESET memory_max_target SCOPE=SPFILE

ALTER SYSTEM SET sga_target=g SCOPE=SPFILE

ALTER SYSTEM SET pga_aggregate_target=g SCOPE=SPFILE

SHUTDOWN IMMEDIATE

STARTUP

-

Disable memory_max_target and memory_target parameter methods

Note here that the official document says "unset", and the direct alter system set memory_target=0 scope=spfile; is unsuccessful. If you directly set it to '0blank, you will make the following error

ORA-00843: Parameter not taking MEMORY_MAX_TARGET into account

ORA-00849: SGA_TARGET 35433480192 cannot be set to more than MEMORY_MAX_TARGET 0.

ORA-01078: failure in processing system parameters

By creating the pfile.ora file, and then deleting the two parameters "MEMORY_TARGET/MEMORY_MAX_TARGET" from the file. Then create a spfile.

-

1.4.Compute the value of vm.nr_hugepages (executed by Oracle users)

Use the script hugepages_settings.sh provided by Oracle to calculate the value of vm.nr_hugepages

Make sure that all Oracle instances are started and that ASM is started before executing the script (if any)

If the HugePages configuration is feasible, he will recommend a memory size, and if not, an error will be reported.

$. / hugepages_settings.sh (specific script, shown later)

...

Recommended setting: vm.nr_hugepages = 1496 (sga_m / 4m + 3)

1.5.Edit / etc/sysctl.conf to set vm.nr_hugepages parameters (root operation)

$sysctl-w vm.nr_hugepages = 125447

$sysctl-p

Stop all Instance and restart server

All the steps above have been dynamically modified, but the allocation of HugePages requires a restart of server to take effect.

1.7. Verify the matching value

The values of HugePages-related parameters will change dynamically as the instance on the current server stops and starts.

In general, the value of HugePages_Free should be less than that of HugePages_Total, and the value of HugePages_ Rsvd should be non-zero when HugePages is used.

$grep Huge / proc/meminfo

HugePages_Total: 131

HugePages_Free: 20

HugePages_Rsvd: 20

Hugepagesize: 2048 kB

As in the following case, when the only instance on the server is shut down, the value of HugePages_Rsvd is zero. And HugePages_Free equals HugePages_Total.

$grep Huge / proc/meminfo

HugePages_Total: 131

HugePages_Free: 131

HugePages_Rsvd: 0

Hugepagesize: 2048 kB

Matters needing attention in using HugePages

There are three scenarios in which HugePages should be reconfigured

A, the increase or decrease of physical memory

B. Add or remove Instance on the current server

C, the SGA size of Instance increases or decreases

Failure to adjust HugePages may cause the following problems

A, database performance underground

B. insufficient memory or excessive use of swap space

C. The database instance cannot be started

D, critical system service failure

Third, the common fault handling of HugePages characteristics

Symptom A:

System is running out of memory or swapping

Possible Cause:

Not enough HugePages to cover the SGA (s) and therefore the area reserved for HugePages are wasted where SGAs are allocated through regular pages.

Troubleshooting Action:

Review your HugePages configuration to make sure that all SGA (s) are covered.

Symptom B:

Databases fail to start

Possible Cause:

Memlock limits are not set properly

Troubleshooting Action:

Make sure the settings in limits.conf apply to database owner account.

Symptom C:

One of the database fail to start while another is up

Possible Cause:

The SGA of the specific database could not find available HugePages and remaining RAM is not enough.

Troubleshooting Action:

Make sure that the RAM and HugePages are enough to cover all your database SGAs

Symptom D:

Cluster Ready Services (CRS) fail to start

Possible Cause:

HugePages configured too large (maybe larger than installed RAM)

Troubleshooting Action:

Make sure the total SGA is less than the installed RAM and re-calculate HugePages.

Symptom E:

HugePages_Total = HugePages_Free

Possible Cause:

HugePages are not used at all. No database instances are up or using AMM.

Troubleshooting Action:

Disable AMM and make sure that the database instances are up.

Symptom F:

Database started successfully and the performance is slow

Possible Cause:

The SGA of the specific database could not find available HugePages and therefore the SGA is handled by regular pages, which leads to slow performance

Troubleshooting Action:

Make sure that the HugePages are many enough to cover all your database SGAs

Reference: [ID 361468.1]

4. How to control whether the database SGA uses Hugepages?

In versions prior to 11.2.0.2, SGA for database could only choose to use hugepages entirely or not to use hugepages at all.

11.2.0.2 and later, oracle adds a new parameter "USE_LARGE_PAGES" to manage how databases use hugepages.

The USE_LARGE_PAGES parameter has three values: "true" (default), "only", and "false" and "auto" (since 11.2.0.3 patchset).

1. Now the default value is "true". If the system sets Hugepages, SGA will give priority to using hugepages as much as it can.

11.2.0.2 SGA will not use hugepages if there is not enough hugepages. This can lead to ORA-4030 errors because hugepages has been allocated from physical memory, but SGA does not use it, but uses other parts of memory, resulting in insufficient memory resources

However, in version 11.2.0.3, this usage strategy has been changed, and SGA can use hugepages in part and small pages in the rest. In this way, SGA will have limited use of hugepages, and then use regular sized pages after hugepages is used up.

two。 If set to "false", SGA will not use hugepages

3. If set to "only" if the hugepages size is not enough, the database instance cannot be started (to prevent memory overflow).

4. After version 11.2.0.3, it can be set to "auto". This option triggers the oradism process to reconfigure the linux kernel to increase the number of hugepages. Oradism needs to be given the appropriate permissions, as follows

-rwsr-x--- 1 root

It will not change the hugepages value in the / etc/sysctl.conf file, and when OS restarts, the system will revert to the hugepages value configured in / etc/sysctl.conf.

V. matters needing attention

A, HugePage uses shared memory, which is dynamically allocated and retained during operating system startup because they will not be replaced.

B, due to the characteristic that it will not be replaced, the memory using hugepage cannot be used by other processes. Therefore, it is necessary to set this value reasonably to avoid wasting memory.

C. For servers that only use Oracle, set Hugepage to the size of SGA (the sum of all instance SGA).

D, if you add HugePage or physical memory, or if the current server adds a new instance and the SGA changes, you should reset the required HugePage.

-- hugepages_settings.sh script

If the HugePages configuration is feasible, he will recommend a memory size, and if not, an error will be reported.

#! / 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 SGA 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);}' `

# 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.2') echo "Kernel version $KERN is not supported. Exiting."

'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"

Esac

# End

The results are as follows

[oracle@n3 ~] $chmod + x hugepages_settings.sh

[oracle@n3 ~] $sh hugepages_settings.sh

Press Enter to proceed...

Recommended setting: vm.nr_hugepages = 125447

These are all the contents of the article "how to configure HugePages memory in Oracle". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.