Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 159154

Summary: Hugepages does not get allocated for Oracle 10g
Product: Red Hat Enterprise Linux 4 Reporter: Boris Mironov <bmironov>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED DUPLICATE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-05-31 16:03:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Boris Mironov 2005-05-30 18:50:48 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

Description of problem:
Oracle 10g database is certified to run on RHEL4 with no changes.
Unfortunately, my system can not use settings that work fine under RHEL3. Namely, I was able to use hugepages.

Under RHEL4 'cat /proc/meminfo' shows no usage of hugepages after Oracle instance starts. At same time a lot of swapping take place.

Version-Release number of selected component (if applicable):
kernel-2.6.9-5.0.5.ELsmp

How reproducible:
Always

Steps to Reproduce:
1. start kernel with hugepages=500 parameter
2. start Oracle 10g
3. 
  

Actual Results:  /proc/meminfo shows no usage of hugepages

Expected Results:  some hugepages should be allocated by Oracle instance

Additional info:

Regarding to numerous postings about SLES9 kernel 2.6 works fine for Oracle inside hugepages

Comment 1 Boris Mironov 2005-05-31 16:03:49 UTC

*** This bug has been marked as a duplicate of 159195 ***