Semaphores and Oracle 11g
Semaphores are data structures within the operating system that function like signals for memory process communications.
For Oracle, semaphores tell the Oracle processes when to stop, wait or start operations. In addition, semaphores tell Oracle processes when they are to resume processing. Each Oracle process has its own semaphore assigned to it.
For example, DBWR (Database Writer process) needs to flush the database buffer cache to write to the data files on disk. When it is time for DBWR to perform this task, DBWR semaphore signals to DBWR to flush the data from the buffer out to disk. With System V implementations and variations of the UNIX and LINUX operating system, some of the key parameters that manage the use and allocation of semaphores with Oracle 11g exist in the following operating system level parameters:
The output of semaphores can be viewed by using the ipcs command for UNIX and Linux platforms as will be observed in the following section on shared memory and Oracle 11g.
Semaphore Management in UNIX
A semaphore is a term used for a signal flag used by the Navy to communicate between ships. In some dialects of UNIX, semaphores are used by Oracle to serialize internal Oracle processes and guarantee that one thing happens before another thing. Oracle uses semaphores in HP/UX and Solaris to synchronize shadow processes and background processes. However, AIX UNIX does not use semaphores, and a post/wait driver is used instead to serialize tasks.
The number of semaphores for an Oracle database is normally equal to the value of the processes initialization parameter. For example, a database where processes=200 would need to have 200 UNIX semaphores allocated for the Oracle database.
When allocating semaphore in UNIX, it is critical that your UNIX kernel parameter semmns be set to at least double the high-water mark of processes for every database instance on your server. If you fail to allocate enough semaphores by setting semmns too low, your Oracle database will fail at startup time with the message:
ORA-7279: spcre: semget error, unable to get first semaphore set
Let?s talk about setting the semmns kernel parameter. To make changes in kernel shared memory or semaphore parameters, you need to perform the following steps:
Today, most dialects of UNIX have specialized System Administration utilities to perform kernel management (Table 2-4)
| UNIX Dialect | Utility Name |
| HP-UX | SAM |
| SCO | SYSADMSH |
| AIX | SMIT |
| Solaris | ADMINTOOL |
UNIX kernel management tools
System Default values for semaphores
The number of UNIX semaphores is determined by the value of the semmns UNIX kernel parameter.
Viewing semaphores in HP/UX version 11
In HP/UX v 11, the command to display kernel parameters is kmtune and we can grep to see the semaphore settings.
root> kmtune|grep sem
sema 1 semaem 16384 semmap (SEMMNI+2) semmni 200 semmns 800 semmnu 30 semume 10 semvmx 32767
Counting Used Semaphores
The ipcs UNIX command has a ?sa option that can be used to display semaphores. The total number of semaphores is determined by summing the NSEMS column in the ipcs display. In the example below we see that there are 4 semaphores held by the ROOT user and 475 semaphores held by the ORACLE user in 3 database instances.
root> ipcs -as|grep oracle
IPC status from /dev/kmem as of Mon Sep 10 17:25:21 2001 T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS s 15 0x00000000 --ra-r----- oracle dba oracle dba 400
To display semaphores with the ipcs command and remove them with ipcs -pmb, see my notes on Managing UNIX memory with IPCS
Next, let?s take a look at how we can examine UNIX system log messages.
Displaying System log Messages
In UNIX, a system failure will often precipitate an Oracle crash. Any hardware associated with disk, CPU or RAM may cause an Oracle database crash, and the UNIX system logs can be used to identify the initial cause of the Oracle failure.
The following commands are used to display the UNIX error logs. We need to note that you should regularly check the UNIX logs, even if there is not Oracle failure. These commands can also be useful for detecting transient disk I/O problems, memory failures, etc.
Show server log on HP/UX
In HP/UX we have a file in the /var/adm directory called syslog to hold all UNIX system messages. In the command below we search the syslog for any lines that contain the word ?error?.
root> grep ?i error /var/adm/syslog/syslog.log|more
May 1 20:30:08 sprihp01 syslog: NetWorker media: (warning) dev/rmt/c5t6d0BESTn reading: I/O error
Show server log on AIX
In the IBM AIX operating system we use the errpt command to display the contents of the system log.
root> errpt -a|more --------------------------------------------------------------------------- LABEL: CORE_DUMP IDENTIFIER: C60BB505
Date/Time: Tue May 9 10:34:47 Sequence Number: 24908 Machine Id: 000138644C00 Node Id: sp2k6n03 Class: S Type: PERM Resource Name: SYSPROC
Again, checking the UNIX system logs should be a regular activity for the Oracle DBA. Next, let?s take a look at how UNIX can be monitored for performance problems.
For large SGA sizes, HugePages can give substantial benefits in virtual memory management. Without HugePages, the memory of the SGA is divided into 4K pages, which have to be managed by the Linux kernel.
Using HugePages, the page size can be increased to any value between 2MB and 256MB, thereby reducing the total number of pages to be managed by the kernel and therefore reducing the amount of memory required to hold the page table in memory.
In addition to these changes, the memory associated with HugePages does not get swapped out, which forces the SGA to stay resident. The savings in memory and resources of page management make HugePages a great addition for Oracle 11g systems running on x86-64 architectures.
Note. Automatic Memory Management (AMM) is not compatible with HugePages, so apart from ASM instances and small unimportant databases, you will probably have no need for AMM on a real system. Instead, Automatic Shared Memory Management and Automatic PGA Management should be used as they are compatible with HugePages.
This command can show the current HugePage usage. The default HugePage size is 2MB on Oracle Linux 5.x and as you can see from the output below, by default no HugePages are defined.
grep HugePages /proc/meminfo
Failure to properly configure amount of hugepages on your Linux box and your instance may silently revert to 4k memory pages resulting in excessive paging/swapping.
Since 11.2.0.2 there is a parameter use_large_pages that controls hugepages allocation behavior. This parameter is not hidden, however there is nothing in public documentation but some notes on metalink (USE_LARGE_PAGES To Enable HugePages In 11.2 [ID 1392497.1]) and blog posts from Oracle guys.
This parameter can have three distinct values and defaults to use_large_pages=true.
In 11.2.0.2 default value preserves old behavior – if there are less hugepages then total allocated SGA – Oracle will write a warning message to alert.log and will go on with normal pages.
With use_large_pages=only Oracle will check during the startup if there’s enough preallocated large pages and if there isn’t – will not proceed starting up with a message like
Specified value of sga_max_size is too small, bumping to 94220845056 ****************** Large Pages Information ***************** Parameter use_large_pages = ONLY Large Pages unused system wide = 43000 (84 GB) (alloc incr 256 MB)
Large Pages configured system wide = 43000 (84 GB)
Large Page size = 2048 KB ERROR: Failed to allocate shared global region with large pages, unix errno = 12. Aborting Instance startup.
ORA-27137: unable to allocate Large Pages to create a shared memory segment ACTION: Total Shared Global Region size is 88 GB. Increase the number of unused large pages to atleast 44932 (88 GB) to allocate 100% Shared Global Region with Large Pages. ***********************************************************
With use_large_pages=false Oracle obviously will not use any of the large pages even if there are enough of them.
In 11.2.0.3 the default behavior has changed – now with use_large_pages=true and less then SGA hugepages Oracle will allocate part of the SGA with them and the resting part with normal 4k pages. In alert.log it will look like
Specified value of sga_max_size is too small, bumping to 94220845056 ****************** Large Pages Information ***************** Total Shared Global Region in Large Pages = 84 GB (95%) Large Pages used by this instance: 42881 (84 GB) Large Pages unused system wide = 119 (238 MB) (alloc incr 256 MB) Large Pages configured system wide = 43000 (84 GB) Large Page size = 2048 KB
RECOMMENDATION: Total Shared Global Region size is 88 GB. For optimal performance, prior to the next instance restart increase the number of unused Large Pages by atleast 1929 2048 KB Large Pages (3858 MB) system wide to get 100% of the Shared Global Region allocated with Large pages ***********************************************************
So there is one trap less, but I hope Oracle will be certified for RHEL6 very soon, so we’ll have a transparent hugepages feature that will make this nice new parameter obsolete ).