![\"twitter\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/twitter.png\" "\\"Share")
<\/a><\/a>![\"linkedin\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/linkedin.png\" "\\"Share")
<\/a>![\"mail\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/mail.png\" "\\"Share")
<\/a>![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2022\/07\/oracle-300x127.jpg\")
<\/p>\n
<\/p>\n
Hello,<\/p>\n
si comme bon nombre de DBAs Oracle, vous avez install\u00e9 et configur\u00e9 une instance de bases de donn\u00e9es, que ce soit sur un syst\u00e8me Linux classique ou une machine Exadata, vous avez surement \u00e9t\u00e9 amen\u00e9 \u00e0 mettre en place ce que l’on appelle des “HugePages”.<\/p>\n
Les HugePages sont des pages de 2Mo (par d\u00e9faut), prises en charge par le kernel linux, que l’administrateur syst\u00e8me et\/ou bases de donn\u00e9es peut utiliser pour les besoins d’une application. Il est tout \u00e0 fait possible \u00e9galement, pour des machines Exadata par exemple, de d\u00e9finir des tailles de pages au del\u00e0 de 2Mo.\u00a0 Si vous manipuler une base de forte volum\u00e9trie avec des fonctionnalit\u00e9s HCC (Hybrid Columnar Compression), choisissez une taille de page de 1Go .<\/p>\n
Par d\u00e9faut, une page sur un syst\u00e8me Linux a une taille de 4Ko. Or, lorsqu’un SGBDR traite un volume de donn\u00e9es cons\u00e9quent, il est toujours b\u00e9n\u00e9fique de limiter les aller-retour entre les diff\u00e9rentes pages de la m\u00e9moire virtuelle et la m\u00e9moire physique support\u00e9e par le serveur via la gestion de la table de pages (la TLB) et la MMU (Memory Manager Unit).<\/p>\n
L’id\u00e9e est de positionner des pages plus grandes afin de stocker une quantit\u00e9 de donn\u00e9es plus importante, et surtout de les “fixer” en m\u00e9moire afin d’\u00e9viter tout ph\u00e9nom\u00e8ne de swapping. Ceci r\u00e9duit \u00e9galement\u00a0 la charge de TLB en r\u00e9duisant la fragmentation m\u00e9moire allou\u00e9e pour les processus.<\/p>\n
Rappelons que dans le meilleur des mondes possibles, un serveur de bases de donn\u00e9es ne doit pas ou peu swapper ! Et ce, que ce soit sous un syst\u00e8me linux ou bien Windows.<\/p>\n
Attention, le m\u00e9canisme de prise en charge des “HugePages”, y compris en 19c est toujours incompatible avec la gestion AMM Oracle (Automatic Memory Management). D\u00e9finissez une SGA_TARGET et une PGA_AGGREGATE_TARGET et oubliez le MEMORY_TARGET.<\/p>\n
<\/p>\n
<\/p>\n
Avant la version 19c, et ce depuis la version 11.2.0.3, Oracle disposait d\u00e9j\u00e0 d’un param\u00e8tre appel\u00e9 USE_LARGE_PAGES<\/strong> pour la prise en charge des HugePages au sein d’une instance Oracle.<\/p>\n Ce param\u00e8tre comportait 3 valeurs possibles :<\/p>\n <\/p>\n <\/p>\n Avec l’arriv\u00e9e de la version 19c, Oracle a valid\u00e9 2 nouvelles valeurs pour son param\u00e8tre USE_LARGE_PAGES<\/strong>.<\/p>\n <\/p>\n <\/p>\n Voici un test-case permettant de voir comment se comporte le syst\u00e8me linux, et notre base de donn\u00e9es vis \u00e0 vis de la configuration de ces param\u00e8tres.<\/p>\n Pour notre exemple, nous disposons d’un syst\u00e8me Linux Red Hat 8.3 et d’une instance Oracle version 19.10.<\/p>\n Celui ci dispose de 2 vCPU et 4 Go de RAM<\/p>\n <\/p>\n Afin de pouvoir b\u00e9n\u00e9ficier de la prise en charge des HugesPages pour ce serveur, il faudra d\u00e9finir des “limits” pour le compte Oracle de notre serveur. <\/p>\n <\/p>\n Nous nous assurons que ce serveur ne comporte aucune configuration de HugePages \u00e9ventuelle.<\/p>\n <\/p>\n Les valeurs “HugePages_Total”<\/strong> et “vm.nr_hugepages<\/strong>” sont bien nulles.<\/p>\n Mis \u00e0 part la “limit” d\u00e9finie sur la m\u00e9moire \u00e0 figer pour le compte Oracle, nous n’avons pas de trace de configuration HugePages sur ce serveur.<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n Voici les valeurs que nous avons d\u00e9fini sur l’init.ora de notre instance. Cette derni\u00e8re se nomme CAPDATADB.<\/p>\n <\/p>\n <\/p>\n Nous partons sur une instance comportant 1,2Go de SGA. Avec le mode AUTO, Oracle laisse la possibilit\u00e9 de monter des HugesPages.<\/p>\n On d\u00e9marre l’instance sans monter la base.<\/p>\n <\/p>\n <\/p>\n <\/p>\n Dans l’alert.log de la base, nous voyons que l’instance Oracle a r\u00e9ussi \u00e0 provisionner des pages de 2Mo au moment du d\u00e9marrage.<\/p>\n <\/p>\n Oracle nous indique qu’il a r\u00e9ussi \u00e0 monter 601 pages de 2Mo afin de les utiliser pour la SGA de notre instance.<\/p>\n S’il l’on regarde les param\u00e8tres kernel, nous voyons bien la pr\u00e9sence de ces pages (HugePages_Total \u00e0 601)<\/p>\n <\/p>\n <\/p>\n Une modification automatique du param\u00e8trage “sysctl” nous assure la prise en charge des HugesPages.<\/p>\n <\/p>\n <\/p>\n <\/p>\n S’il l’on regarde du cot\u00e9 des ipc , l’outil “sysresv<\/strong>” fourni par Oracle nous donne toutes les informations n\u00e9cessaires sur la m\u00e9moire partag\u00e9e de notre instance et les limites de notre compte Oracle.<\/p>\n <\/p>\n On retrouve pour le “shmid” 1\u00a0 les 1,2Go provisionn\u00e9s pour la SGA. Le “max locked memory” \u00e0 1,5Go pour le compte Oracle.<\/p>\n <\/p>\n A noter \u00e9galement que lorsque l’on arr\u00eate l’instance, les HugesPages restent actifs. Mais les HugesPages sont toujours pr\u00e9sents. Les 601 pages, toujours pr\u00e9sentes, mais vues comme libres, dans la configuration kernel.<\/p>\n <\/p>\n avec le mode AUTO_ONLY, pas de souci pour ce server, dans la mesure ou nous avons deja 601 HugePages provisionn\u00e9es et libres.<\/p>\n <\/p>\n Au d\u00e9marrage<\/p>\n <\/p>\n Nous pouvons m\u00eame voir qu’Oracle s’attribue 100% de la SGA dans les pages de 2Mo.<\/p>\n 602 pages prises par Oracle et que le kernel enregistrera apr\u00e8s d\u00e9marrage<\/p>\n <\/p>\n Au niveau des ipc rien n’a chang\u00e9 dans l’attribution de la m\u00e9moire partag\u00e9e. Nous avons toujours le d\u00e9coupage SGA de 1,2Go pris sur le segment num\u00e9ro 5, et le reste repr\u00e9sentant les “fixed size”, “redo buffers”.<\/p>\n <\/p>\n <\/p>\n Mais que se passe-t-il si l’on choisit une SGA de taille plus importante que la “soft” limite d\u00e9finie pour le compte Oracle. Rappelons que nous avions cap\u00e9 \u00e0 1,5Go les limites en terme de “memlock” pour notre user Oracle.<\/p>\n Supposons que nous choisissons les valeurs suivantes dans l’init.ora de notre instance. 1,8Go pour notre SGA.<\/p>\n <\/p>\n Au d\u00e9marrage de l’instance<\/p>\n <\/p>\n L’instance d\u00e9marre, mais que dit l’alert.log :<\/p>\n <\/p>\n Notre instance r\u00e9clame 1,8Go de SGA. Le kernel n’a pu lui fournir que 749 pages de 2Mo, soit 1498Mo, alors qu’Oracle en r\u00e9clame 905.<\/p>\n le reste de la m\u00e9moire SGA va donc se positionner dans des pages conventionnelles de 4Ko, soit 79752 pages, donc 311Mo.<\/p>\n S’il l’on regarde les segments de m\u00e9moire partag\u00e9e, nous voyons des espaces fragment\u00e9es , avec au plus, un espace contigu de 900Mo sur le shmid 9. Nous voyons \u00e9galement le shmid 14 repr\u00e9sentant les 311 Mo en pages de 4Ko.<\/p>\n la situation n’est pas la plus optimale, surtout dans un syst\u00e8me ou l’on charge en m\u00e9moire de grandes volum\u00e9tries de donn\u00e9es. Il est fort possible que cette instance fasse plus de lectures\/\u00e9critures des IO dans la mesure ou nos segments de m\u00e9moire sont fragment\u00e9s.<\/p>\n <\/p>\n mais alors, qu’en est-il du mode AUTO_ONLY si je d\u00e9passe la valeur “soft limit” des 1,5Go ?<\/p>\n Nous avons auparavant d\u00e9j\u00e0 allou\u00e9 901 pages de 2Mo au niveau du kernel. Ces pages sont pr\u00e9sentes, m\u00eame avec notre instance arr\u00eat\u00e9e.<\/p>\n Mais au d\u00e9marrage de notre instance avec 1,8Go de SGA configur\u00e9e<\/p>\n <\/p>\n <\/p>\n et l’alert.log est claire<\/p>\n <\/p>\n <\/p>\n Nous rencontrons une erreur ORA 27125, impossible d’affecter les pages demand\u00e9es, l’instance ne d\u00e9marre pas. <\/p>\n Comme nous venons de voir, Oracle, depuis la version 19c, est capable de r\u00e9clamer dynamiquement au kernel des pages de 2Mo, sans pour autant les avoir provisionner dans le fichier “sysctl.conf<\/strong>“. Il est cependant, indispensable, de fixer des soft\/hard limits au user Oracle afin de pouvoir verrouiller des pages en m\u00e9moire.<\/p>\n Lors du reboot du server, le syst\u00e8me dispose de pages conventionnelles de 4Ko avec les param\u00e8tres “vm.nr_hugepages<\/strong>” et “HugePages_Total<\/strong>”\u00a0 \u00e0 0.<\/p>\n <\/p>\n Voici les configurations que je pr\u00e9coniserais pour un syst\u00e8me Linux 64 bits si vous souhaitez profiter de la gestion dynamique des HugePages par Oracle.<\/p>\n <\/p>\n Dans tous les cas, sur un serveur Linux d\u00e9di\u00e9 pour des instances de bases de donn\u00e9es, Oracle recommande de d\u00e9sactiver les Transparent Huges Pages (THP) dans la mesure ou ces pages sont dynamiquement “swappable” . Ce qui peut \u00eatre tr\u00e8s probl\u00e9matique, notamment dans le cadre d’un environnement RAC (\u00e9viction de n\u0153ud possible).<\/p>\n <\/p>\n <\/p>\n \ud83d\ude42<\/p>\n <\/p>\n <\/p>\n Emmanuel RAMI<\/p>\n Hello, si comme bon nombre de DBAs Oracle, vous avez install\u00e9 et configur\u00e9 une instance de bases de donn\u00e9es, que ce soit sur un syst\u00e8me Linux classique ou une machine Exadata, vous avez surement \u00e9t\u00e9 amen\u00e9 \u00e0 mettre en… Continuer la lecture \n
\nMettez en place les pr\u00e9requis syst\u00e8me n\u00e9cessaires pour les versions ant\u00e9rieures \u00e0 Oracle 19c.<\/li>\n<\/ul>\nla gestion des HugePages depuis Oracle 19c<\/h2>\n
\n
\nDans ce cas la, si le kernel dispose d’assez de m\u00e9moire (hard limit) pour configurer des HugePages, Oracle d\u00e9marre avec 100% de sa SGA_TARGET avec des pages de 2Mo (soft limit). Oracle utilisera des pages conventionnelles de 4Ko si la place n’est pas suffisante.<\/li>\n
\nA noter que sur Exadata, c’est la valeur qui est par d\u00e9faut sur chaque instance.<\/li>\n<\/ul>\nFonctionnement<\/h2>\n
[root@ip-172-44-2-107 ~]# cat \/etc\/redhat-release\r\nRed Hat Enterprise Linux release 8.3 (Ootpa)<\/pre>\n
[root@ip-172-44-2-107 ~]# cat \/proc\/meminfo | grep -i MemTotal\r\nMemTotal: 3823056 kB\r\n\r\n[root@ip-172-44-2-107 ~]# cat \/proc\/cpuinfo | grep -i core\r\ncore id : 0\r\ncpu cores : 2\r\ncore id : 1\r\ncpu cores : 2<\/pre>\n
Pr\u00e9requis<\/h3>\n
\nNous pourrons partir du principe que, le compte Oracle pourra, au plus, bloquer en m\u00e9moire jusqu’\u00e0 1,5Go.
\nA d\u00e9finir par le compte “root<\/strong>” dans le fichiers “limits.conf”.<\/p>\n # vi \/etc\/security\/limits.conf\r\n....\r\ndomain type item value\r\noracle soft memlock 1536000\r\noracle hard memlock 1536000\r\n<\/pre>\n
\r\n[root]# sysctl -a | grep -i hugepages\r\nvm.nr_hugepages = 0\r\nvm.nr_hugepages_mempolicy = 0\r\nvm.nr_overcommit_hugepages = 0\r\n\r\n[root]# cat \/proc\/meminfo | grep -i Huge\r\nAnonHugePages: 0 kB\r\nShmemHugePages: 0 kB\r\nHugePages_Total: 0\r\nHugePages_Free: 0\r\nHugePages_Rsvd: 0\r\nHugePages_Surp: 0\r\nHugepagesize: 2048 kB\r\nHugetlb: 0 kB\r\n<\/pre>\n
[oracle]$ ulimit -Sl\r\n1536000<\/pre>\n
Validation du param\u00e8tre USE_LARGE_PAGES<\/h2>\n
Cas du mode AUTO<\/h3>\n
[oracle@ dbs]$ cat initCAPDATADB.ora\r\n...\r\n*.sga_target=1200M\r\n*.use_large_pages='AUTO'<\/pre>\n
[oracle@ dbs]$ sqlplus \/ as sysdba\r\n\r\n startup nomount\r\nORACLE instance started.\r\n\r\nTotal System Global Area 1258290744 bytes\r\nFixed Size 8896056 bytes\r\nVariable Size 436207616 bytes\r\nDatabase Buffers 805306368 bytes\r\nRedo Buffers 7880704 bytes<\/pre>\n
\r\n****************************************************\r\nSys-V shared memory will be used for creating SGA\r\n****************************************************\r\n2022-07-27T15:01:09.749738+00:00\r\nDISM started, OS id=1692\r\n2022-07-27T15:01:09.784169+00:00\r\n**********************************************************************\r\n2022-07-27T15:01:09.784260+00:00\r\nDump of system resources acquired for SHARED GLOBAL AREA (SGA)\r\n\r\n2022-07-27T15:01:09.784382+00:00\r\nPer process system memlock (soft) limit = 1500M\r\n2022-07-27T15:01:09.784459+00:00\r\nExpected per process system memlock (soft) limit to lock\r\ninstance MAX SHARED GLOBAL AREA (SGA) into memory: 1202M\r\n2022-07-27T15:01:09.784626+00:00\r\nAvailable system pagesizes:\r\n4K, 2048K\r\n2022-07-27T15:01:09.784807+00:00\r\nSupported system pagesize(s):\r\n2022-07-27T15:01:09.784893+00:00\r\nPAGESIZE AVAILABLE_PAGES EXPECTED_PAGES ALLOCATED_PAGES ERROR(s)\r\n2022-07-27T15:01:09.785003+00:00\r\n4K Configured 4 4 NONE\r\n2022-07-27T15:01:09.785147+00:00\r\n2048K 601 601 601 NONE\r\n2022-07-27T15:01:09.785230+00:00\r\n**********************************************************************\r\n<\/pre>\n
$ cat \/proc\/meminfo | grep -i Huge\r\nAnonHugePages: 0 kB\r\nShmemHugePages: 0 kB\r\nHugePages_Total: 601\r\nHugePages_Free: 11\r\nHugePages_Rsvd: 11\r\nHugePages_Surp: 0\r\nHugepagesize: 2048 kB\r\nHugetlb: 1230848 kB<\/pre>\n
[root~]# sysctl -a | grep -i Hugepages\r\nvm.nr_hugepages = 601\r\nvm.nr_hugepages_mempolicy = 601\r\nvm.nr_overcommit_hugepages = 0<\/pre>\n
[oracle ~]$ $ORACLE_HOME\/bin\/sysresv\r\n\r\nIPC Resources for ORACLE_SID "CAPDATADB" :\r\nMaximum shared memory segment size (shmmax): 18446744073692774399 bytes\r\nTotal system shared memory (shmall): 18446744004990070784 bytes\r\nTotal system shared memory count (shmmni): 4096\r\n*********************** Dumping ipcs output ********************\r\n\r\n------ Message Queues --------\r\nkey msqid owner perms used-bytes messages\r\n\r\n------ Shared Memory Segments --------\r\nkey shmid owner perms bytes nattch status\r\n0x00000000 0 oracle 600 10485760 32\r\n0x00000000 1 oracle 600 1241513984 32\r\n0x00000000 2 oracle 600 8388608 32\r\n0x679d3c3c 3 oracle 600 16384 32\r\n\r\n------ Semaphore Arrays --------\r\nkey semid owner perms nsems\r\n0x3b5f1c70 3 oracle 600 154\r\n\r\n*********************** End of ipcs command dump **************\r\n\r\n\r\n***************** Dumping Resource Limits(s\/h) *****************\r\ncore file size UNLIMITED\/UNLIMITED\r\ndata seg size UNLIMITED\/UNLIMITED\r\nscheduling priority 0 KB\/0 KB\r\nfile size UNLIMITED\/UNLIMITED\r\npending signals 14 KB\/14 KB\r\nmax locked memory 1500 MB\/1500 MB\r\nmax memory size UNLIMITED\/UNLIMITED\r\nopen files 256 KB\/256 KB\r\nPOSIX message queues 800 KB\/800 KB\r\nreal-time priority 0 KB\/0 KB\r\nstack size 32 MB\/UNLIMITED\r\ncpu time UNLIMITED\/UNLIMITED\r\nmax user processes 14 KB\/14 KB\r\nvirtual memory UNLIMITED\/UNLIMITED\r\nfile locks UNLIMITED\/UNLIMITED\r\n\r\n***************** End of Resource Limits Dump ******************\r\n<\/pre>\n
\nAttention donc si vous avez plusieurs instances sur votre serveur et avec un mode AUTO sur chacune d’elle. La premi\u00e8re instance qui d\u00e9marre prend l’espace n\u00e9cessaire dans les HugesPages, les suivantes utiliseront ce qu’il reste jusqu’aux limites d\u00e9finies dans “ulimit -l”. Il se peut donc que la(les) derni\u00e8re(s) instance(s) d\u00e9marre(nt) avec des pages de 4Ko potentiellement.<\/p>\n[oracle~]$ sqlplus \/ as sysdba\r\n shutdown immediate\r\nORA-01507: database not mounted\r\n\r\nORACLE instance shut down.<\/pre>\n
[root@ ~]# cat \/proc\/meminfo | grep -i Huge\r\nAnonHugePages: 0 kB\r\nShmemHugePages: 0 kB\r\nHugePages_Total: 601\r\nHugePages_Free: 601\r\nHugePages_Rsvd: 0\r\nHugePages_Surp: 0\r\nHugepagesize: 2048 kB\r\nHugetlb: 1230848 kB<\/pre>\n
<\/h3>\n
Cas du mode AUTO_ONLY<\/h3>\n
[oracle@ dbs]$ cat initCAPDATADB.ora \r\n... \r\n*.sga_target=1200M \r\n*.use_large_pages='AUTO_ONLY'<\/pre>\n
\r\nstartup nomount\r\nORACLE instance started.\r\n\r\nTotal System Global Area 1258290744 bytes\r\nFixed Size 8896056 bytes\r\nVariable Size 436207616 bytes\r\nDatabase Buffers 805306368 bytes\r\nRedo Buffers 7880704 bytes<\/pre>\n
2022-07-27T15:28:14.054639+00:00\r\nAvailable system pagesizes:\r\n4K, 2048K\r\n2022-07-27T15:28:14.054776+00:00\r\nSupported system pagesize(s):\r\n2022-07-27T15:28:14.054841+00:00\r\nPAGESIZE AVAILABLE_PAGES EXPECTED_PAGES ALLOCATED_PAGES ERROR(s)\r\n2022-07-27T15:28:14.054970+00:00\r\n2048K 602 602 602 NONE\r\n2022-07-27T15:28:14.055045+00:00\r\nReason for not supporting certain system pagesizes:\r\n2022-07-27T15:28:14.055111+00:00\r\n4K - Large pagesizes only<\/pre>\n
[oracle@ dbs]$ cat \/proc\/meminfo | grep -i Huge\r\nAnonHugePages: 0 kB\r\nShmemHugePages: 0 kB\r\nHugePages_Total: 602\r\nHugePages_Free: 11\r\nHugePages_Rsvd: 11\r\nHugePages_Surp: 0\r\nHugepagesize: 2048 kB\r\nHugetlb: 1232896 kB<\/pre>\n
[oracle@ dbs]$ ipcs -m\r\n\r\n------ Shared Memory Segments --------\r\nkey shmid owner perms bytes nattch status\r\n0x00000000 4 oracle 600 10485760 32\r\n0x00000000 5 oracle 600 1241513984 32\r\n0x00000000 6 oracle 600 8388608 32\r\n0x679d3c3c 7 oracle 600 2097152 32<\/pre>\n
Au dela des limites !<\/h2>\n
Cas du mode AUTO<\/h3>\n
[oracle@ dbs]$ cat initCAPDATADB.ora\r\n...\r\n*.sga_target=1800M\r\n*.use_large_pages='AUTO'<\/pre>\n
\r\nstartup nomount\r\nORACLE instance started.\r\n\r\nTotal System Global Area 1895822680 bytes\r\nFixed Size 8897880 bytes\r\nVariable Size 436207616 bytes\r\nDatabase Buffers 1442840576 bytes\r\nRedo Buffers 7876608 bytes<\/pre>\n
2022-07-27T15:38:35.723099+00:00\r\nAvailable system pagesizes:\r\n4K, 2048K\r\n2022-07-27T15:38:35.723243+00:00\r\nSupported system pagesize(s):\r\n2022-07-27T15:38:35.723318+00:00\r\nPAGESIZE AVAILABLE_PAGES EXPECTED_PAGES ALLOCATED_PAGES ERROR(s)\r\n2022-07-27T15:38:35.723395+00:00\r\n4K Configured 5 79752 NONE\r\n2022-07-27T15:38:35.723516+00:00\r\n2048K 901 905 749 NONE\r\n2022-07-27T15:38:35.723594+00:00\r\nRECOMMENDATION:\r\n2022-07-27T15:38:35.723676+00:00\r\n1. For optimal performance, configure system with expected number\r\nof pages for every supported system pagesize prior to the next\r\ninstance restart operation.\r\n2022-07-27T15:38:35.727289+00:00\r\n2. Increase per process memlock (soft) limit to at least 1810MB\r\nto lock 100% of SHARED GLOBAL AREA (SGA) pages into physical memory\r\n2022-07-27T15:38:35.727468+00:00\r\n**********************************************************************\r\n<\/pre>\n
[oracle@ dbs]$ ipcs -m\r\n\r\n------ Shared Memory Segments --------\r\nkey shmid owner perms bytes nattch status\r\n0x00000000 8 oracle 600 10485760 31\r\n0x00000000 9 oracle 600 939524096 31\r\n0x00000000 10 oracle 600 469762048 31\r\n0x00000000 11 oracle 600 117440512 31\r\n0x00000000 12 oracle 600 16777216 31\r\n0x00000000 13 oracle 600 16777216 31\r\n0x00000000 14 oracle 600 318767104 31\r\n0x00000000 15 oracle 600 7876608 31\r\n0x679d3c3c 16 oracle 600 20480 31<\/pre>\n
Cas du mode AUTO_ONLY<\/h3>\n
[oracle@ dbs]$ ipcs -m -u\r\n\r\n------ Shared Memory Status --------\r\nsegments allocated 0\r\npages allocated 0\r\npages resident 0\r\npages swapped 0\r\nSwap performance: 0 attempts 0 successes<\/pre>\n
[oracle@ dbs]$ cat \/proc\/meminfo | grep -i Huge\r\nAnonHugePages: 0 kB\r\nShmemHugePages: 0 kB\r\nHugePages_Total: 901\r\nHugePages_Free: 901\r\nHugePages_Rsvd: 0\r\nHugePages_Surp: 0\r\nHugepagesize: 2048 kB\r\nHugetlb: 1845248 kB<\/pre>\n
[oracle@ dbs]$ cat initCAPDATADB.ora\r\n...\r\n*.sga_target=1800M\r\n*.use_large_pages='AUTO_ONLY'<\/pre>\n
startup nomount\r\nORA-27125: unable to create shared memory segment\r\nLinux-x86_64 Error: 1: Operation not permitted\r\nAdditional information: 4641\r\nAdditional information: 16777216<\/pre>\n
2022-07-27T15:54:04.922034+00:00\r\nPAGESIZE AVAILABLE_PAGES EXPECTED_PAGES ALLOCATED_PAGES ERROR(s)\r\n2022-07-27T15:54:04.922154+00:00\r\n2048K 901 906 749 ORA-27125\r\n2022-07-27T15:54:04.922230+00:00\r\nReason for not supporting certain system pagesizes:\r\n2022-07-27T15:54:04.922305+00:00\r\n4K - Large pagesizes only\r\n2022-07-27T15:54:04.922378+00:00\r\nRECOMMENDATION:\r\n2022-07-27T15:54:04.922448+00:00\r\n1. Configure system with expected number of pages for every\r\nsupported system pagesize prior to the next instance restart operation.\r\n2022-07-27T15:54:04.925893+00:00\r\n2. Increase per process memlock (soft) limit to at least 1812MB\r\nto lock 100% of SHARED GLOBAL AREA (SGA) pages into physical memory\r\n2022-07-27T15:54:04.926083+00:00\r\n**********************************************************************\r\n<\/pre>\n
\nOracle nous conseille d’augmenter le “soft limit” afin de faire tenir les 1,8Go de SGA dans des “HugePages” de 2Mo.<\/p>\nConclusion<\/h2>\n
Optimisations de configuration<\/h3>\n
Cas d’un serveur d\u00e9di\u00e9 SGBDR avec 1 instance Oracle :<\/span><\/h4>\n
\n
Cas d’un serveur SGBDR avec plusieurs instances Oracle.<\/span><\/h4>\n
\n
\n
\n
echo never | tee \/sys\/kernel\/mm\/transparent_hugepage\/enabled<\/pre>\n<\/li>\n
<\/a><\/a><\/a>","protected":false},"excerpt":{"rendered":"