Shared Memory Test
Shared memory (SHM) is another method of interprocess communication (IPC) whereby 2 or more processes share a single chunk of memory to communicate. The shared memory system can also be used to set permissions on memory, allowing for things like malloc debuggers to be written.
Shared memory is persistent. It does not go away when no program is referencing it. This can be a good thing, but it can tie up system resources. To conserve system resources, administrators should cleanup the shared memory if it is not in use anymore. But, how would administrators know whether a shared memory segment is currently in use or not, and if used, which processes are using it? For this, administrators can use the Shared Memory test. This test auto-discovers the owners of SHM segments, monitors the usage of each segment, and reports the number of SHM segments owned by each owner, the number of segments mapped to/not mapped to processes, the count of processes attached to the segments, the total size of the SHM segments owned by each owner, and the number of SHM segments removed, cleared, and locked for every owner. This way, the test points to those owners with SHM segments that are not even mapped to any process, leave alone being used; thus memory segments that are candidates for removal/release can be identified.
This test is disabled by default. To enable the test, go to the enable / disable tests page using the menu sequence : Agents -> Tests -> Enable/Disable, pick the desired Component type, set Performance as the Test type, choose the test from the DISABLED TESTS list, and click on the << button to move the test to the ENABLED TESTS list. Finally, click the Update button.
Target of the test : A Linux, AIX, HPUX, or Solaris server
Agent deploying the test : An internal agent
Outputs of the test : One set of results for every SHM segment owner (by default) of the server being monitored
Parameter | Description |
---|---|
Test Period |
How often should the test be executed. |
Host |
The host for which the test is to be configured. |
Report by |
By default, this flag is set to Owner. This implies that, by default, the test metrics for every message queue owner on the target server. You can set this flag to Total, if you want the test to report metrics for the Total descriptor alone; in this case, the test will aggregate measures across all the message queues on the server. Alternatively, you can pick the Owner and Total option. In this case, the test will report metrics per owner and also for the Total descriptor. |
DD Frequency |
Refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 1:1. This indicates that, by default, detailed measures will be generated every time this test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD frequency. |
Detailed Diagnosis |
To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:
|
Measurement | Description | Measurement Unit | Interpretation |
---|---|---|---|
Number of shared memory segments |
For each owner, this indicates the number of shared memory segments owned by that owner. For the Total descriptor, this indicates the total number of shared memory segments on the target server, regardless of owner. |
Number |
This measure will be reported for the Total descriptor, only if the Report by flag is set to Total or Owner and Total. To know the complete details of each SHM segment owned by an owner, use the detailed diagnosis of this measure. From the detailed diagnosis, you can figure out which user and process created each SHM segment, when it was created, the size of each segment, the number of processes mapped to each segment, and more! Using this information, you can accurately isolate those SHM segments that are of the maximum size, and those that have been sized poorly. You can also point to SHM segments that are not attached to any processes; you can either attach such segments to processes, remove them, or clear the space in them to conserve system resources. |
Number of shared memory segments with no process attached |
For each owner, this indicates the number of shared memory segments owned by that owner to which no processes are attached currently. For the Total descriptor, this indicates the total number of shared memory segments on the target server without any processes attached. |
Number |
This measure will be reported for the Total descriptor, only if the Report by flag is set to Total or Owner and Total. You can use the detailed diagnosis of this measure to know which segments have no processes attached. Such segments are candidates for removal / space release. |
Number of processes attaching to shared memory segments |
For each owner, this indicates the number of processes that are currently attached to the SHM segments owned by that owner. For the Total descriptor, this indicates the total number of processes attached to all SHM segments on the target server. |
Number |
This measure will be reported for the Total descriptor, only if the Report by flag is set to Total or Owner and Total. You can use the detailed diagnosis of this measure to know which processes are attached to which SHM segment. |
Total size of shared memory segments: |
For each owner, this indicates the total size of all SHM segments owned by that owner. For the Total descriptor, this indicates the total size of all SHM segments on the target server. |
KB |
This measure will be reported for the Total descriptor, only if the Report by flag is set to Total or Owner and Total.
|
Number of shared memory segments removed |
For each owner, this indicates the number of SHM segments owned by that owner that have been removed. For the Total descriptor, this indicates the total number of SHM segments that have been removed from the target server. |
Number |
This measure will be reported for the Total descriptor, only if the Report by flag is set to Total or Owner and Total. You can use the detailed diagnosis of this measure to know which shared memory segments have been removed. |
Number of shared memory segments cleared |
For each owner, this indicates the number of SHM segments owned by that owner that have been cleared. For the Total descriptor, this indicates the total number of SHM segments on the server that have been cleared. |
Number |
This measure will be reported for the Total descriptor, only if the Report by flag is set to Total or Owner and Total. You can use the detailed diagnosis of this measure to know which shared memory segments have been cleared. |
Number of shared memory segments locked |
For each owner, this indicates the number of SHM segments owned by that owner that are currently locked. For the Total descriptor, this indicates the total number of SHM segments on the server that are currently locked. |
Number |
Since multiple processes may attempt to modify a shared memory segment at the same time, it is possible that certain errors could crop up when updates to the segment occur simultaneously. This concurrent access is almost always a problem when you have multiple writers to a shared object. To get around this, you can use semaphores to lock the shared memory segment while a process is writing to it. This measure will be reported for the Total descriptor, only if the Report by flag is set to Total or Owner and Total. You can use the detailed diagnosis of this measure to know which shared memory segments are locked currently. |