Example--Checking Page-Out and Memory
The following abbreviated example shows output from the sar -g command.
$ sar -g SunOS venus 5.9 Generic sun4u 06/24/2001 00:00:00 pgout/s ppgout/s pgfree/s pgscan/s %ufs_ipf 01:00:00 0.00 0.00 0.00 0.00 0.00 02:00:02 0.00 0.00 0.00 0.00 0.00 03:00:00 0.00 0.01 0.01 0.00 0.00 04:00:00 0.00 0.00 0.00 0.00 0.00 05:00:01 0.00 0.00 0.00 0.00 0.00 06:00:00 0.00 0.00 0.00 0.00 0.00 Average 0.01 0.12 0.21 0.66 0.00 |
How to Check Kernel Memory Allocation (sar -k)
Use the sar -k command to report on the following activities of the Kernel Memory Allocator (KMA).
The KMA allows a kernel subsystem to allocate and free memory as needed. Rather than statically allocating the maximum amount of memory it is expected to require under peak load, the KMA divides requests for memory into three categories: small (less than 256 bytes), large (512 bytes to 4 Kbytes), and oversized (greater than 4 Kbytes). The KMA keeps two pools of memory to satisfy small and large requests. The oversized requests are satisfied by allocating memory from the system page allocator.
If you are investigating a system that is being used to write drivers or STREAMS that use KMA resources, then the sar -k command will likely prove useful. Otherwise, you will probably not need the information it provides. Any driver or module that uses KMA resources, but does not specifically return the resources before it exits, can create a memory leak. A memory leak causes the amount of memory that is allocated by KMA to increase over time. Thus, if the alloc fields of the sar -k command increase steadily over time, there might be a memory leak. Another indication of a memory leak is failed requests. If this problem occurs, a memory leak has probably caused KMA to be unable to reserve and allocate memory.
If it appears that a memory leak has occurred, you should check any drivers or STREAMS that might have requested memory from KMA and not returned it.
$ sar -k 00:00:00 sml_mem alloc fail lg_mem alloc fail ovsz_alloc fail 01:00:00 2523136 1866512 0 18939904 14762364 0 360448 0 02:00:02 2523136 1861724 0 18939904 14778748 0 360448 0 |
The following table describes the output from the -k option.
Table 24-12 Output From the sar -k Command
Field Name | Description |
|---|---|
sml_mem | The amount of memory, in bytes, that the KMA has available in the small memory request pool (a small request is less than 256 bytes). |
alloc | The amount of memory, in bytes, that the KMA has allocated from its small memory request pool to small memory requests. |
fail | The number of requests for small amounts of memory that failed. |
lg_mem | The amount of memory, in bytes, that the KMA has available in the large memory request pool (a large request is from 512 bytes to 4 Kbytes). |
alloc | The amount of memory, in bytes, that the KMA has allocated from its large memory request pool to large memory requests. |
fail | The number of failed requests for large amounts of memory |
ovsz_alloc | The amount of memory that is allocated for oversized requests (those requests that are greater than 4 Kbytes). These requests are satisfied by the page allocator. Thus, there is no pool. |
fail | The number of failed requests for oversized amounts of memory. |
Example--Checking Kernel Memory Allocation (sar)
The following is an abbreviated example of sar -k output.
$ sar -k SunOS venus 5.9 Generic sun4u 06/24/2001 00:00:00 sml_mem alloc fail lg_mem alloc fail ovsz_alloc fail 01:00:00 2523136 1866512 0 18939904 14762364 0 360448 0 02:00:02 2523136 1861724 0 18939904 14778748 0 360448 0 03:00:00 2523136 1865664 0 18939904 14745884 0 360448 0 04:00:00 2523136 1867692 0 18939904 14746616 0 360448 0 05:00:01 2523136 1867208 0 18939904 14763700 0 360448 0 06:00:00 2523136 1867772 0 18939904 14779444 0 360448 0 Average 2724096 1791806 0 20089344 15434591 0 360448 0 |
How to Check Interprocess Communication (sar -m)
Use the sar -m command to report interprocess communication activities.
$ sar -m 00:00:00 msg/s sema/s 01:00:00 0.00 0.00 |
These figures will usually be zero (0.00), unless you are running applications that use messages or semaphores.
The following table describes the output from the -m option.
Table 24-13 Output From the sar -m Command
Field Name | Description |
|---|---|
msg/s | The number of message operations (sends and receives) per second |
sema/s | The number of semaphore operations per second |
Example--Checking Interprocess Communication
The following abbreviated example shows output from the sar -m command.
$ sar -m SunOS venus 5.9 Generic sun4u 06/24/2001 00:00:00 msg/s sema/s 01:00:00 0.00 0.00 02:00:02 0.00 0.00 03:00:00 0.00 0.00 04:00:00 0.00 0.00 05:00:01 0.00 0.00 06:00:00 0.00 0.00 Average 0.00 0.00 |
How to Check Page-In Activity (sar -p)
Use the sar -p command to report page-in activity which includes protection and translation faults.
$ sar -p 00:00:00 atch/s pgin/s ppgin/s pflt/s vflt/s slock/s 01:00:00 0.07 0.00 0.00 0.21 0.39 0.00 |
The following table describes the reported statistics from the -p option.
Table 24-14 Output From the sar -p Command
Field Name | Description |
|---|---|
atch/s | The number of page faults, per second, that are satisfied by reclaiming a page currently in memory (attaches per second). Instances include reclaiming an invalid page from the free list and sharing a page of text that is currently being used by another process (for example, two or more processes that are accessing the same program text). |
pgin/s | The number of times, per second, that file systems receive page-in requests. |
ppgin/s | The number of pages paged in, per second. A single page-in request, such as a soft-lock request (see slock/s), or a large block size, might involve paging-in multiple pages. |
pflt/s | The number of page faults from protection errors. Instances of protection faults are illegal access to a page and "copy-on-writes." Generally, this number consists primarily of "copy-on-writes." |
vflt/s | The number of address translation page faults, per second. These faults are known as validity faults, and occur when a valid process table entry does not exist for a given virtual address. |
slock/s | The number of faults, per second, caused by software lock requests that require physical I/O. An example of the occurrence of a soft-lock request is the transfer of data from a disk to memory. The system locks the page that is to receive the data, so that it cannot be claimed and used by another process. |
Example--Checking Page-In Activity
The following abbreviated example shows output from the sar -p command.
$ sar -p SunOS venus 5.9 Generic sun4u 06/24/2001 00:00:00 atch/s pgin/s ppgin/s pflt/s vflt/s slock/s 01:00:00 0.07 0.00 0.00 0.21 0.39 0.00 02:00:02 0.07 0.00 0.00 0.21 0.39 0.00 03:00:00 0.32 0.00 0.00 1.10 2.48 0.00 04:00:00 0.09 0.00 0.00 0.32 0.57 0.00 05:00:01 0.07 0.00 0.00 0.21 0.39 0.00 06:00:00 0.07 0.00 0.00 0.21 0.39 0.00 Average 0.26 0.20 0.30 0.92 1.78 0.00 |