Oracle 12c Database swapping after set up huge pages
I need to setup a Oracle Database 12c with 64GB RAM on Linux RedHet. I decided to use huge pages. Something must have went wrong. Altertlog:
WARNING: Heavy swapping observed on system in last 5 mins. pct of
memory swapped in [0.42%] pct of memory swapped out [1.82%]. Please
make sure there is no memory pressure and the SGA and PGA are
configured correctly. Look at DBRM trace file for more details.
Supported system pagesize(s): PAGESIZE AVAILABLE_PAGES EXPECTED_PAGES ALLOCATED_PAGES ERROR(s)
4K Configured 10 8192010 NONE
2048K 15946 16001 0 NONE
Seems like the Database is not using the huge pages? What could be the issue?
Update:
grep Huge /proc/meminfo
AnonHugePages: 40960 kB
HugePages_Total: 16001
HugePages_Free: 16001
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
oracle memory
bumped to the homepage by Community♦ 8 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
|
show 1 more comment
I need to setup a Oracle Database 12c with 64GB RAM on Linux RedHet. I decided to use huge pages. Something must have went wrong. Altertlog:
WARNING: Heavy swapping observed on system in last 5 mins. pct of
memory swapped in [0.42%] pct of memory swapped out [1.82%]. Please
make sure there is no memory pressure and the SGA and PGA are
configured correctly. Look at DBRM trace file for more details.
Supported system pagesize(s): PAGESIZE AVAILABLE_PAGES EXPECTED_PAGES ALLOCATED_PAGES ERROR(s)
4K Configured 10 8192010 NONE
2048K 15946 16001 0 NONE
Seems like the Database is not using the huge pages? What could be the issue?
Update:
grep Huge /proc/meminfo
AnonHugePages: 40960 kB
HugePages_Total: 16001
HugePages_Free: 16001
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
oracle memory
bumped to the homepage by Community♦ 8 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
Would you care to add the output of a "vmstat 5 5" to your question? Just to see if your system is really "swapping". You've assigne 32Gb to hugepages, so there should be plenty of room for normal activity. Also, "grep Huge /proc/meminfo" would show if you're using it or not.
– Gerard H. Pille
Aug 29 '18 at 7:27
Unfortunately I cannot provide the vmstat because I restarted the System with new settings. I found that limits in the grep oracle /etc/security/limits.conf were set wrong: #oracle soft memlock 19857408 #oracle hard memlock 19857408. The limits should be set to something like 90% of the total RAM.
– r0tt
Aug 29 '18 at 8:05
Good for you! I was going to point you to oracle-base.com/articles/linux/…
– Gerard H. Pille
Aug 29 '18 at 8:42
They use the Formular HugePages * Hugepagesize.
– r0tt
Aug 29 '18 at 8:44
The issue here was that the Oracle Database wanted to use more RAM than the limit allowed.
– r0tt
Aug 29 '18 at 8:49
|
show 1 more comment
I need to setup a Oracle Database 12c with 64GB RAM on Linux RedHet. I decided to use huge pages. Something must have went wrong. Altertlog:
WARNING: Heavy swapping observed on system in last 5 mins. pct of
memory swapped in [0.42%] pct of memory swapped out [1.82%]. Please
make sure there is no memory pressure and the SGA and PGA are
configured correctly. Look at DBRM trace file for more details.
Supported system pagesize(s): PAGESIZE AVAILABLE_PAGES EXPECTED_PAGES ALLOCATED_PAGES ERROR(s)
4K Configured 10 8192010 NONE
2048K 15946 16001 0 NONE
Seems like the Database is not using the huge pages? What could be the issue?
Update:
grep Huge /proc/meminfo
AnonHugePages: 40960 kB
HugePages_Total: 16001
HugePages_Free: 16001
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
oracle memory
I need to setup a Oracle Database 12c with 64GB RAM on Linux RedHet. I decided to use huge pages. Something must have went wrong. Altertlog:
WARNING: Heavy swapping observed on system in last 5 mins. pct of
memory swapped in [0.42%] pct of memory swapped out [1.82%]. Please
make sure there is no memory pressure and the SGA and PGA are
configured correctly. Look at DBRM trace file for more details.
Supported system pagesize(s): PAGESIZE AVAILABLE_PAGES EXPECTED_PAGES ALLOCATED_PAGES ERROR(s)
4K Configured 10 8192010 NONE
2048K 15946 16001 0 NONE
Seems like the Database is not using the huge pages? What could be the issue?
Update:
grep Huge /proc/meminfo
AnonHugePages: 40960 kB
HugePages_Total: 16001
HugePages_Free: 16001
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
oracle memory
oracle memory
edited Aug 29 '18 at 7:35
r0tt
asked Aug 29 '18 at 7:06
r0ttr0tt
39031022
39031022
bumped to the homepage by Community♦ 8 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 8 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
Would you care to add the output of a "vmstat 5 5" to your question? Just to see if your system is really "swapping". You've assigne 32Gb to hugepages, so there should be plenty of room for normal activity. Also, "grep Huge /proc/meminfo" would show if you're using it or not.
– Gerard H. Pille
Aug 29 '18 at 7:27
Unfortunately I cannot provide the vmstat because I restarted the System with new settings. I found that limits in the grep oracle /etc/security/limits.conf were set wrong: #oracle soft memlock 19857408 #oracle hard memlock 19857408. The limits should be set to something like 90% of the total RAM.
– r0tt
Aug 29 '18 at 8:05
Good for you! I was going to point you to oracle-base.com/articles/linux/…
– Gerard H. Pille
Aug 29 '18 at 8:42
They use the Formular HugePages * Hugepagesize.
– r0tt
Aug 29 '18 at 8:44
The issue here was that the Oracle Database wanted to use more RAM than the limit allowed.
– r0tt
Aug 29 '18 at 8:49
|
show 1 more comment
Would you care to add the output of a "vmstat 5 5" to your question? Just to see if your system is really "swapping". You've assigne 32Gb to hugepages, so there should be plenty of room for normal activity. Also, "grep Huge /proc/meminfo" would show if you're using it or not.
– Gerard H. Pille
Aug 29 '18 at 7:27
Unfortunately I cannot provide the vmstat because I restarted the System with new settings. I found that limits in the grep oracle /etc/security/limits.conf were set wrong: #oracle soft memlock 19857408 #oracle hard memlock 19857408. The limits should be set to something like 90% of the total RAM.
– r0tt
Aug 29 '18 at 8:05
Good for you! I was going to point you to oracle-base.com/articles/linux/…
– Gerard H. Pille
Aug 29 '18 at 8:42
They use the Formular HugePages * Hugepagesize.
– r0tt
Aug 29 '18 at 8:44
The issue here was that the Oracle Database wanted to use more RAM than the limit allowed.
– r0tt
Aug 29 '18 at 8:49
Would you care to add the output of a "vmstat 5 5" to your question? Just to see if your system is really "swapping". You've assigne 32Gb to hugepages, so there should be plenty of room for normal activity. Also, "grep Huge /proc/meminfo" would show if you're using it or not.
– Gerard H. Pille
Aug 29 '18 at 7:27
Would you care to add the output of a "vmstat 5 5" to your question? Just to see if your system is really "swapping". You've assigne 32Gb to hugepages, so there should be plenty of room for normal activity. Also, "grep Huge /proc/meminfo" would show if you're using it or not.
– Gerard H. Pille
Aug 29 '18 at 7:27
Unfortunately I cannot provide the vmstat because I restarted the System with new settings. I found that limits in the grep oracle /etc/security/limits.conf were set wrong: #oracle soft memlock 19857408 #oracle hard memlock 19857408. The limits should be set to something like 90% of the total RAM.
– r0tt
Aug 29 '18 at 8:05
Unfortunately I cannot provide the vmstat because I restarted the System with new settings. I found that limits in the grep oracle /etc/security/limits.conf were set wrong: #oracle soft memlock 19857408 #oracle hard memlock 19857408. The limits should be set to something like 90% of the total RAM.
– r0tt
Aug 29 '18 at 8:05
Good for you! I was going to point you to oracle-base.com/articles/linux/…
– Gerard H. Pille
Aug 29 '18 at 8:42
Good for you! I was going to point you to oracle-base.com/articles/linux/…
– Gerard H. Pille
Aug 29 '18 at 8:42
They use the Formular HugePages * Hugepagesize.
– r0tt
Aug 29 '18 at 8:44
They use the Formular HugePages * Hugepagesize.
– r0tt
Aug 29 '18 at 8:44
The issue here was that the Oracle Database wanted to use more RAM than the limit allowed.
– r0tt
Aug 29 '18 at 8:49
The issue here was that the Oracle Database wanted to use more RAM than the limit allowed.
– r0tt
Aug 29 '18 at 8:49
|
show 1 more comment
1 Answer
1
active
oldest
votes
The steps I did to setup this hugepage configuration on ReDHat 7.3 64GBRAM and the mistake. (Link from oracle base posted above provides a better Manual for reuse)
Check total RAM of OS:
grep MemTotal /proc/meminfo
MemTotal: 65809456 kB
Check Oracle Database – AMM needs to be off:
MEMORY_TARGET und MEMORY_MAX_TARGETneed to be set to zero.
SQL> select value from v$parameter where name = 'memory_target';
VALUE
---------------------------
0
Calculate SGA size, for example 32GB:
select value/1024 from v$parameter where name = 'sga_target';
VALUE/1024
----------
32768000
Calculate Huge Pages,
for a x86_64 Red Hat Enterprise Linux Server we can use a default 2MB hugepagesize:
SGA / Hugepagesize=Hugepage +1
32768000/2048=16001
This need to be set in /etc/sysctl.conf as root:
vm.nr_hugepages =16001
Also we need to set the /etc/security/limits.conf. This value hard and soft memlock should be greater than the the SGA and smaller than the total RAM.
Hugepages * Hugepagesize = minimum Memlock or something like 90% of total RAM.
Setting memlock to a lower value then SGA leads to unpredictable behavior of the Oracle Database. As commented above Oracle Database will allocate memory without using the huge pages. In my case this leaded to fatal errors when using impdp. Datapump did not provide errors which made sense.
grep oracle /etc/security/limits.conf
oracle soft nproc 2047
oracle hard nproc 16384
oracle soft nofile 1024
oracle hard nofile 65536
oracle soft stack 10240
#oracle soft memlock 19857408
#oracle hard memlock 19857408
oracle soft memlock 57671680
oracle hard memlock 57671680
For RedHat we also need to turn off Transparent Hugepages
cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
[always] madvise never
echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag
cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
always madvise [never]
Reboot System and start Oracle Database check:
grep Huge /proc/meminfo
AnonHugePages: 40960 kB
HugePages_Total: 16001
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "182"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f216161%2foracle-12c-database-swapping-after-set-up-huge-pages%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The steps I did to setup this hugepage configuration on ReDHat 7.3 64GBRAM and the mistake. (Link from oracle base posted above provides a better Manual for reuse)
Check total RAM of OS:
grep MemTotal /proc/meminfo
MemTotal: 65809456 kB
Check Oracle Database – AMM needs to be off:
MEMORY_TARGET und MEMORY_MAX_TARGETneed to be set to zero.
SQL> select value from v$parameter where name = 'memory_target';
VALUE
---------------------------
0
Calculate SGA size, for example 32GB:
select value/1024 from v$parameter where name = 'sga_target';
VALUE/1024
----------
32768000
Calculate Huge Pages,
for a x86_64 Red Hat Enterprise Linux Server we can use a default 2MB hugepagesize:
SGA / Hugepagesize=Hugepage +1
32768000/2048=16001
This need to be set in /etc/sysctl.conf as root:
vm.nr_hugepages =16001
Also we need to set the /etc/security/limits.conf. This value hard and soft memlock should be greater than the the SGA and smaller than the total RAM.
Hugepages * Hugepagesize = minimum Memlock or something like 90% of total RAM.
Setting memlock to a lower value then SGA leads to unpredictable behavior of the Oracle Database. As commented above Oracle Database will allocate memory without using the huge pages. In my case this leaded to fatal errors when using impdp. Datapump did not provide errors which made sense.
grep oracle /etc/security/limits.conf
oracle soft nproc 2047
oracle hard nproc 16384
oracle soft nofile 1024
oracle hard nofile 65536
oracle soft stack 10240
#oracle soft memlock 19857408
#oracle hard memlock 19857408
oracle soft memlock 57671680
oracle hard memlock 57671680
For RedHat we also need to turn off Transparent Hugepages
cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
[always] madvise never
echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag
cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
always madvise [never]
Reboot System and start Oracle Database check:
grep Huge /proc/meminfo
AnonHugePages: 40960 kB
HugePages_Total: 16001
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
add a comment |
The steps I did to setup this hugepage configuration on ReDHat 7.3 64GBRAM and the mistake. (Link from oracle base posted above provides a better Manual for reuse)
Check total RAM of OS:
grep MemTotal /proc/meminfo
MemTotal: 65809456 kB
Check Oracle Database – AMM needs to be off:
MEMORY_TARGET und MEMORY_MAX_TARGETneed to be set to zero.
SQL> select value from v$parameter where name = 'memory_target';
VALUE
---------------------------
0
Calculate SGA size, for example 32GB:
select value/1024 from v$parameter where name = 'sga_target';
VALUE/1024
----------
32768000
Calculate Huge Pages,
for a x86_64 Red Hat Enterprise Linux Server we can use a default 2MB hugepagesize:
SGA / Hugepagesize=Hugepage +1
32768000/2048=16001
This need to be set in /etc/sysctl.conf as root:
vm.nr_hugepages =16001
Also we need to set the /etc/security/limits.conf. This value hard and soft memlock should be greater than the the SGA and smaller than the total RAM.
Hugepages * Hugepagesize = minimum Memlock or something like 90% of total RAM.
Setting memlock to a lower value then SGA leads to unpredictable behavior of the Oracle Database. As commented above Oracle Database will allocate memory without using the huge pages. In my case this leaded to fatal errors when using impdp. Datapump did not provide errors which made sense.
grep oracle /etc/security/limits.conf
oracle soft nproc 2047
oracle hard nproc 16384
oracle soft nofile 1024
oracle hard nofile 65536
oracle soft stack 10240
#oracle soft memlock 19857408
#oracle hard memlock 19857408
oracle soft memlock 57671680
oracle hard memlock 57671680
For RedHat we also need to turn off Transparent Hugepages
cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
[always] madvise never
echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag
cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
always madvise [never]
Reboot System and start Oracle Database check:
grep Huge /proc/meminfo
AnonHugePages: 40960 kB
HugePages_Total: 16001
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
add a comment |
The steps I did to setup this hugepage configuration on ReDHat 7.3 64GBRAM and the mistake. (Link from oracle base posted above provides a better Manual for reuse)
Check total RAM of OS:
grep MemTotal /proc/meminfo
MemTotal: 65809456 kB
Check Oracle Database – AMM needs to be off:
MEMORY_TARGET und MEMORY_MAX_TARGETneed to be set to zero.
SQL> select value from v$parameter where name = 'memory_target';
VALUE
---------------------------
0
Calculate SGA size, for example 32GB:
select value/1024 from v$parameter where name = 'sga_target';
VALUE/1024
----------
32768000
Calculate Huge Pages,
for a x86_64 Red Hat Enterprise Linux Server we can use a default 2MB hugepagesize:
SGA / Hugepagesize=Hugepage +1
32768000/2048=16001
This need to be set in /etc/sysctl.conf as root:
vm.nr_hugepages =16001
Also we need to set the /etc/security/limits.conf. This value hard and soft memlock should be greater than the the SGA and smaller than the total RAM.
Hugepages * Hugepagesize = minimum Memlock or something like 90% of total RAM.
Setting memlock to a lower value then SGA leads to unpredictable behavior of the Oracle Database. As commented above Oracle Database will allocate memory without using the huge pages. In my case this leaded to fatal errors when using impdp. Datapump did not provide errors which made sense.
grep oracle /etc/security/limits.conf
oracle soft nproc 2047
oracle hard nproc 16384
oracle soft nofile 1024
oracle hard nofile 65536
oracle soft stack 10240
#oracle soft memlock 19857408
#oracle hard memlock 19857408
oracle soft memlock 57671680
oracle hard memlock 57671680
For RedHat we also need to turn off Transparent Hugepages
cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
[always] madvise never
echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag
cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
always madvise [never]
Reboot System and start Oracle Database check:
grep Huge /proc/meminfo
AnonHugePages: 40960 kB
HugePages_Total: 16001
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
The steps I did to setup this hugepage configuration on ReDHat 7.3 64GBRAM and the mistake. (Link from oracle base posted above provides a better Manual for reuse)
Check total RAM of OS:
grep MemTotal /proc/meminfo
MemTotal: 65809456 kB
Check Oracle Database – AMM needs to be off:
MEMORY_TARGET und MEMORY_MAX_TARGETneed to be set to zero.
SQL> select value from v$parameter where name = 'memory_target';
VALUE
---------------------------
0
Calculate SGA size, for example 32GB:
select value/1024 from v$parameter where name = 'sga_target';
VALUE/1024
----------
32768000
Calculate Huge Pages,
for a x86_64 Red Hat Enterprise Linux Server we can use a default 2MB hugepagesize:
SGA / Hugepagesize=Hugepage +1
32768000/2048=16001
This need to be set in /etc/sysctl.conf as root:
vm.nr_hugepages =16001
Also we need to set the /etc/security/limits.conf. This value hard and soft memlock should be greater than the the SGA and smaller than the total RAM.
Hugepages * Hugepagesize = minimum Memlock or something like 90% of total RAM.
Setting memlock to a lower value then SGA leads to unpredictable behavior of the Oracle Database. As commented above Oracle Database will allocate memory without using the huge pages. In my case this leaded to fatal errors when using impdp. Datapump did not provide errors which made sense.
grep oracle /etc/security/limits.conf
oracle soft nproc 2047
oracle hard nproc 16384
oracle soft nofile 1024
oracle hard nofile 65536
oracle soft stack 10240
#oracle soft memlock 19857408
#oracle hard memlock 19857408
oracle soft memlock 57671680
oracle hard memlock 57671680
For RedHat we also need to turn off Transparent Hugepages
cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
[always] madvise never
echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag
cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
always madvise [never]
Reboot System and start Oracle Database check:
grep Huge /proc/meminfo
AnonHugePages: 40960 kB
HugePages_Total: 16001
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
answered Aug 29 '18 at 9:38
r0ttr0tt
39031022
39031022
add a comment |
add a comment |
Thanks for contributing an answer to Database Administrators Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f216161%2foracle-12c-database-swapping-after-set-up-huge-pages%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Would you care to add the output of a "vmstat 5 5" to your question? Just to see if your system is really "swapping". You've assigne 32Gb to hugepages, so there should be plenty of room for normal activity. Also, "grep Huge /proc/meminfo" would show if you're using it or not.
– Gerard H. Pille
Aug 29 '18 at 7:27
Unfortunately I cannot provide the vmstat because I restarted the System with new settings. I found that limits in the grep oracle /etc/security/limits.conf were set wrong: #oracle soft memlock 19857408 #oracle hard memlock 19857408. The limits should be set to something like 90% of the total RAM.
– r0tt
Aug 29 '18 at 8:05
Good for you! I was going to point you to oracle-base.com/articles/linux/…
– Gerard H. Pille
Aug 29 '18 at 8:42
They use the Formular HugePages * Hugepagesize.
– r0tt
Aug 29 '18 at 8:44
The issue here was that the Oracle Database wanted to use more RAM than the limit allowed.
– r0tt
Aug 29 '18 at 8:49