BMC Portal

Installation Notes

Version: 2.4

Kit name: BMC Performance Manager Infrastructure and Solutions

June 26, 2007

This document contains the following topics:

Introduction

Sizing your Environment

Portal scaling recommendations

Performance Manager scaling recommendations

Deployment and hardware recommendations

Small environment recommendations

Medium environment recommendations

Large environment recommendations

Portal and database tuning

Frequently Asked Questions

Worksheet

Where to get the latest product information

Introduction

BMC Software scalability laboratories performed tests on the BMC Performance Manager Portal version 2.4 to determine the recommended configurations for the supported operating systems and various sizes of implementation (number of monitored servers). This document contains the recommendations of BMC Software based on the results of those tests.

---

NOTE:

The recommendations stated in this document are conservative and are designed to give you high performance under all conditions. You may find that a less powerful hardware configuration or fewer Remote Service Monitors (RSMs) give you acceptable performance.

---

Sizing your Environment

1. Determine which Performance Managers you will use in your enterprise.

2. Estimate how many monitored entities (managed nodes, application instances, web servers, databases, and so forth) you will monitor.

3. Based on the Performance Managers that you will use and the number of monitored entities in your environment, estimate the total number of parameters in your enterprise.

4. Determine the Portal size required for your enterprise.

5. Determine the number of RSMs required for your enterprise.

To size your environment

This section walks you through each of these steps using a simple set of tables that show how the results from each step accumulate. The results for each step are identified in boldface.

You can use the Worksheet on page 19 to evaluate your own enterprise.

1. Determine which Performance Managers you will use in your enterprise.

This example will use the following Performance Managers:

BMC Performance Manager Integration with PATROL for UNIX and Linux

BMC Performance Manager Integration with PATROL for Microsoft Windows Servers

BMC Performance Manager Express for Lightweight Protocols - Ping

BMC Performance Manager Express for Servers - Microsoft Windows

2. Estimate the number of monitored entities.

Estimating the number of monitored entities involves taking the number of managed nodes (elements) for the target enterprise and determining which Performance Managers will be used to monitor those systems and in what quantities.

The following table shows the number of each Performance Manager for this example. Note that these tables group the Performance Managers into one of two categories based on whether they appear in Table 2 on page 7 or Table 3 on page 9. This separation will be used in the last step to estimate the number of RSMs.

BMC Performance Manager…	Elements	Parameters/ element	Parameter estimates	RSM estimates
Performance Managers constrained by parameter counts
Integration with PATROL for UNIX and Linux	100
Integration with PATROL for Microsoft Windows Servers	150
for Lightweight Protocols—PING	1,000
Subtotal	1,250
Performance Managers constrained by other factors
Express for Servers—Windows	300
Subtotal	300
Summary Results
Total Portal Parameters
Total Portal Elements	1,550
Portal Size
Total RSMs

In this example, none of the selected Performance Managers will be deployed together on the same element. If you have a scenario where two or more Performance Managers are deployed on the same monitoring element (for instance an OS and database Performance Manager) then record the element counts for both, but only include the element counts for one in the sum for Total Portal Elements.

3. Estimate the total number of parameters in your enterprise.

To estimate the total number of parameters in your enterprise, determine the total parameters for each type of the Performance Manager you plan on deploying and add them all together. To determine the total parameters for each type of Performance Manager, refer to Table 2 on page 7 and Table 3 on page 9 for estimates of the parameters per element for each kind of Performance Manager.

For illustration purposes, assume that the machines monitored by PATROL for Microsoft Windows Servers have less than the typical workload predicted by the assumptions in Table 2. Specifically, assume that these machines will do no process monitoring and only half as much log monitoring as defined by the “Expected values” in Table 2. Using the information in the “Baseline” and “Additional parameters” columns from Table 2, the revised number of expected parameters is calculated this way:

No process monitoring means 10 ¥ 17 = 170 fewer parameters.

Half as much log monitoring works out to 5 ¥ 10 = 50 fewer parameters.

So the expected number of parameters for each of these elements is 880 - 170 - 50 = 660.

The following table shows parameter estimates and totals for each Performance Manager for this example:

BMC Performance Manager…	Elements	Parameters/ element	Parameter estimates	RSM estimates
Performance Managers constrained by parameter counts
Integration with PATROL for UNIX and Linux	100	540	54,000
Integration with PATROL for Microsoft Windows Servers	150	660	99,000
for Lightweight Protocols—PING	1,000	5	5,000
Subtotal	1,250		158,000
Performance Managers constrained by other factors
Express for Servers—Windows	300	400	120,000
Subtotal	300		120,000
Summary Results
Total Portal Parameters	278,000
Total Portal Elements	1,550
Portal Size
Total RSMs

As illustrated by this example, the number of parameters for a particular Performance Manager can vary from the expected values in Tables 2 and 3 depending on the size of the target application on the managed node and how much you choose to monitor (for example, 10 log files generate 10 times more parameters than 1 log file for the same number of rules).

The expected values in Tables 2 and 3 are based on fairly conservative estimates of how a typical server might be configured. The actual values for your particular managed nodes may be higher or lower.

Refer to "Performance Manager scaling recommendations" for information on how to adjust your estimates for each Performance Manager.

4. Determine the Portal size required for your enterprise.

The Portal hardware requirements and the basic deployment model of Portal server components (webserver, appserver, and datastore) are divided into three categories based on the expected size of the implementation as measured by total parameters: Small, Medium and Large. These sizes are defined in Table 1 on page 6.

To look up values in Table 1, review the mix of Performance Managers selected in step 1. on page 2 to determine whether your deployment is primarily based on Remote Monitoring, PATROL Integration, or a mix of both.

This example has a mix, so comparing the Total Portal Parameters computed above (278,000) with the data in the 50%–50% row of Table 1, you can see that this example requires a medium Portal deployment.

"Deployment and hardware recommendations" contains details on the number machines and hardware requirements for each of the three deployment sizes.

5. Determine the number of RSMs required for your enterprise.

The last step involves determining the number of RSMs for your enterprise. The sizing of RSMs must take into account the fact that not all Performance Managers impact RSM or Portal scalability in the same way.

For Performance Managers that are constrained by parameter counts, you can assume that a single RSM can accommodate approximately 100,000 parameters. Divide the subtotal of parameters for that type of Performance Managers by 100,000 and round up the result to get the number of RSMS required for those Performance Managers.

For Performance Managers that have other constraints, consult Table 3 on page 9 for the specific constraints for each Performance Manager that you are using, and record the results. In this example, Performance Manager Express for Servers - Windows can support no more than 200 elements on a single RSM, so 300 of those elements will require at least 2 RSMs.

The complete results for this example are illustrated in the following table:

BMC Performance Manager…	Elements	Parameters/ element	Parameter estimates	RSM estimates
Performance Managers constrained by parameter counts
Integration with PATROL for UNIX and Linux	100	540	54,000
Integration with PATROL for Microsoft Windows Servers	150	660	99,000
for Lightweight Protocols—PING	1,000	5	5,000
Subtotal	1,250		158,000	1.58
Performance Managers constrained by other factors
Express for Servers—Windows	300	400	120,000	1.5
Subtotal	300		120,000	1.5
Summary Results
Total Portal Parameters	278,000
Total Portal Elements	1,550
Portal Size	Medium
Total RSMs	3.08

In this example, 3 RSMs will probably suffice because the fractional RSM values are so close to an even number. However, no additional capacity would be available for more servers or additional workload in the cases where the estimated parameter counts were below those observed in the actual managed environment. A more conservative planner might choose 4 RSMs.

Portal scaling recommendations

This section summarizes the recommendations of this series of tests. Details of the environments and results are given in later sections.

Table 1 lists the recommended maximum numbers of parameters for various combinations of remote monitoring and PATROL integration.

The “Remote monitoring” column lists the percentage of parameters that are populated by remote monitoring.

The “PATROL Integration” column lists the percentage of parameters that are populated by PATROL Integration (that is, obtaining data from PATROL Knowledge Modules).

Table 1 General scalability recommendations—maximum number of parameters 

Portal platform	Remote monitoring	PATROL Integration	BMC Performance Manager Portal environment size
			Small	Medium	Large
Windows	100 %	0	123,000	400,000	925,000
	50 %	50 %	82,000	360,000	720,000
	0	100 %	54,000	240,000	640,000
Solaris	100 %	0		320,000	640,000
	50 %	50 %		300,000	600,000
	0	100 %		276,000	416,000

---

NOTE:

To achieve similar results, BMC Portal components must be the only processes generating significant workload on the BMC Portal host computer or computers.

---

Performance Manager scaling recommendations

The tables in this section list the scaling recommendations for individual Performance Managers.

Table 2 lists Performance Managers that are constrained by the number of parameters.

Table 3 on page 9 lists Performance Managers that are constrained by application behavior and system resources.

The “Expected number of parameters per element” column is the typical number of parameters that the Performance Manager instantiates for a single element.

The “Maximum per RSM” column in Table 3 on page 9 is the maximum workload that one RSM can handle for a single Performance Manager. The maximum number of elements must be reduced when multiple Performance Managers are loaded in the Portal.

The “Baseline” column lists any assumptions or conditions that determined the expected number of parameters.

The “Additional Parameters” column contains an estimate of how many additional parameters will be instantiated when monitoring additional entities.

These recommendations are based on default collection and reporting intervals. Reducing the collection interval increases workload and reduces the maximum number of parameters and elements that the RSM and BMC Portal can monitor.

Table 2 Performance Manager scaling recommendations (part 1 of 3)

BMC Performance Manager…	Version	Expected number of parameters	Baseline	Additional Parameters
Express for Lightweight Protocols—Internet Protocols	2.3.00	60
Express for Mail Servers	2.3.00	110
Express for SNMP Devices	2.3.00	660	60 interfaces	11 parameters per interface
Express for Web Application Servers—Apache or IIS	2.3.00	20
Express for Web Servers—Apache	2.3.00	20
Express for Web Servers—IIS	2.3.00	60
Express for Web Transactions	2.3.00	60
for Lightweight Protocols—Domain Name Server	2.4.00	5
for Lightweight Protocols—PING	2.4.00	5
for Lightweight Protocols—Port Monitor	2.4.00	5
Integration with PATROL for DB2 Universal Database	6.6.30	80
Integration with PATROL for HP Insight Manager	1.6.00	50
Integration with PATROL for Informix	9.3.10	100
Integration with PATROL for iSeries	3.6.00	80
Integration with PATROL for Lotus Domino	4.6.10	480
Integration with PATROL for Microsoft Exchange Servers	5.1.00	450	30 cluster resources 5 storage groups 5 public folders 5 private folders 15 queues 3 client roundtrip sessions 5 internet roundtrip sessions 5 server roundtrip sessions 10 watch users 2 SMTP servers, 4 instances o MSEXCH_Sent_Mail	add 1 parameter per cluster resource 1 per storage group 7 per public folder 7 per private folder 7 per queue instance 12 per client roundtrip session 4 per internet roundtrip session 4 per server roundtrip session 10 per watch user 3 per SMTP server 4 per instance of MSEXCH_Sent_Mail
Integration with PATROL for Microsoft SQL Server	4.2.30	40
Integration with PATROL for Microsoft Windows Servers	3.2.30	880	based on OS and 12 disks, 12 file systems, 10 processes, 3 event logs, and 10 log files	add 6 parameters per file system, 2 per disk, 17 per process, 10 per log file, and 141 per event log
Integration with PATROL for OpenVMS	2.7.01	450
Integration with PATROL for Oracle	8.8.20	50
Integration with PATROL for PeopleSoft	2.0.05	110
Integration with PATROL for SAP Enterprise Portal and SAP J2EE Engine	1.0.50	330	10 nodes (dispatcher or server)	30 parameters for each additional dispatcher or server
Integration with PATROL for SAP Solutions Suite	5.0.00	300	monitoring 20 filters and 5 SLG	add 5 parameters per filter and 40 per SLG
Integration with PATROL for Siebel eBusiness Applications	3.6.01	40
Integration with PATROL for Sybase	10.4.20	40
Integration with PATROL for UNIX and Linux	9.4.00	540	based on OS and 10 disks, 40 file systems, 20 processes, and 10 log files	add 5 parameters per file system, 2 per disk, 4 per process, and 10 per log file
Integration with PATROL for webMethods	2.2.10	100
Integration with PATROL Internet Server Manager	6.2.40	100

Table 3 Performance Manager scaling recommendations (part 1 of 2)

BMC Performance Manager…	Version	Expected number of parameters	Maximum per RSM	Baseline	Additional Parameters
Express for Databases— Oracle	2.4.00	840	100	1 instance with 200 tablespaces	25 per instance, 4 per tablespace
Express for Databases—DB2 UDB	2.4.00	16,300	35	2 databases, 10 partition, and 200 tablespace	2 parameters per database, 13 per partition, and (4¥number of partitions) per tablespace
Express for Databases—Microsoft SQL Server	2.4.00	1970	200	20 databases and 20 filegroups	8 per database, 4 per filegroup
Express for Databases—Sybase	2.4.00	300	100	20 databases, 3 data cache, and 50 devices	8 per database, 2 per data cache, and 2 per device
Express for Servers—UNIX/Linux	2.4.00	70	400	running OS monitoring with only 10 disks and 20 file systems	add 5 parameters per file system and 3 per disk
		370	60	running log management and the OS as above with 10 processes and 2 text logs with 5 rules each	add 10 parameters per text log
Express for Servers—Windows	2.4.00	400	200	running OS with 25 processes, 6 disk and file systems, and 3 event logs	add 2 parameters per disk, 4 per file system, and 23 per event log
for Citrix Presentation Server	2.3.00	270	5	20 servers with 20 applications per server	12 parameters per server, 3 parameters per application
for SAP	2.1.10	265	20	5 R/3 Application servers, 3 J2EE instances, 10 nodes (dispatcher or server)	35 per R/3 Application server, 6 for each J2EE instances, 2 nodes (dispatcher or server)
for Virtual Servers	2.4.00	1,700	1	1 element with 1 Virtual Center with 20 ESX Servers, 10 VMs per ESX Server, and TBD resource pools and TBD clusters	add 72 parameters per VM, 49 per ESX Server, 9 per resource pool, and 17 per cluster
Integration with PATROL for Virtual Servers	2.0.00	1,700	1	1 element with 1 Virtual Center with 20 ESX Servers and 10 VMs per ESX Server	add 72 parameters per VM and 49 per ESX Server
Integration with PATROL for WebSphere MQ	4.5.00	3,400	30	1 queue manager with 400 monitored queues and channels	8 parameters per additional monitored queue and channel

Deployment and hardware recommendations

BMC Software recommends that you use the hardware configurations given in the following sections for the size category that your enterprise fits into.

Small environment recommendations

Figure 1 and Table 4 describe the hardware platform used for small Windows environments. In this case, all components of the BMC Portal and RSM are installed on one host computer.

(Solaris cannot be used in a small environment configuration, because the RSM is supported only on Windows.)

Figure 1 Small environment architecture

Table 4 Computer used for application server, web server, datastore, and RSM 

Component	Recommendation
processor	2 CPU 3.2 GHz Pentium 4 or better
memory	4 GB or more
disk subsystem	any
disk space	200 GB or more available
operating system	Microsoft Windows Server 2003 Enterprise Edition SP1

Medium environment recommendations

Figure 2 and Table 5 through Table 7 on page 13 describe the hardware platforms used for medium-sized environments. In this case, multiple computers are used:

web server and application server on one computer

datastore on one computer

approximately 3 RSMs on separate computers, depending upon parameter count

Figure 2 Medium environment architecture

Table 5 Computer for application server and web server—medium environment 

Component	Recommendation
	Windows	Solaris
processor	2 CPU 3.2 GHz Pentium 4 or better	2 CPU 1.28 GHz UltraSPARC IIIi or better
memory	4 GB or more	4 GB or more
disk type	any
disk capacity	5 GB or more available
operating system	Microsoft Windows Server 2003 Enterprise Edition SP1	Solaris 10 (or 9)

Table 6 Computer for datastore—medium environment (part 1 of 2)

Component	Recommendation
	Windows	Solaris
processor	2 CPU 3.2 GHz Pentium 4 or better	2 CPU 1.28 GHz UltraSPARC IIIi or better
memory	4 GB or more	4 GB or more
disk type	any RAID
disk capacity	350 GB or more available
operating system	Microsoft Windows Server 2003 Enterprise Edition SP1	Solaris 10 (or 9)

Table 7 describes the recommended hardware platform for each RSM that is installed on a dedicated computer. The computer must use the Windows operating system.

Table 7 Recommended computer for RSM 

Component	Recommendation
processor	2 CPU 3.2 GHz Pentium 4 or better
memory	2 GB or more
disk subsystem	any
disk space	500 MB or more available
operating system	Microsoft Windows Server 2003 Enterprise Edition SP1

Large environment recommendations

Figure 3 and Table 8 on page 14 through Table 10 on page 14 describe the hardware platform used for large environments. In this case, multiple computers are used:

web server and application server on one computer

datastore on one computer

approximately 5 RSMs on separate computers, depending upon parameter count

Figure 3 Large environment architecture

Table 8 Computer for application server and web server—large environment 

Component	Recommendation
	Windows	Solaris
processor	2 CPU 3.2 GHz Pentium 4 or better	2 CPU 1 GHz UltraSPARC T1 4 Core or better
memory	4 GB or more	4 GB or more
disk type	any
disk capacity	5 GB or more available
operating system	Microsoft Windows Server 2003 Enterprise Edition SP1	Sun Solaris 10 (or 9)

Table 9 Computer for datastore server—large environment 

Component	Recommendation
	Windows	Solaris
processor	2 CPU 3.2 GHz Pentium 4 or better	4 CPU 1 GHz UltraSPARC T1 4 Core or better
memory	4 GB or more	8 GB or more
disk type	SAN array with Ultra 320 10K RPM drives or better
disk capacity	550 GB or more available
operating system	Microsoft Windows Server 2003 Enterprise Edition SP1	Sun Solaris 10 (or 9)

Table 10 describes the recommended hardware platform for each RSM that is installed on a dedicated computer. The computer must use the Windows operating system.

Table 10 Recommended computer for RSM 

Component	Recommendation
processor	2 CPU 3.2 GHz Pentium 4 or better
memory	2 GB
disk subsystem	any
disk space	500 MB available
operating system	Microsoft Windows Server 2003 Enterprise Edition SP1

Portal and database tuning

BMC Software recommends tuning the Portal and database for optimum performance. You can use tools supplied by BMC software to change product memory and Oracle configuration settings.

The procedure for changing Portal Java settings is in the section “Using the installation utility to maintain the Portal” Appendix B of BMC Performance Manager Portal Getting Started.

To modify datastore settings, run the program DatastoreInstallationTools.cmd or DatastoreInstallationTools.sh that is located in the product installation directory. Select the Datastore Maintenance tab, and then the System tab to change system settings. Redo log file size is on the Redo Logs tab.

For more information about these utilities, see Appendix B of BMC Performance Manager Portal Getting Started.

For Solaris medium and large environments, use of direct I/O is recommended where possible. For information on how to enable direct I/O, see the section on “Enabling direct I/O for a datastore installation on Solaris computers” in the BMC Portal Installation Guide.

Table 11 lists optimum settings for the small environment:

Table 11 Small environment server settings 

Component	Setting or attribute	Default value	Recommended value
Portal	WRAPPER.JAVA.MAXMEMORY	512 MB	Windows: 1,536 MB Solaris: 3 GB
Datastore	PGA_AGGREGATE_TARGET	0	400 MB
	Automated Memory Management SGA_TARGET	0	600 MB
	SGA_MAX_SIZE	0	600 MB
	redo logs	500 MB	3 redo log groups to have a single member each at 2 GB
	OPTIMIZER_DYMANIC_SAMPLING	2	5
	DB_CACHE_SIZE	48 MB	0
	SESSION_CACHED_CURSORS	30	75
	SHARED_POOL_SIZE	32-bit: 8 MB 64-bit: 64 MB	0 a

a When SGA_TARGET is set to a non-zero value and SHARED_POOL_SIZE is zero, Oracle dynamically allocates memory to the shared pool as needed.

Table 12 lists optimum settings for the medium environment:

Table 12 Medium environment server settings 

Component	Setting or attribute	Default value	Recommended value
Portal	WRAPPER.JAVA.MAXMEMORY	512 MB	Windows: 1,536 MB Solaris: 3 GB
Datastore	PGA_AGGREGATE_TARGET	0	400 MB
	Automated Memory Management SGA_TARGET	0	600 MB
	SGA_MAX_SIZE	0	600 MB
	redo logs	500 MB	3 redo log groups to have a single member each at 2 GB
	OPTIMIZER_DYMANIC_SAMPLING	2	5
	DB_CACHE_SIZE	48 MB	0
	SESSION_CACHED_CURSORS	30	75
	SHARED_POOL_SIZE	32-bit: 8 MB 64-bit: 64 MB	0 a

a When SGA_TARGET is set to a non-zero value and SHARED_POOL_SIZE is zero, Oracle dynamically allocates memory to the shared pool as needed.

Table 13 lists optimum settings for the server environment:

Table 13 Large environment server settings 

Component	Setting or attribute	Default value	Recommended value
Portal	WRAPPER.JAVA.MAXMEMORY	512 MB	1,536 MB
Datastore	PGA_AGGREGATE_TARGET	0	600 MB
	Automated Memory Management SGA_TARGET	0	2 GB
	SGA_MAX_SIZE	0	2 GB
	redo logs	500 MB	3 redo log groups to have a single member each at 5 GB
	OPTIMIZER_DYMANIC_SAMPLING	2	5
	SESSION_CACHED_CURSORS	30	75
	DB_CACHE_SIZE	48 MB	0
	SHARED_POOL_SIZE	32-bit: 8 MB 64-bit: 64 MB	0 a

a When SGA_TARGET is set to a non-zero value and SHARED_POOL_SIZE is zero, Oracle dynamically allocates memory to the shared pool as needed.

Frequently Asked Questions

Q. What is the impact on the scale estimates if Continuous Data Export (CDE) is used?

A. CDE is designed to put minimum impact on the portal. The CDE database should be an equivalent configuration to the portal database and will be able to maintain the required throughput.

Q. How will clustering of the web server, application server or RSM impact the scale estimates?

A. Clustering addresses continued operation in the event of a failure and not performance. The scale estimates produced by this document represent the minimum number of machines required to support a given workload. If you implement clustering, you will need additional machines. The estimates should be used to ensure that in the case of a failure that the remaining components will continue to operate.

Q. Can I deploy fewer RSM machines than the calculated results may suggest?

A. Yes. It may be possible to run with fewer RSMs than calculated in the worksheet. The recommendations are conservative estimations based on average numbers of elements and parameters.

The actual number of RSMs necessary for your environment may vary based on the actual hardware configuration, number of elements and parameters, and activity in your environment.

For a new installation, as you add managed servers, compare the actual parameter counts observed in your environment to the original estimates to adjust the RSM counts as necessary.

Q. Does having remote offices affect the number of RSM machines required?

A. Yes. Remote monitoring across a WAN is generally not recommended (though it is possible in limited situations). Therefore, you will likely need at least one RSM for each remote location. Keep the RSM estimating guidelines in mind so that the RSMs in each remote location can accommodate the Performance Managers you plan to run at those sites.

Q. Is the minimum RSM configuration required even if I am managing only a few systems in these locations?

A. No, if only a few systems are being monitored, the size of system required is reduced.