A P P E N D I X

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.

Blank OpenSSP Memory Worksheet

This section contains a blank SSP memory worksheet that you can use to determine the memory requirements for your SSP configuration.

TABLE B-1 Blank OpenSSP Memory Worksheet
Line	Item	Number	Real Memory (MB)	Virtual Memory (MB)	Real Memory Subtotal (MB)	Virtual Memory Subtotal (MB)
1	System	1	60	236	60	236
2	Base SSP	1	22	35	22	35
3	Domains (1-16)		3 x no. of domains	4 x no. of domains
4	Hostviews (0 or more)		12 x no. of hostviews	17 x no. of hostviews
5	Sun Management Center (0 or 1)		0 or 26	0 or 31
6	Third-party applications
7	Subtotal (lines 1 through 6)
8	Kernel buffer memory (MB)		15% of RAM
9	Recommended real memory (lines 7 and 8)
10	Reserved for `/tmp/` in `swapfs`			512		512
11	Subtract amount of real memory
12	Recommended swap space size			(Virtual memory subtotal − real memory total) + `/tmp/` reserved

How Memory Sizing Values are Derived

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.

Process Private Resident Memory

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.

Process Private Virtual 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 (Line 1)

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.)

TABLE B-2 System Memory Values
Memory	Resident Memory (MB)	Virtual Memory (MB)	Description
System processes	21	56	Use `pmap` `-x` to find the private resident and virtual memory of root processes, that is `/usr/lib/` , `/usr/sbin/` , `/usr/sadm/` , `rpc.` , and `mibiisa` .
System shared libraries	15	25	The total resident and virtual memory for system shared libraries, which are under `/usr/lib/` , is approximately 15 and 25 MB (see Richard McDougall's paper, "The Solaris Memory System: Sizing, Tools and Architecture," pp. 34-36 at `http://www.Sun.COM/sun-on-net/ performance/vmsizing.pdf` ).
CDE libraries	5	10	Use pmap -x to find the highest shared memory among `/usr/dt/bin/` and `/usr/openwin/bin/` processes.
CDE processes	19	145	Use `pmap` `-x` to find the private resident and virtual memory of `Xsun` , speckeysd, `fbconsole` , `sdt_shell` , `ttsession` , and `dt*` processes.
System subtotal	`60`	`236`

Base SSP Memory (Line 2)

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.

TABLE B-3 Base SSP Memory Values
Memory	Resident Memory (MB)	Virtual Memory (MB)	Description
SSP shared libraries	3	4	Sum the file sizes of the *.so files under `/opt/SUNWssp/lib/` and `/opt/SUNWssp/release/` This gives the approximate virtual memory used by the SSP libraries.
SSP platform software	19	31	Use `pmap` `-x` to find the private resident and shared memory of SSP platform-wide processes. That is, `snmpd` , (but not `snmpdx` ), `ssp_startup.*` , `fad` , edd, straps, `machine_server` , `fod` , `cbs` , and `datasyncd` .
SSP platform subtotal	`22`	`35`

Each Domain SSP Memory (Line 3)

Each domain on the Sun Enterprise 10000 system requires three processes on the SSP:

obp_helper
netcon_server
netcon client

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.

Hostview Memory (Line 4)

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.

Sun Management Center Memory (Line 5)

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:

TABLE B-4 Sun Management Center Memory Values
Memory	Resident Memory (MB)	Virtual Memory (MB)
Sun Management Center workstation agent	14	16
Sun Management Center platform agent	12	15
Sun Management Center subtotal	`26`	`31`

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.

Kernel Buffer Memory (Line 8)

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.

swapfs (Line 12)

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.