DB2 and Memory Requirements
From the clIEnt- Memory Requirements
50 Concurrent Connections 186 MB
Kernel Parameters needed for Server:
The kernel maintains certain resources for the implememtation of shared mem.
Specifically a shared mem identifIEr is initialized and maintained by the OS
whenever a shmget system call is executed successfully. The shmid identifIEs
a shared segment which has two components:
The actual shared RAM pages and a data structure that maintains information
about the shared segment
ipcs -ma on server
Shared Memory:
T ID GROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME
m 0 root 1 68 351 351 9:38:32 9:38:32 9:38:32
m 1 dba 25 524288 392 12102 20:54:35 13:25:55 9:38:39
m 2 dba 21 4407296 392 12102 13:25:55 13:25:55 9:38:39
m 3 dba 20 5308416 400 12102 9:38:41 13:25:55 9:38:41
Physical memory usage can be classifIEd into four groups:
1. Kernel memory mapped into kernel address space
2. Process memory is mapped into a process address space
3. Filesystem cache memory that is not mapped into any address space
4. Free memory that is not mapped into any address space
1.Kernel memory is allocated to hold the initial kernel code at boot time, then
grows dynamically as new device drivers and kernel modules are used.
Kernel tables also grow dynamically unlike older versions of Unix.
To check usage
sar or kmastat from crash will show kernel usage
On DB2server
sar -k -1
sml_mem alloc fail lg_mem alloc fail ovsz_alloc fail
78356480 70380352 0 202645504 191583000 0 185065472 0
#crash
kmastat
2. Application process memory
Application processes consist of an address space divided into segments
where each segment maps either to a file, anonymous memory(swap), Shared
memory or a memory mapped device.
/usr/proc/bin/pmap 19660 (db2inst1
shows the base address and size of each segment
total Kb 62432 28232 1968 2626
total resident shared private
resident - indicates resident in main memory
shared - with other processes
private - taken from the free list
3. Cached memory
4. Free memory
Free memory is maintained so that when a new process starts up or an existing
process needs to grow, the additional memory is immediately available.
Memory Sizing Rules and Example: (for a 2GIG)
Item: Rule EG Comment:
System Processes: +system 10MB
System Libraries: +sys librarIEs 15MB
User-Processes +proc_user 9.7MB per user (For large aPPS)
+proc_sys-wide 15.6
Background Process +background priv
+background shar 27MB
Buffer-Cache Memory: +buffer cache 100MB if DB is running RAW
Sys V Shared Memory: +Shar-mem 560MB The db2 Dba set params that generated a 560MB shared memory segment
Kernel Memory: +kernel_mem 150MB Because this is a
RAW db sys, no tuning
Total: 900MB
Memory is allocated in units called pages.
On Db2server it's 8192 bytes per page
IPC'S Interprocess Communication
IPC encompasses facilitIEs provided by the Operating system to enable the
sharing of data (shared memory segments), the Exchange of information and
data(message queues) , and the syncronization of Access to shared resourses
(semaphores) between processes and threads on the same system.
Contrast IPC to networking based facilitIEs such as sockets and RPC
interfaces. which enabled communication over a network link between
distributed systems
Other facilitIEs for IPC's include memory mapped files (mmap), named pipes and
Solaris doors which provide a RPC like facility fro threads running on the
same system.
Shared memory is an interprocess communication (IPC)facility and is used extensively by by relational databases as a means of implementing a cache
- sharing of the same physical RAM pages by multiple processes
These processes have mappings to the same physical pages
The kernel implementation of shared memory requires two loadable kernel
modules : the shmsys module and the ipc module
Semaphores are another IPC facility
Semaphores provide a means of synchronizing Access to shared resources
by multiple processes.
Each time a process needs a resource, a semaphore value gets decremented
and when the process is done the value gets incremented.
These are controlled by the following tunable parameters
a. semmap - determines the max number of entrIEs in a semaphore map
The memory space given to the creation of semaphores is taken from
the fixed number of entrIEs set to semmap
Therefore kernel memory is allocated up front and semaphore subsystem
controls the allocation and deallocation dynamically
on ArtIE: set semsys:seminfo_semmap = 1026
b. semmni - semaphore identifIErs
should never be greater than the semmap .
The semmni tunable establishes the maximum number of semaphore
sets system wide. Every semaphore set in the system has a
unique indentifIEr and control structure. During initialization,
the system allocates kernel memory for semmni control structures.
Each control structure is 84 bytes
On ArtIE: set semsys:seminfo_semmni = 1024
c. semmns - max number of semaphores in system (SEMMNS)
A semaphore set may have more than one semaphore associated with it
On artIE: set semsys:seminfo_semmns = 2048
d. semmnu - semaphore undo structures in system (SEMMNU)
:
set semsys:seminfo_semmnu = 2048
During initialization of the semaphore code, the system checks for the
maximum amount of available kernel memory and divides that number by 4
ensuring that that semaphore requirements do not exceed 25 % of the
available kernel memory.
maximum proceses is determined during startup based on the amount of RAM
sysdef | grep v_proc
jaguar
% sysdef | grep v_proc
3914 maximum number of processes (v.v_proc)
artIE:
% sysdef | grep v_proc
16394 maximum number of processes (v.v_proc)
Asyncronous I/O:
---------------
Databases often use a modern method of queuing I/O requests to the devices
known as asyncronous I/O. using this method, multiple I/O's can be requested
at once, with a asyncronous notification via a signal when the I/O has
completed.
Tunable parameters:
1. Parameters msgmnb and msgmax must be set to at least 65535
65535 max message size (MSGMAX)
65535 max bytes on queue (MSGMNB)
2. Parameter shmmax should be set to 100% of the physical memory (in bytes)
eg
if you have 196 MB of physical memory,
196*0.9*1024*1024 = 184 968 806
in artIE we have shmmax set to
536870912 max shared memory segment size (SHMMAX)
How to Check Interprocess Communication (sar)
Use the sar -m command to report interprocess communication activitIEs.
$ sar -m
00:00:01 msg/s sema/s
01:00:01 0.00 0.00
The figures will be zero unless you are running applications that use
messages or semaphores
msg/s The number of message Operations (sends and receives) per second
sema/s The number of semaphore Operations per second
On jaguar:
jaguar % sar -m | head
SunOS jaguar 5.7 Generic_106541-12 sun4u 11/24/00
00:01:02 msg/s sema/s
00:11:01 78.17 1.36
00:21:01 74.87 3.83
00:31:01 11.95 44.84
00:41:01 66.80 9.66
sar -q
00:01:02 runq-sz %runocc swpq-sz %swpocc
Average 1.9 2 40.8 100
runq-sz -The number of kernel threads in memory waiting for a CPU
to run. Typically, this value should be less than 2.
Consistently higher values mean that the system may be
CPU-bound.
runocc - The percentage of time the dispatch queues are occupIEd
swpq-sz The average number of swapped out LWPS.
%swpocc The percentage of time LWPS are swapped out
The following example shows output from the sar -q command. If %runocc is
high (greater than 90 percent) and runq-sz is greater than 2, the CPU is
heavily loaded and response is degraded. In this case, additional CPU
capacity may be required to obtain acceptable system response.
How to Check Unused Memory (sar)
sar -r
00:01:02 freemem freeswap
Average 1655 2072084
freemem The average number of memory pages available to user
processes over the intervals sampled by the command. Page
size is Machine-dependent.
freeswap The number of 512-byte disk blocks available for page swapping
How to Check CPU Utilization (sar)
sar -u
00:01:02 %usr %sys %wio %idle
verage 19 8 70 2
A high %wio generally means a disk slowdown has occurred
%sys
Lists the percentage of time that the processor is in system
mode
%user
Lists the percentage of time that the processor is in user
mode
%wio
Lists the percentage of time the processor is idle and waiting
for I/O completion
%idle
:How to Check System Table Status (sar)
Use the sar -v command to report the status of the process table, inode table,
file table, and shared memory record table.
$ sar -v
00:00:01 proc-sz ov inod-sz ov file-sz ov lock-sz
15:41:01 73/3914 0 3785/16952 0 502/502 0 0/0
15:51:01 73/3914 0 3785/16952 0 502/502 0 0/0
proc-sz The number of process entrIEs (proc structs) currently being
used, or allocated in the kernel.
inod-sz The total number of inodes in memory verses the
maximum number of inodes allocated in the kernel. This is
not a strict high water mark; it can overflow.
file-sz The size of the open system file table. The sz is given as 0,
since space is allocated dynamically for the file table.
ov - The number of shared memory record table entrIEs
currently being used or allocated in the kernel. The sz is
given as 0 because space is allocated dynamically for the
shared memory record table.
lock-sz The number of shared memory record table entrIEs
currently being used or allocated in the kernel. The sz is
given as 0 because space is allocated dynamically for the
shared memory record table.
When the system first loads the shared memory module, it allocates kernel
memory to support the shmid structures and other required kernel support
structures. The kernel memory required is based on the shmmni tunable, since
that defines the requested number of unique shared memory identifIErs the
system maintains. Each shmid_ds structure is 112 bytes in size and has a
corresponding kernel mutex lock, which is an additional eight bytes. Thus,
the amount of kernel memory required by the system to support shared
memory can be calculated as ((shmmni * 112) + (shmmni * ). The default value
of 100 for shmmni requires the system to allocate about 13 kilobytes of kernel
memory for shared memory support. The system makes some attempt at
protecting itself against allocating too much kernel memory for shared
memory support by checking for the maximum available kernel memory,
dividing that value by four, and using the resulting value as a limit for
allocating resources for shared memory. Simply put, the system will not allow
more than 25 percent of available kernel memory to be allocated.
------------------------------------------------------------------------
It should be clear that one should not set shmmni to an arbitrarily large value
simply to ensure sufficIEnt resources. There are limits as to how much kernel
memory the system supports. On sun4m-based platforms, the limits are on
the order of 128 megabytes (MB) prior to Solaris 2.5, and 256 MB for 2.5,
2.5.1, and 2.6. On sun4d systems (SS1000 and SC2000), the limits are about
576 MB in 2.5 and later. On UltrASPARC[sun4u]-based systems, the kernel
has its own four gigabyte (GB) address space, so it's much less constrained.
Still, keep in mind that the kernel is not pageable, and thus whatever kernel
memory is needed remains resident in RAM, reducing available memory for
user processes. Given the fact that Sun ships systems today with very large
RAM capacitIEs, this may not be an issue, but it should be considered
nonetheless. (sun4m, sun4d, and sun4u is Sun nomenclature for defining
different "kernel architectures.") Every Operating system has some
hardware-independent and hardware-dependent components to it -- the
hardware-dependent components are at the lower levels, where hardware
:registers, and things get touched. Different kernel architectures exist for
different Sun desktop and server systems and vary due to processor
technology (SuperSPARC, UltrASPARC, etc.) and system infrastructure
(Mbus, XDbus, Gigaplane, etc.). Use uname(1M) with the -m flag to determine
what your systems kernel architecture is:
% uname -m
Note that the maximum value for shmmni listed in Table 2 is 2 GB. This is a
theoretical limit, based on the data type (a signed integer) and should not be
construed as something configurable today. Applying the math from above,
you see that two billion shared memory identifIErs would require over 200 GB
of kernel memory! One should assess to the best of their ability the number
of shared memory identifIErs required by the application and set shmmni to that
value plus 10 percent or so for headroom.
The remaining three shared memory tunables are quite simple in their
meaning. Shmmax defines the maximum size a shared segment can be. The size
of a shared memory segment is determined by the second argument to the
shmget(2) system call. When the call is executed, the kernel checks to ensure
that the size argument is not greater than shmmax. If it is, an error is returne
d.
Setting shmmax to its maximum value does not effect the kernel size -- no
kernel resources get allocated based on shmmax, so this can be tuned to its
maximum value of 4 GB (0xffffffff), as in this (/etc/system) entry:
The shmmin tunable defines the smallest possible size a shared segment can be,
as per the size argument passed in the shmget(2) call. There's no real
compelling reason to set this from the default value of 1. Lastly, there's
shmseg, which defines the number of shared segments a process can attach
(map pages) to. Processes may attach to multiple shared memory segments
for application purposes, and this tunable determines how many mapped
shared segments a process can have attached at any one time. Again, the
32-kilobyte (K) limit (maximum size) in Table 2 is based on the data type
(short), and does not necessarily reflect a value that will provide application
performance that meets business requirements if some number of processes
attach to 32,000 shared memory segments. Things like shared segment size
and system size (amount of RAM, number/speed of processors, etc.) will all
factor into determining the extent to which you can push the boundarIEs of
:factor into determining the extent to which you can push the boundarIEs of
this facility.
t should be pointed out that the kernel makes no attempt at coordinating
concurrent Access to shared segments. This must be done by the software
developer using shared memory in order to prevent multiple processes
attached to the same shared pages from writing to the same locations at the
same time. There are several ways this can be done, the most common of
which is the use of another IPC facility, semaphores.
Semaphores provide a means of
synchronizing Access to shared resources and
are used quite often to synchronize Access to
shared memory segments by multiple
processes in applications.
The semmap parameter determines the maximum number of entrIEs in a
semaphore map. The memory space given to the creation of semaphores is
taken from the semmap, which is initialized with a fixed number of map entrIEs
based on the value of semmap. The implementation of allocation maps is
generic within Unix SVR4 and also Solaris, supported with a standard set of
kernel routines (rmalloc(), rmfree(), etc.). The use of allocation maps by the
semaphore subsystem is just one example of their implementation. They
basically prevent the kernel from having to deal with allocating and
de-allocating additional kernel memory as semaphores get initialized and
freed. By initializing and using allocation maps, kernel memory is allocated
upfront, and map entrIEs are allocated and freed dynamically from the semmap
allocation maps. The semmni tunable should never be larger than semmap. In fact,
semmap should be set to the product of semmni and semmsl: (semmap = semmni *
semmsl). If you make semmap to small for the application, you'll get
"WARNING: rmfree map overflow" messages on the console. Tweak it
higher and reboot.
