Tuning Red Hat Enterprise Linux For Oracle and Oracle RAC Performance

8/9/2017 Tuning Red Hat Enterprise Linux for Oracle and Oracle RAC performance - Red Hat Customer
mance - Red Hat Customer Portal
Tuning Red Hat Enterprise Linux for Oracle and Oracle RAC performance
$ SOLUTION VERIFIED - Updated July 20 2017 at 9:55 PM - English ()
Environment
Red Hat Enterprise Linux 7
Oracle 9g
Oracle 10g
Oracle 11g
Oracle 12c
Issue
How can I tune my Red Hat Enterprise Linux system for Oracle 10g/11g?
High memory consumption on Oracle database system
High CPU consumption on Oracle hosts
How should I congure swap memory for an Oracle database?
Slower than expected IO performance running Oracle on RHEL
What is the maximum number of huge pages I should be using per system?
Resolution
IMPORTANT: This article is not an authoritative source of information on how to congure Red Hat Enterprise Linux for use with Oracle products, as
these products are not shipped by Red Hat. This is just an example of how the conguration may look like and is provided just for the convenience
only. The authoritative source of such information is the Oracle Installation Guide or Oracle OS Tuning Guide for your version of Oracle product,
such a documentation could be found on Oracle Metalink site, namely:
RHEL4 32 bit (x86):
Note 303859.1 - Requirements for Installing Oracle 9iR2 on RHEL 4
Note 392940.1 - Requirements for Installing Oracle 10.1.0.x RDBMS on RHEL 4 x86 platform
Note 343431.1 - Requirements for Installing Oracle 10gR2 RDBMS on RHEL 4 x86 platform
Note 430653.1 - Requirements for Installing Oracle 11gR1 32-bit on RHEL 4
Note 880211.1 - Requirements for Installing Oracle 11gR2 RDBMS on RHEL (and OEL) 4 x86
RHEL4 64 bit (x86-64):
Note 353529.1 - Requirements for Installing Oracle 9iR2 64-bit on RHEL 4 x86-64 (AMD64/EM64T)
Note 390900.1 - Requirements for Installing Oracle 10g (10.1.0.x) RDBMS on RHEL 4 on AMD64/EM64T (Linux x86-64)
Note 339510.1 - Requirements for Installing Oracle 10gR2 RDBMS on RHEL 4 on AMD64/EM64T
Note 880942.1 - Requirements for Installing Oracle 11gR2 RDBMS on RHEL (and OEL) 4 on AMD64/EM64T
RHEL5 32 bit (x86):
Note 419646.1 - Requirements For Installing Oracle 10gR2 On RHEL 5 (x86)
Note 438765.1 - Requirements for Installing Oracle 11gR1 32bit RDBMS on RHEL 5
Note 880936.1 - Requirements for Installing Oracle 11gR2 RDBMS on RHEL (and OEL) 5 on 32-bit x86
RHEL5 64 bit (x86-64):
Note 421308.1 - Requirements For Installing Oracle10gR2 On RHEL 5 (x86_64)
Note 880989.1 - Requirements for Installing Oracle 11gR2 RDBMS on RHEL (and OEL) 5 on AMD64/EM64T
Note 1529433.1 - Requirements for Installing Oracle Database 12.1 on RHEL5 or OL5 64-bit (x86-64)
RHEL6 64 bit (x86-64):
Note 1441282.1 - Requirements for Installing Oracle 11gR2 RDBMS on RHEL6 or OL6 64-bit (x86-64)
Note 1529864.1 - Requirements for Installing Oracle Database 12.1 on RHEL6 or OL6 64-bit (x86-64)
https://access.redhat.com/solutions/39188 1/12
8/9/2017 Tuning Red Hat Enterprise Linux for Oracle and Oracle RAC performance - Red Hat Customer Portal
Master Note of Linux OS Requirements for Database Server
(https://blogs.oracle.com/db/entry/master_note_of_linux_os_requirements_for_database_server)
Where can I nd an Oracle Tuning Guide for Red Hat Enterprise Linux? (https://access.redhat.com/solutions/26368)
Automatic conguration
Red Hat provides a RHEL Tuner for Oracle (https://access.redhat.com/labs/rheltfo/) tool to help tune your Red Hat Enterprise Linux for Oracle. The tool
incorporates the information included in this document but makes it easier to generate valid and support-recommended congurations. You can leave
feedback on the tool at RHEL Tuner for Oracle (https://access.redhat.com/labsinfo/rheltfo).
Manual conguration
Note: All the numbers mentioned in this article are not generic and have been shown to have a positive effect on database workloads resident on
Red Hat Enterprise Linux. That being said, the specic values depend on user environments and may require further adjustment.
Memory settings in /etc/sysctl.conf:
Swapping for Oracle is not ideal and should be avoided as much as possible. The following tunable will tune the kernel to swap less aggressively.
vm.swappiness=10
Maximum percentage of active memory that can have dirty pages:
For example if a system has 1000 pages of memory and dirty_background_ratio is set to 3% , writeback will begin when 30 pages have been dirtied.
vm.dirty_background_ratio=3
Maximum percentage of total memory that can have dirty pages:
If it is set to 40% on a 1000 page system, a process dirtying pages will be made to wait once the 400th page is dirtied.This mechanism will, thus, slow the
dirtying of pages while the system catches up.
vm.dirty_ratio=40
How long data can be in page cache before being expired:
vm.dirty_expire_centisecs=500
How often pdush is activated to clean dirty pages (in hundreds of a second):
vm.dirty_writeback_centisecs=100
HugePages
1. Obtain the Hugepagesize from /proc/meminfo
$ grep Huge /proc/meminfo

HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
Hugepagesize: 2048 kB
2. Calculate the recommended number of HugePages using the formula below, using Hugepagesize and the System Global Area (SGA) values from
Oracle. See Oracle documentation for more about SGA and where to nd those values. Note that the Program Global Area (PGA) does not use huge
pages.
SGA / huge page size
The following is an example. Values were are all converted to kilobytes for calculation:
Hugepagesize = 2048 KB

20 GB SGA = 20971520 KB
(20971520 / 2048) = 10240
So, 10240 is amount of huge pages required to t the 20GB SGA.
3. Add that number to the /etc/sysctl.conf setting:
vm.nr_hugepages=10240
vm.hugetlb_shm_group=<insert oracle group ID here>
4. Once the above setting has been tested and shown to provide the performance required, it is recommended to move HugePage allocation to the kernel
line in /boot/grub/grub.conf as a boot option. This allows for earlier and cleaner allocation of HugePages:
If Hugepages are not set in kernel, they are dynamically allocated by setting the value in nr_hugepages.
When the system is under memory pressure, the huge pages cannot be swapped.
kernel /vmlinuz-<kernel-version> ro root=/dev/vg01/lv01 hugepages=15369 <other boot options>
5. Change the Oracle database conguration to use the Huge Pages. Contact Oracle support if assistance is needed
Limits setting in /etc/security/limits.conf:
Note: In order for Oracle database to use Huge Pages in Red Hat Enterprise Linux 4, 5 or 6, you may also need to increase the ulimit parameter
"memlock" for the oracle user in /etc/security/limits.conf. The memlock setting is specied in KB and must match the memory size of the number of
Huge Pages that Oracle should be able to allocate. So, if the Oracle database should be able to use 512 Huge Pages, then memlock must be set to at
least (512 * Hugepagesize), which on a default system would be 1048576 KB (512*2048).
oracle soft memlock 1048576

oracle hard memlock 1048576
Shared Memory
According to the documentation (https://www.kernel.org/doc/Documentation/sysctl/kernel.txt):
SHMALL is the maximum total amount of shared memory pages that can be used system-wide. Hence, SHMALL should always be at least
ceil(SHMMAX/PAGE_SIZE) .
SHMMAX is the maximum size in bytes of a single shared memory segment that can be created.
Obtain the total memory in the system in bytes:
mem=$(free -b | awk '/Mem/ {print $2}')
Get page size in bytes:
page=$(getconf PAGE_SIZE)
Calculate 75% of the total memory in the system in pages for SHMALL :
all=$(expr $mem \* 75 / 100 / $page + 1)
Multiply the SHMALL value by the page size to get SHMMAX :
max=$(expr $all \* $page)
Set the SHMMAX and the SHMALL values in the /etc/sysctl.conf le:
echo "kernel.shmmax = $max" >> /etc/sysctl.conf

echo "kernel.shmall = $all" >> /etc/sysctl.conf
Set the maximum number of shared memory segments with SHMMNI in the /etc/sysctl.conf le:
echo "kernel.shmmni = 4096" >> /etc/sysctl.conf

Semaphores
Recommended minimums for semaphore operations:
kernel.sem="250 32000 100 128"
The rst value, SEMMSL, is the maximum number of semaphores per semaphore set
The second value, SEMMNS, denes the total number of semaphores for the system
The third value, SEMOPM, denes the maximum number of semaphore operations per semaphore call
The last value, SEMMNI, denes the number of entire semaphore sets for the system
# sysctl -w "kernel.sem = 250 32000 100 128"

# echo "kernel.sem = 250 32000 100 128" >> /etc/sysctl.conf
Open le descriptors for oracle user
#vi /etc/security/limits.conf
#<domain> <type> <item> <value>
oracle hard nofile 10000
Disabling transparent hugepages (THP) recommended just for Red Hat Enterprise Linux 6
Disable tuned and ktune services if you have it.

Eg:
# service tuned stop

# chkconfig tuned off
# service ktune stop
# chkconfig ktune off
OR
# tuned-adm off
Note: The tuned-adm command will revert all your settings to what they were before tuned started and disable the tuning services from running at boot.
As an alternative, a customized tuned prole can be created, taking over the old settings and only disabling THP. Refer to kbase Disabling transparent
hugepages (THP) on Red Hat Enterprise Linux 6 is not taking effect. (https://access.redhat.com/site/solutions/422283) for details.
Append "transparent_hugepage=never" to kernel command line in /boot/grub/grub.conf le.

Eg:
kernel /boot/vmlinuz-2.6.32-358.el6.x86_64 ro root=UUID=a216d1e5-884f-4e5c-859a-6e2e2530d486 rhgb quiet transparent_hugepage=never
Reboot the server for changes to take effect.

Eg:
# reboot
I/O scheduler
The default CFQ I/O scheduler is appropriate for most workloads, but does not offer optimal performance for database environments. Instead, one
of the following IO schedulers should be used:
The deadline scheduler is recommended for physical systems (https://access.redhat.com/solutions/54164)
The noop scheduler is recommended for virtual systems (https://access.redhat.com/solutions/5427)
Reference
* 2016 - Deploying Oracle RAC Database 12c on Red Hat Enterprise Linux 7 - Best Practices (https://access.redhat.com/articles/1357883)
* 2016 - Deploying Oracle Database 12c on Red Hat Enterprise Linux 7- Recommended Practices (https://access.redhat.com/articles/1282303)
* 2014 - Red Hat Enterprise Linux 7 - Using Tuned for Tuning an Oracle Workload (https://access.redhat.com/videos/898563)
* 2014 - Deploying Oracle Database 12c on Red Hat Enterprise Linux 6 (https://access.redhat.com/articles/725843)
* 2013 - Deploying Oracle RAC 11g R2 Database on Red Hat Enterprise Linux 6 - Best Practices (https://access.redhat.com/site/articles/479093)
* 2013 - Deploying Oracle Database 11g R2 on Red Hat Enterprise Linux 6 - Best Practices (https://access.redhat.com/articles/395013)
* 2008 - Deploying Oracle 10g RHEL 5 (https://access.redhat.com/site/articles/215753)
Product(s) Red Hat Enterprise Linux (/taxonomy/products/red-hat-enterprise-linux) Component kernel (/components/kernel)
Category Performance tune (/category/performance-tune)
Tags labs_rheltfo (/taxonomy/tags/labsrheltfo) oracle (/tags/oracle) performance (/tags/performance) performance_tuning (/tags/performancetuning) rhel_4 (/tags/rhel_4)
rhel_5 (/tags/rhel_5) rhel_6 (/tags/rhel_6) rhel_7 (/taxonomy/tags/rhel7)
This solution is part of Red Hats fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while
supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited
form.
33 Comments
17 October 2011 2:55 PM (https://access.redhat.com/solutions/39188#comment-334603)
Wilmer Jaramillo M. (/user/433253)

(/user/433253)
Next line is incomplete:
COMMUNITY
MEMBER
30 Points How often pdush is activated to clean dirty pages (hundreths of a.... vm.dirty_writeback_centisecs=100
Reply (/Ajax_comments/Reply/39188/334603)
18 October 2011 5:32 AM (https://access.redhat.com/solutions/39188#comment-334613)
David Powles (/user/8963) Administrator
(/user/8963)Thanks for the feedback! I've corrected the article.

RED HAT
25289 Reply (/Ajax_comments/Reply/39188/334613)

Points
23 January 2012 5:08 PM (https://access.redhat.com/solutions/39188#comment-337973)
Paul Qu (/user/1135473)
(/user/1135473)
If use Huge Page, no need for other vm.* parameters tuning as Huge Page memory does not swap.
NEWBIE
5 Points Reply (/Ajax_comments/Reply/39188/337973)
HP Linux Engineering team (/user/1185973)

(/user/1185973)
Oracle on MOS 811306.1 actually recommends setting swappiness to 100, what's the deal ?
COMMUNITY
MEMBER
33 Points
20 November 2012 12:45 AM (https://access.redhat.com/solutions/39188#comment-435993)
Sergey Guzenkov (/user/1786133)

(/user/1786133)
The article mentions /etc/syscong/sysctl.conf
GURU Is this a typo and /etc/sysctl.conf was meant? Or if it is a valid le, then can you please advise the difference with /etc/sysctl.conf
PRO

Points
Yogesh Babar (/user/10283)

Hello,
(/user/10283)
RED HAT Thanks for catching this, indeed it should be /etc/sysctl.conf. I have corrected the article.
PRO
729
Points
Sergey Guzenkov (/user/1786133)

(/user/1786133)
no worries. Thank you for quick response! and for the article
GURU
PRO Reply (/Ajax_comments/Reply/39188/436043)

2378
Points
16 July 2013 6:41 PM (https://access.redhat.com/solutions/39188#comment-499703)
Jesse Johnson (/user/3074453)

(/user/3074453)
.
RED HAT
COMMUNITY
MEMBER
57 Points
23 October 2013 3:32 AM (https://access.redhat.com/solutions/39188#comment-562073)
Ugo Bellavance (/user/76163)

(/user/76163)
I got a notication saying that this article changed... Is there a way to know what changed?
COMMUNITY
MEMBER
52 Points
Marc Milgram (/user/5073)

(/user/5073)Ugo,
RED HAT
EXPERT That is a great question. I don't know of any way that non-Red Hat associates can see what changed.
1003
Points I took a look at the changes. The only substantive changes were the recommendations relating to kernel.sem.
Anne Robbins (/user/5512813)

(/user/5512813)
Question about the huge pages value calculation: my understanding is that PGA does not use huge pages, so why is that included in the
NEWBIE calculation? Elsewhere, for instance on some Oracle sites, I've seen a hugepages_setting.sh script that does its calculations from ipcs.
10 Points
18 January 2014 4:13 AM (https://access.redhat.com/solutions/39188#comment-691593)
Roger Lopez (/user/4000813)

(/user/4000813)
Hi Anne,
RED HAT
ACTIVE You are right on the PGA does not use huge pages.The goal of setting up huge pages is to provide the correct number of pages to handle the
CONTRIBUTOR
running shared memory segments used by the SGA. An easy way to calculate the number of huge pages without using the
182 Points
hugepages_settings.sh script created by Oracle is to take the size of your SGA in kilobytes and divide that by the huge page size from the
OS. In RHEL, the page size is 2048 kb. So the calculation would be: SGA in kilobytes / 2048 (huge page size). Once you have this size, you
should add a few additional huge pages just to ensure all of the SGA can t in large pages. After you have set this piece up, you also need to
set the memlock parameter within your limits.d conf le located in /etc/security/limits.d/ directory). Setting memlock allows the oracle user
to lock a certain amount of memory from physical RAM that isn't swapped out. The value is expressed in kilobytes and is important from the
Oracle perspective because it provides the oracle user permission to use huge pages. So the next question might be how do I know if Oracle
is using the huge pages? Well you can check cat /proc/meminfo and look at the hugepages total and hugepages free and see how the value
goes down when you start your Oracle db instance. The other place to look is in the Oracle alert log. Within the alert log search for the word
'Large' and you should see something like:
************************ Large Pages Information *******************

Thu Jan 16 16:55:07 2014
Per process system memlock (soft) limit = UNLIMITED
Thu Jan 16 16:55:07 2014
Total System Global Area in large pages = 19 GB (100%)

Thu Jan 16 16:55:07 2014
Large pages used by this instance: 9665 (19 GB)

Thu Jan 16 16:55:07 2014
Large pages unused system wide = 3 (6144 KB)
Thu Jan 16 16:55:07 2014
Large pages congured system wide = 9668 (19 GB)
Thu Jan 16 16:55:07 2014
Large page size = 2048 KB
Thu Jan 16 16:55:07 2014
In this example the key line was: Total System Global Area in large pages = 19 GB (100%) as it shows that the Total SGA is in large pages.
As a shameless plug check out my Deploying Oracle 11gR2 on RHEL6 reference architectures at:
https://access.redhat.com/site/articles/395013 and my Deploying Oracle 11gR2 RAC on RHEL6 at:
https://access.redhat.com/site/articles/479093
If you have any other questions, feel free to reply to this. :)
Hope that helped and have a great weekend,
Roger

(/user/4000813)
Forgot to mention, to value of memlock should be slightly bigger than the size of the Oracle SGA in kilobytes.
RED HAT
ACTIVE
CONTRIBUTOR Reply (/Ajax_comments/Reply/39188/691603)
182 Points
10 September 2014 10:23 AM (https://access.redhat.com/solutions/39188#comment-814223)
Valeriy Smirnov (/user/8193763)

(/user/8193763)
Roger, but you didn't explain why RedHat recommmends in this article reserve huge pages for
COMMUNITY "+ PGA + (20 KB * # of Oracle processes running)".
MEMBER
You agree that PGA doesn't use shared memory.
22 Points
You add some pages to SGA size for safety.
But PGA can be huge. And it's advisable parameter - Oracle tries to limit PGA by pga_aggregate_target, but it cann't guarantee it and it/s
normal behaviour.
If you cann't explain it "+ PGA + (20 KB * # of Oracle processes running)" - remove it from article.
It looks that RedHat doesn't know from where it comes but it leaves it in article.
It's not good.
16 September 2014 2:38 PM (https://access.redhat.com/solutions/39188#comment-818063)
Fabio Tavano (/user/724433)

(/user/724433)
COMMUNITY
MEMBER I'm interested too to know why the author of the article (good for the other aspects) take in account also PGA and number of oracle
41 Points processes.
I didn't found that calculation in any Oracle knowledge base.
Hope to read from Roger soon.
Regards
Anne Robbins (/user/5512813)

(/user/5512813)
Thank you very much for your responses. A couple of questions: Any strong reason not to set memlock for Oracle to unlimited (as shown in
NEWBIE your log example)? Is there a really great risk of Oracle getting out of hand and xing more memory than its SGA? This would certainly
10 Points reduce the need to change this setting every time SGA is increased.
And, yes, I have seen at least one of your articles mentioned above, which brings me to my next question. A couple of the settings you
recommend differ signicantly from those in this article, the most dramatic difference being dirty_pages_ratio, which you recommend
raising signicantly from the default, while this article recommends lowering it. Did you specically have RH 6 in mind when you made that
recommendation - would you make the same recommendation for RH 5? I have seen the KB article 348683 that seems to imply that the
setting should be done in bytes, not ratio, if using huge pages at RH 5 - another thing on the to-do list for huge pages?

(/user/4000813)
Hi Anne,
RED HAT
ACTIVE I'm not sure why the log shows the memlock value as unlimited, because I denitely have a value set. I don't think there is a great risk of
CONTRIBUTOR
Oracle getting out of hand and xing more memory than its SGA. Oracle is just looking to see if large pages are available and if it can
182 Points
accommodate all the memory of the SGA into large pages. As for the value set for memlock, I'd set it to slightly larger than what you believe
will be your largest SGA at any point in time. This way all your use cases with a smaller SGA are taken care of.
With regards to the dirty_ratio, the reason I increased the value from what you normally see as 15 to 80 is based on my understanding of
dirty ratio. Dirty ratio denes the maximum percentage of total memory that can be lled with dirty pages before user processes are forced
to write dirty buffers themselves during their time slice instead of being allowed to do more writes. Note that all processes are blocked for
writes when this happens, not just the one that lled the write buffers. This can cause what is perceived as an unfair behavior where a single
proces can hog all the I/O on a system. However, an application that can handle their writes being blocked altogether might benet from
decreasing the value.
The biggest thing I want to point out about kernel parameters in general is that there is no perfect answer. Every workload is different and
requires performance testing. These values should just be seen as a starting point for your workload. The behavior of this parameter to my
knowledge is the same for RHEL5 and RHEL6 so it would apply to both distributions.
The vm.dirty_background_bytes and vm.dirty_bytes is something I'm looking into further but have not tested personally. Due to that, I'm
sticking to the use of ratios until I'm able to do some performance testing around the difference between using ratios vs bytes parameters.
Hope that helps and if you have any other questions feel free to ask :)
Take care,
Roger
Miguel Perez Colino (/user/228343)

(/user/228343)
The grub modication can be done by issuing the following command:
RED HAT
grubby --update-kernel=ALL --args="transparent_hugepage=never"
ACTIVE
CONTRIBUTOR
(via eminguez)
242
Points C U S T O M E R (https://access.redhat.com/)
P O R TA L
P O R TA L

21 March 2014 10:00 AM (https://access.redhat.com/solutions/39188#comment-726223)
Ramkumar Natarajan (/user/3838633)

(/user/3838633)
HugePages:
COMMUNITY Missed the line in sysctl.conf,
MEMBER
without mentioned oracle/dba group id, oracle user not able to access the huge pages.
25 Points
vm.huge_tlb_shm_group = gid
Gi Kim (/user/2014383)
(/user/2014383) 75% of System Memory in bytes
NEWBIE mem=$(free|grep Mem|awk '{print $2}') # KiB
17 Points totmem=$(echo "$mem1024"|bc) # B
max=$(echo "$totmem75/100"|bc) # B
HugePages in KiB
huge=$(grep Hugepagesize /proc/meminfo|awk '{print $2}') # KiB
all=$(echo "$max/$huge"|bc)
So in the above calculation you have B / KiB .. i think $huge should also be put into the same metrics (Bytes).. (times $huge by 1024)
29 July 2014 1:56 AM (https://access.redhat.com/solutions/39188#comment-795913)
Gi Kim (/user/2014383)
(/user/2014383)
kernel.shmall is measured in "pages". In the summit notes and this guide it is assumed the pages is 2MiB (that is why you divide by
NEWBIE 'hugepagesize'). When i set the value in /etc/sysctl.conf and use ipcs -l to conrm the new size i nd that the O/S is multiplying the value in a
17 Points page size of 4KiB rather than 2MiB.
Any guidance on how to set and check shared memory values when hugepages is in use?
10 September 2014 8:18 AM (https://access.redhat.com/solutions/39188#comment-814143)
Valeriy Smirnov (/user/8193763)

(/user/8193763)
1. Calculate the recommended number of HugePages using the formula below, using Hugepagesize and >the System Global Area
COMMUNITY
MEMBER (SGA) and Program Global Area (PGA) values from Oracle. See Oracle >documentation for more about SGA and PGA, and where
22 Points to nd those values:
(SGA + PGA + (20 KB * # of Oracle processes running)) / (Hugepagesize)
Why we reserve hugepages for PGA and for (20 KB * # of Oracle processes running) ?
Oracle stated that hugepages are used only for SGA(shared memory).
13 November 2014 4:40 PM (https://access.redhat.com/solutions/39188#comment-850743)
Bret Sanders (/user/9231793)

(/user/9231793)
Some of the recommended values differ from at least one of the referenced articles, like https://access.redhat.com/articles/395013, which
NEWBIE we have been following. Which article do we follow and why? Is the intent of this one to correct the previous?
17 Points
24 February 2015 10:43 AM (https://access.redhat.com/solutions/39188#comment-888653)
Ameya Sathe (/user/3903963)

The solution does not mention the environment of Red Hat Enterprise Linux 7. Is it not veried?
(/user/3903963)
RED HAT Reply (/Ajax_comments/Reply/39188/888653)
COMMUNITY
MEMBER
27 Points
6 May 2015 3:49 PM (https://access.redhat.com/solutions/39188#comment-915923)

(/user/76163)
Is it me or this KB solution article looks totally not professionnal? Tons of comments, but we don't know it's valid or not, or included in the
COMMUNITY article or not. Also, there is no way to know what has been edited since the last version of the article. I recive notications when it changes,
MEMBER
but have no idea what changes every time.
52 Points

(/user/76163)
Isn't there a way to keep tuned enabled, but have it disable transparent huge pages? See here:
COMMUNITY https://access.redhat.com/sites/default/les/attachments/deploying-oracle-11gr2-rac-on-rhel6_1.1.pdf
MEMBER
52 Points By the same token, why not integrate this article in this document, once all the parameters are validated?
29 September 2015 10:30 PM (https://access.redhat.com/solutions/39188#comment-970763)
Jose Gonzalez Goni (/user/9815943)

(/user/9815943)
Gi Kim
NEWBIE
15 Points 75% of System Memory in bytes

mem=$(free|grep Mem|awk '{print $2}') # KiB
totmem=$(echo "$mem1024"|bc) # B
max=$(echo "$totmem75/100"|bc) # B
HugePages in KiB
huge=$(grep Hugepagesize /proc/meminfo|awk '{print $2}') # KiB
all=$(echo "$max/$huge"|bc)
So in the above calculation you have B / KiB .. i think $huge should also be put into the same metrics (Bytes).. (times $huge by 1024)"
I completely agree with Gi Kim on this.

I do not believe you can divide Bytes by KB. It is a simple maths rule.
Also this calculation will produce the wrong results.
Furthermore if you were to convert the huge page size to Bytes, the value of shmall would be way too small.
Also, every other article in RH KB and on the internet use the system page size (4096 Bytes) for this calculation.
Could you please clarify.
Thanks
Kyle Walker (/user/2171033)

(/user/2171033)
Well spotted! I have corrected this calculation so that like-units carry through the calculation. This should be a much more correct resulting
RED HAT
value for the shmmax tunable (measured in bytes)
EXPERT

Points
3 December 2015 2:02 AM (https://access.redhat.com/solutions/39188#comment-992693)
Jose Gonzalez Goni (/user/9815943)

The calculation for shmall and shmmax is buggy. It seems that the free command does not always show the full number of bytes. i.e:
(/user/9815943)
NEWBIE #free -h
15 Points total used free shared buffers cached
Mem: 19G 18G 826M 4.9G 397M 16G
-/+ buffers/cache: 1.9G 17G
Swap: 49G 0B 49G
#free -b
total used free shared buffers cached
Mem: 2095443148 2008875008 865681408 5300641792 416825344 1759333171
-/+ buffers/cache: 2078593024 1887583846
Swap: 5368289280 0 5368289280
In this case, 19GB = 20954431488 bytes but free -b shows 2095443148 bytes (note the missing 8 at the end).
I suggest using this:
memkb=$(grep MemTotal /proc/meminfo | awk '{print $2}') mem=$(echo "$memkb * 1024" | bc)
Thanks
Toronto Transit Comission (/user/10545793)

(/user/10545793)
not complete
COMMUNITY
MEMBER
23 Points
Jose Eskert (/user/6366013)

(/user/6366013)
System Z
NEWBIE
9 Points Reply (/Ajax_comments/Reply/39188/1110811)
19 April 2017 5:28 PM (https://access.redhat.com/solutions/39188#comment-1167681)

(/user/76163)
There is now a tuned-proles-oracle package for RHEL6 and 7. I think the article should be updated to reect tuned's usage.
COMMUNITY
MEMBER
52 Points
Jason Nance (/user/15218151)

(/user/15218151)
It seems that this guide isn't quite in sync with the tuned prole provided by tuned-proles-oracle in EL 6.8 and higher. Which is the more
NEWBIE up-to-date resource?
12 Points
Privacy Policy (http://www.redhat.com/en/about/privacy-policy)
Customer Portal Terms of Use (https://access.redhat.com/help/terms/)
All Policies and Guidelines (http://www.redhat.com/en/about/all-policies-guidelines)
Copyright 2017 Red Hat, Inc.

Tuning Red Hat Enterprise Linux For Oracle and Oracle RAC Performance

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Tuning Red Hat Enterprise Linux For Oracle and Oracle RAC Performance

Загружено:

Авторское право:

Доступные форматы

8/9/2017 Tuning Red Hat Enterprise Linux for Oracle and Oracle RAC performance - Red Hat Customer

mance - Red Hat Customer Portal

Memory settings in /etc/sysctl.conf:

Maximum percentage of active memory that can have dirty pages:

Maximum percentage of total memory that can have dirty pages:

How long data can be in page cache before being expired:

1. Obtain the Hugepagesize from /proc/meminfo

$ grep Huge /proc/meminfo

SGA / huge page size

(20971520 / 2048) = 10240

So, 10240 is amount of huge pages required to t the 20GB SGA.

3. Add that number to the /etc/sysctl.conf setting:

kernel /vmlinuz-<kernel-version> ro root=/dev/vg01/lv01 hugepages=15369 <other boot options>

Limits setting in /etc/security/limits.conf:

oracle soft memlock 1048576

According to the documentation (https://www.kernel.org/doc/Documentation/sysctl/kernel.txt):

Obtain the total memory in the system in bytes:

mem=$(free -b | awk '/Mem/ {print $2}')

Get page size in bytes:

all=$(expr $mem \* 75 / 100 / $page + 1)

Multiply the SHMALL value by the page size to get SHMMAX :

max=$(expr $all \* $page)

echo "kernel.shmmax = $max" >> /etc/sysctl.conf

echo "kernel.shmmni = 4096" >> /etc/sysctl.conf

Recommended minimums for semaphore operations:

kernel.sem="250 32000 100 128"

# sysctl -w "kernel.sem = 250 32000 100 128"

Open le descriptors for oracle user

Disable tuned and ktune services if you have it.

# service tuned stop

Append "transparent_hugepage=never" to kernel command line in /boot/grub/grub.conf le.

kernel /boot/vmlinuz-2.6.32-358.el6.x86_64 ro root=UUID=a216d1e5-884f-4e5c-859a-6e2e2530d486 rhgb quiet transparent_hugepage=never

Reboot the server for changes to take effect.

Product(s) Red Hat Enterprise Linux (/taxonomy/products/red-hat-enterprise-linux) Component kernel (/components/kernel)

Category Performance tune (/category/performance-tune)

rhel_5 (/tags/rhel_5) rhel_6 (/tags/rhel_6) rhel_7 (/taxonomy/tags/rhel7)

Wilmer Jaramillo M. (/user/433253)

18 October 2011 5:32 AM (https://access.redhat.com/solutions/39188#comment-334613)

David Powles (/user/8963) Administrator

(/user/8963)Thanks for the feedback! I've corrected the article.

25289 Reply (/Ajax_comments/Reply/39188/334613)

23 January 2012 5:08 PM (https://access.redhat.com/solutions/39188#comment-337973)

5 Points Reply (/Ajax_comments/Reply/39188/337973)

30 October 2012 7:27 PM (https://access.redhat.com/solutions/39188#comment-431463)

HP Linux Engineering team (/user/1185973)

20 November 2012 12:45 AM (https://access.redhat.com/solutions/39188#comment-435993)

Sergey Guzenkov (/user/1786133)

2378 Reply (/Ajax_comments/Reply/39188/435993)

20 November 2012 3:57 AM (https://access.redhat.com/solutions/39188#comment-436023)

20 November 2012 5:22 AM (https://access.redhat.com/solutions/39188#comment-436043)

Sergey Guzenkov (/user/1786133)

PRO Reply (/Ajax_comments/Reply/39188/436043)

16 July 2013 6:41 PM (https://access.redhat.com/solutions/39188#comment-499703)

Jesse Johnson (/user/3074453)

23 October 2013 3:32 AM (https://access.redhat.com/solutions/39188#comment-562073)

Ugo Bellavance (/user/76163)

24 October 2013 2:31 PM (https://access.redhat.com/solutions/39188#comment-563153)

Marc Milgram (/user/5073)

17 January 2014 11:27 PM (https://access.redhat.com/solutions/39188#comment-691493)

Anne Robbins (/user/5512813)

18 January 2014 4:13 AM (https://access.redhat.com/solutions/39188#comment-691593)

Roger Lopez (/user/4000813)

************************ Large Pages Information *******************

****** Large Pages Information *