Previous | Table of Contents | Next

Page 560

currently occupying can be overwritten by the new information; but if a data page is overwritten or paged out, that page must be written or copied to disk before the overwriting of the physical page can begin. The reason behind this is simply that text pages are never modified, and the image of the text page can always be obtained from the file system.

A UNIX process is actually divided into six regions: text, stack, heap, BSS, initialized data, and shared memory.

Text, as mentioned, is the shared-between processes and is paged from filesystem. It contains the machine instructions and they are marked read-only.

Stack is private to the process, is paged from the swap area, and contains the runtime execution stack. The runtime stack contains function and procedure activation records apart from function and procedure parameters. The stack pages are marked as read/write. The size of the stack can grow.

Heap contains the data pages that are allocated to the process as it runs. The heap is a private process region, and its size can grow very large during program execution. The heap pages, marked as read/write, are paged from the swap area.

The BSS segment is also private to the process. It's marked as read/write, its size remains static during the execution of the process, and the pages of the BSS segment are marked as read/write. The size of this segment remains fixed during the execution of the program. This segment is used to store statically allocated uninitialized data, and these pages are paged from the swap area.

The initialized data segment is private to the process. It's marked as read/write, it is paged from the swap, and the size remains constant during the execution of the process.

Shared memory segments, as the name says, are pages that are shared between processes. They are marked as read/write. Shared pages are allocated using the shmget() system call. Processes are attached to share pages by using the shmat() system call. Shared pages are paged from the swap, and the size of the shared memory segment remains fixed when the allocation is done.

Taking a Memory Overview

Before you probe into finer details of individual processes using the memory, you must first take an overview of the system. The key thing to look for when taking a memory overview of the system is excessive paging and swapping on the system. If memory is scarce on the system, a process allocated a time slice of the CPU will use the CPU time for swapping and paging and do nothing else, which could be very drastic for the performance of the system. High paging and swapping activity on the system will severely hamper system performance and must be prevented as much as possible either by adding extra physical memory or by rescheduling processes.

On UNIX systems, vmstat and sar are utilities that can be used to monitor the system memory usage. The disadvantage of both of these tools is that they will allow memory to be monitored only at an overall level and do not give the per-process memory usage breakup. Shown in Listing 22.20 is the output of the vmstat command.

Page 561

Listing 22.20 Output of vmstat Command Used for Monitoring Memory Usage
vmstat -S 2 10
procs      memory             page    faults                   cpu
r  b  w   avm free   si so  pi  po  fr  de  sr   in   sy   cs us sy id
1 111 0  5152 2885   0   0   0   0   0   0   0 1028 3068 1121 19  8 73
1 111 0  5152 2885   0   0   0   0   0   0   0 1004 2778 1074 17  5 78
2 117 0  4986 2885   0   0   0   0   0   0   0 1022 2666 1097 18 10 72
2 117 0  4986 2885   0   0   0   0   0   0   0 1008 2618 1129 22  7 71
0 111 0  5644 2842   0   0   0   0   0   0   0  994 2742 1079 27 10 64
0 111 0  5644 2841   0   0   0   0   0   0   0 1016 2974 1210 24 14 63
0 111 0  5644 2927   0   0   0   0   0   0   0 1029 4388 1438 21  9 70
0 109 0  5816 2927   0   0   0   0   0   0   0  997 3656 1359 12  8 81
0 109 0  5816 2927   0   0   0   0   0   0   0  953 3135 1255 16  5 79

The important columns of interest are in Table 22.3.

Table 22.3 Important Columns in the vmstat Output
Column Name Description
procs Report on number of processes in various states
r Number of processes in run mode
b Number of processes in block mode
w Number of processes swapped and waiting for processing resources
Memory Reports on real and virtual memory
avm The average active memory
free The size of the free list in pages
page Reports on the page faults in the interval
si Number of pages swapped in
so Number of pages swapped out
pi Number of kilobytes paged in (Check Out)
po Number of kilobytes paged out
cpu Reports on CPU usage
us Percentage of time spent on servicing user requests
sy Percentage of time spent on servicing system calls
id Idle time


As you can see, the vmstat command is quite comprehensive and gives almost an entire overview of the system from memory usage, process states, and the CPU usage percentages.

Page 562

In this output, key things to look for as far as memory usage is concerned are the columns po, so, b, and w.

If the po (page outs) and so (swap outs) values are high, it indicates severe memory shortage on the system. In Listing 22.20, there are no page outs occurring on the system. There is approximately 2885¥4KB (4KB is the size of the memory page)= 11.26MB of free memory available on the system.

NOTE
When looking at the outputs of po and so, you must ensure whether high swapping or paging is happening regularly before you can make any inferences from it. To ascertain this, the previous command should be run at different points in the day to check whether the system is constantly paging or swapping.n

If you look at the previous output, you see that the b column indicates a high number of blocked processes. I did some further investigation by using the sar -d command and found that the high number of blocked processes were due to some heavy I/O occurring on a few disks, and the processes were blocked on account of the I/Os that were waiting to be completed. If the vmstat output shows a high number of pagings or swappings, you must identify the heavy resource users.

Finding Heavy Memory Users

Monitoring the individual memory usage of memory on UNIX systems can be pretty tricky. Most utilities, such as vmstat and sar, will report the memory usage at a system level and will not report the per-process memory usage. Another reason the actual physical memory usage is not easy to access is the fact that each process is divided into text and data, and the text pages are shared between processes while the data pages are private to the process. If the process is attached to a shared memory segment, this offset must be subtracted to obtain the actual private memory (the memory used by the process). As the text page is shared, this will be reported in the virtual memory usage of all the processes. Therefore, if you add the virtual memory usage of all the processes on the system, the figure obtained will be much larger than the actual virtual memory used by all the processes.

Nevertheless, you can make an assumption that when monitoring memory on an Oracle system, all the processes share the same text (that is, Oracle executable) page. If all the processes are using the same executable, the offset text memory usage of all the processes is the same. The rest of the memory is the private memory used by the process. On UNIX systems, the ps command with the -l option can be used to determine the per-process memory usage of each individual process. The -l option reports the memory usage under the SZ column of the ps output. The ps command shown in Listing 22.21 can be used to monitor memory usage of Oracle processes (foreground and background) on the system. The SZ column reports the size of the physical page of the core image of the process. It includes the text, data, and the stack space. The output in Listing 22.21 shows the ps command sorted in descending order of the SZ column, which is the tenth column in the output. This output gives a fair idea of the text + data + stack usage of all Oracle processes.

Previous | Table of Contents | Next