A P P E N D I X B |
OpenSSP Memory Worksheet |
This appendix provides a blank SSP memory worksheet and explains how the predetermined memory values in the worksheet are derived.
This section contains a blank SSP memory worksheet that you can use to determine the memory requirements for your SSP configuration.
(Virtual memory subtotal − real memory total) +
|
The OpenSSP memory worksheet ( TABLE B-1 ) is used to size virtual and real memory for a SSP workstation or server, based on the number of Sun Enterprise 10000 domains controlled by the SSP and the number of SSP, Sun Management Center, and third-party applications involved.
This section provides details on how the predetermined memory values in the worksheet are derived. The pmap command provides output that is used to calculate the following memory values in the worksheet.
Process private resident memory
Process private virtual memory
System memory (line 1 of the worksheet)
Base SSP memory (line 2 of the worksheet)
Each domain SSP memory (line 3 of the worksheet)
Hostview memory (line 4 of the worksheet)
Sun Management Center memory (line 5 of the worksheet)
Kernel buffer memory (line 8 of the worksheet)
swapfs (line 10 of the worksheet)
The following sections describe how each of these values is calculated.
Use the pmap -x processID command to obtain the amount of private resident memory used by a process, where processID is the number of the process ID (for example, 406). In the output displayed, note the Private column in the last line. This value is the total private memory, in kilobytes, for a process that is resident in real memory.
To find the approximate amount of private virtual memory that a process uses, run the pmap -x processID command. In the output displayed, locate the total resident shared memory (shown on the last line under the Shared column) and subtract it from the total process memory (shown on the last line under the Kbytes column). The resulting value is the approximate total private virtual memory for a process. It is slightly higher than the actual amount needed, as it includes nonresident shared memory (paged-out memory that is also used by other processes). The resulting value is a reasonable measurement of the private virtual memory required, which does not underestimate the required memory.
For further information on memory sizing, see Richard McDougall's paper, "The Solaris Memory System: Sizing, Tools and Architecture," at http://www.Sun.COM/sun-on-net/performance/vmsizing.pdf
System memory usage consists of memory used by system processes, system shared libraries, CDE libraries, and CDE processes. TABLE B-2 shows the values for these items and the resulting totals for system memory: 60 MB of real memory and 60 MB of virtual memory. (The kernel buffer memory used is discussed in a subsequent section.)
Base SSP memory consists of memory used by the SSP shared libraries and SSP platform-wide processes. TABLE B-3 shows the subtotals for base SSP memory: 22 MB of real memory and 35 MB of virtual memory.
Each domain on the Sun Enterprise 10000 system requires three processes on the SSP:
Output from the pmap -x command shows that these three processes take 3 MB of private resident memory and 4 MB of private virtual memory.
Each instance of Hostview, with all three status subwindows open, requires four processes. The output from the pmap -x command shows that these four processes use 12 MB of private resident memory and 17 MB of private virtual memory. Hostview is not required for the SSP to function, but it is useful for monitoring alerts and events if no other monitoring software, such as Sun Management Center, is being used.
On the SSP, Sun Management Center requires two agents to send information back to the Sun Management Center server. One agent monitors the SSP workstation itself, while the other agent monitors the Sun Enterprise 10000 platform. Sun Management Center appears in the ps command as two processes, both named esd. TABLE B-4 presents the output from the pmap -x command for the Sun Management Center processes and the resulting subtotals for resident and virtual memory:
Due to the large footprint of the Sun Management Center server or console, running Sun Management Center on the same system with the SSP is not recommended. Sun Management Center is neither required nor used by SSP software.
The following quote from Richard McDougall's paper, The Solaris Memory System: Sizing, Tools and Architecture at:
http://www.Sun.COM/sun-on-net/performance/vmsizing.pdf
provides a general rule of thumb for determining kernel RAM.
The amount of memory that the kernel uses varies significantly, based on the size of the tunable parameters. A lot of the tunable parameters are set at boot in proportion with the amount of physical RAM in the system. As a general rule of thumb, if all of the parameters are standard, you can allow about 15% of physical RAM for the kernel.
The swapfs file system implements a file system in virtual memory, using both RAM and, if necessary, swap space, to store files. However, because this memory is not preserved across reboots, swapfs is used only for temporary files, usually /tmp/ . SSP automatic failover uses /tmp/ to propagate modified files to the other SSP in a dual configuration, mainly log files and recently changed configuration files, as part of the process of failing over to the other SSP. Be sure to allocate enough space for swapfs, as log files can become quite large. Otherwise, the SSP workstation might behave strangely or even fail. Allocating 512 MB of swap space for /tmp/ should be sufficient for SSP automatic failover. This amount is in addition to the amount of required virtual memory that exceeds available RAM.
If the system is generating a large number of diagnostic messages to the SSP logs, or the system is generating many log messages due to an error situation, monitor the SSP log file sizes under the /var/opt/SUNWssp/adm/ directory. If, in rare instances, log files in this directory grow to hundreds of megabytes in size, trim or remove them from the /var/opt/SUNWssp directory.
Copyright © 2002, Sun Microsystems, Inc. All rights reserved.