amm与hugepage是否能同时使用

今天遇到个现象，在开启hugepage的前提下，设置数据库内存管理模式为amm，发现集群启动不了，无法申请相应内存

从MOS的官方解释，AMM与HUGEPAGE不兼容

Following are the limitations of using HugePages:

• • The Automatic Memory Management (AMM) and HugePages are not compatible. With AMM the entire SGA memory is allocated by creating files under /dev/shm. When Oracle Database allocates SGA that way HugePages are not reserved. You must disable AMM on Oracle Database 11g to use HugePages.
    
    
  • If you are using VLM in a 32-bit environment, then you cannot use HugePages for the Database Buffer cache. HugePages can be used for other parts of SGA like shared_pool, large_pool, and so on. Memory allocation for VLM (buffer cache) is done using shared memory file systems (ramfs/tmpfs/shmfs). HugePages does not get reserved or used by the memory file systems.
    
    
  • HugePages are not subject to allocation or release after system startup, unless a system administrator changes the HugePages configuration by modifying the number of pages available, or the pool size. If the space required is not reserved in memory during system startup, then HugePages allocation fails.

SOLUTION

Step 1:  Convert AMM (Automatic Memory Management) to ASMM (Automatic Shared Memory Management)

Here the first point is, the use of AMM (memory_target and memory_max_target) is absolutely incompatible with HugePages.
Only ASMM is supported with LINUX x86-64 Hugepages (you may need to refer Doc ID 1134002.1 for further details).

Now in case if your Database is configured in AMM, you may need to convert AMM to ASMM. For this you may need to check the usage of SGA and PGA and then
set the parameters accordingly. You can use below SQLs as a script to find out the memory configuration and usage.

This will generate two spool files (mem_config.log, mem_usage.log).
Based on the report on these spool files, you can convert AMM to ASMM and configure appropriate values.

set pagesize 1000 lines 1000 linesize 1000
spool mem_config.log
prompt memory configuration parameters:
prompt ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
break on dbname nodup
col dbname format a30
col name format a45
col value format a20
select sys_context ('USERENV', 'DB_NAME') dbname,
name,
value
from v$parameter
where ( name like '%memory%'
or name like '%sga%'
or name like '%pool%'
or name like '%cache%' )
and ( name like '%size%'
or name like '%target%' )
order by name;

prompt startup values:
prompt ~~~~~~~~~~~~~~~
col parm format a40
col sessval format a15
col instval format a15
select a.ksppinm parm,
b.ksppstvl sessval,
c.ksppstvl instval
from sys.x$ksppi a,
sys.x$ksppcv b,
sys.x$ksppsv c
where a.indx = b.indx
and a.indx = c.indx
and a.ksppinm in ( '__shared_pool_size', '__db_cache_size', '__large_pool_size', '__java_pool_size',
'__streams_pool_size', '__pga_aggregate_target', '__sga_target', '_kghdsidx_count',
'_ksmg_granule_size', '_memory_imm_mode_without_autosga' );

spool off
spool mem_usage.log
prompt memory advisories:
prompt ~~~~~~~~~~~~~~~~~~
-- memory target advisory
select *
from v$memory_target_advice;

-- sga target advisory
select *
from v$sga_target_advice;

prompt sgastat details:
prompt ~~~~~~~~~~~~~~~~
break on pool nodup
col bytes format 999, 999, 999, 999, 999, 999
select pool,
name,
bytes
from (select pool,
name,
bytes
from v$sgastat
where pool is null
order by bytes desc)
where rownum <= 5
union all
select pool,
name,
bytes
from (select pool,
name,
bytes
from v$sgastat
where pool = 'shared pool'
order by bytes desc)
where rownum <= 5
union all
select pool,
name,
bytes
from (select pool,
name,
bytes
from v$sgastat
where pool = 'large pool'
order by bytes desc)
where rownum <= 5
union all
select pool,
name,
bytes
from (select pool,
name,
bytes
from v$sgastat
where pool = 'java pool'
order by bytes desc)
where rownum <= 5;

-- relevant only if PX buffers are occupying more memory in shared pool
show parameter parallel_automatic_tuning
select a.ksppinm name,
b.ksppstvl value,
b.ksppstdf defalt,
decode (a.ksppity, 1, 'boolean',
2, 'string',
3, 'number',
4, 'file',
a.ksppity) type,
a.ksppdesc description
from sys.x$ksppi a,
sys.x$ksppcv b
where a.indx = b.indx
and a.ksppinm like '%use%large%pool%'
order by name;

prompt sga, pga usage:
prompt ~~~~~~~~~~~~~~~
select name,
bytes
from v$sgainfo;

select round(sum(bytes) / 1024 / 1024, 2) current_sga_size_mb
from v$sgastat;

select round(sum(bytes) / 1024 / 1024, 2) hist_sga_size_mb
from dba_hist_sgastat;

select round(sum(bytes) / 1024 / 1024, 2) max_sga_size_mb
from v$sgainfo
where name = 'Maximum SGA Size';

select round(( value ) / 1024 / 1024, 2) current_pga_in_use_mb
from v$pgastat
where name = 'total PGA inuse';

select round(( value / 1024 / 1024 ), 2) max_pga_allocated_mb
from v$pgastat
where name = 'maximum PGA allocated';

select round(max(value) / 1024 / 1024, 2) hist_max_pga_allocated_mb
from dba_hist_pgastat
where name = 'maximum PGA allocated';

select round(value / 1024 / 1024, 2) pga_target_mb
from v$pgastat
where name = 'aggregate PGA target parameter';

select component,
current_size
from v$sga_dynamic_components;

col component for a25
select component,
round(( min(final_size / 1024 / 1024) ), 2) low_mb,
round(( max(final_size / 1024 / 1024) ), 2) high_mb
from v$sga_resize_ops
group by component
order by component;

spool off

Step: 2  Once we identify the memory usage (SGA, PGA), then we need to configure/ re-configure those parameters in existing instance. 
               This will ensure lower limit for SGA, PGA and Dynamic memory components.

SGA_TARGET
SGA_MAX_TARGET
PGA_AGGREGATE_TARGET

SHARED_POOL_SIZE
DB_CACHE_SIZE
LARGE_POOL_SIZE
JAVA_POOL_SIZE
STREAMS_POOL_SIZE

Step: 3  Unset the AMM memory parameters

MEMORY_MAX_TARGET
MEMORY_TARGET

Once we complete this step, the conversion part is completed from AMM to ASMM.

Step: 4  Configuring HugePages

Now coming back to HugePages configuration part, here you may need to involve your Linux Admin and cross-check the environment.

You need to check how much RAM you have available on the system. HugePages run in physical RAM and are pinned in it, so you want to know
how much RAM is available and how much you can use for databases. Also you may need to reboot your server, and may need a maintenance
window for this.

You can go through below documentation, metalink notes for further guidance on configuring HugePages.

HugePages on Oracle Linux 64-bit (Doc ID 361468.1)
https://docs.oracle.com/cd/E37670_01/E37355/html/ol_config_hugepages.html
HugePages on Linux: What It Is... and What It Is Not... (Doc ID 361323.1)

The vm.nr_hugepages defines the number of hugepages. And (vm.nr_hugepages * Hugeagesize) decided the amount of memory available for HugePage.
(you can check the Hugepagesize by using - grep -i "Hugepagesize" /proc/meminfo).

After this you should see output like example below that indicates HugePage has been configured:

Example:

# grep HugePages /proc/meminfo
HugePages_Total: 1496
HugePages_Free: 485
HugePages_Rsvd: 446
HugePages_Surp: 0

Once HugePage is configured in the system the database automatically uses hugepages for SGA allocation.

Ensure the(vm.nr_hugepages * Hugepagesize) i.e. the HugePage memory should be greater that than sum of all SGAs i.e sga_max_size
(if more than one database in the server) in the system.

Step: 5  Monitoring and fine tuning HugePages

In the alert log you can see the HugePage information during instance startup.
Also from 11.2.0.2 onwards, there is a parameter called USE_LARGE_PAGES that provides very useful information in the alert log.

Once configured, you can fine tune the HugePage configuration by using script mentioned in below document:

Shell Script to Calculate Values Recommended Linux HugePages / HugeTLB Configuration (Doc ID 401749.1)

Incorrect configuration of HugePages can lead to many problems. Some of them includes - hugepages not used, poor db performance, running out of
memory or excessive swapping, db instance not start etc.

Regarding Trouble shooting and Known issues, you can refer below metalink note-

HugePages on Oracle Linux 64-bit (Doc ID 361468.1)