bppm best practices performance scalability

Best Practices for BMC ProactiveNet Performance Management Performance and ScalabilityVersion: 8.6July, 2011 (revision)

BMC Software has released version 8.6 of the BMC ProactiveNet product. This document provides information about optimizing performance and server sizing the BMC ProactiveNet in your environment. This information supplements and supersedes information in the product documents.

This document contains the following topics:

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Deployment Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Sizing a BMC ProactiveNet environment for data collection . . . . . . . . . . . . . . . . . . 4Additional guidelines for a data collection environment . . . . . . . . . . . . . . . . . . . . . 8Adapter data collection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Hardware requirements for BMC ProactiveNet server . . . . . . . . . . . . . . . . . . . . . . 12Hardware requirements for Business Objects reporting . . . . . . . . . . . . . . . . . . . . . 13Hardware requirements for Remote Agent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Hardware requirements for Oracle Database Server . . . . . . . . . . . . . . . . . . . . . . . . 14Oracle Database tuning recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Data management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Data management sizing recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Data management sizing chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Data management tuning recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21BMC ProactiveNet Server Bandwidth Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . 23Time consumed by different functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Event management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Event management sizing recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Event management sizing chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Event management tuning recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

NOTE Details about recent patches or PTFs for this product are available from the BMC Software Customer Support website at http://www.bmc.com/support_home. Before installation, BMC Software recommends that you check the website to determine whether patches are available for this product.

*204678**204678*

*204678*

http://www.bmc.com/support_home

Time consumed by different functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Impact Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Impact Management sizing recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Impact Management sizing chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Impact Management tuning recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Time consumed by different functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Recommended AR configuration settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Recommended AR System Mid-Tier configuration settings . . . . . . . . . . . . . . . . . 42Recommended AR Application Server configuration settings. . . . . . . . . . . . . . . . 47

Hybrid management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Hybrid management sizing recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Hybrid management sizing chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Hybrid management tuning recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Cloud management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Cloud management sizing recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Cloud Management hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Hardware requirements for Servers in Cloud Management . . . . . . . . . . . . . . . . . 62Cloud Management sizing chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Virtual Center details used for monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Reports Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Event Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Impact Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Component performance and tuning recommendations. . . . . . . . . . . . . . . . . . . . . . . . 70Disk subsystems and database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70CPU guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Configuration and deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Tested environment for concurrent users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Frequently asked questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Where to view the latest product information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6 2

Introduction

IntroductionBMC Software has released version 8.6 of the BMC ProactiveNet product. This document contains guidelines and recommendations to help you size an environment and identify the appropriate architecture and hardware for BMC ProactiveNet deployments.

All information provided is based on controlled, internal testing of BMC ProactiveNet version 8.6 to ensure optimum performance.

In general, the performance of a single BMC ProactiveNet server depends on several variables. Substantial changes in any of these variables could change the expected scaling and performance numbers. Those variables are:

■ The size of the server.

■ The type of devices monitored.

■ The number of adapters and monitors on each agent.

■ The polling frequency.

■ The number of concurrent users.

■ The number of external events per day.

■ The number of alarms and abnormalities per day.

NOTE Do not use 32-bit hardware to deploy BMC ProactiveNet server. BMC strongly recommends using 64-bit hardware to deploy BMC ProactiveNet server. If you are an upgrade user and using 32-bit hardware, BMC strongly recommends upgrading to 64-bit hardware. No performance or scalability testing is performed on 32-bit hardware.


Deployment Configuration Guidelines

Deployment Configuration GuidelinesThis section uses example scenarios of a BMC ProactiveNet environment that provides only data collection (that is, an environment that does not include external event management), to provide the hardware configurations as recommended by BMC Software.

For data collection and analytics, the system used to operate BMC ProactiveNet requires sufficient memory for the analytical engine component to perform all of the tasks quickly. Most data that it uses is cached in memory so that baseline and abnormality generation on monitored attribute in the system can be done behind the scenes.

Sizing a BMC ProactiveNet environment for data collection

This section guides you through these procedures and provides sample scenarios and guidelines for:

■ Sizing using BMC PATROL Performance Manager

■ Determining the BMC ProactiveNet architecture size required for your environment

■ Determining the number of BMC ProactiveNet Agents and Servers required for your environment

WARNING BMC ProactiveNet can use the Sybase database or Oracle database in any deployment.

■ The embedded database (Sybase Adaptive Server Anywhere or Sybase ASA) that must run on the same system as the core server components. The embedded database is optimized for BMC ProactiveNet.

■ The Oracle database must be installed in different systems with the same subnet network.

NOTE Open the BMC Administration Console or Operations Console on a system different from the system on which the BMC ProactiveNet Server is running. Both these systems must be running on the same network.



Sizing using BMC PATROL Performance Manager

The following sample scenario shows you how to size your environment for data collection.

Sample Scenario

Determine the system to monitor

Determine what you want to monitor in your environment, and then select the applicable Performance Managers. This scenario monitors the following systems using the following Performance Managers:

■ PATROL for UNIX and Linux

■ PATROL for Microsoft Windows Servers

Estimate the total number of monitor instances

Estimate the number of monitored types by counting the number of managed nodes for the target environment and determining which BMC Performance Managers are required to monitor those managed nodes and in what quantities.

This scenario uses the following number of monitor instances per BMC Performance Manager:

■ PATROL for UNIX and Linux: 7000

■ PATROL for Microsoft Windows Servers: 5300

Calculate the total number of attributes

To estimate the total number of attributes in your enterprise, determine the total number of attributes for each monitor type that you plan to deploy and total them.

Determine the total number of attributes for each monitor type or Performance Manager.

The following table uses the number of monitor instances and the number of estimated attributes per monitor type or Performance Manager to calculate the estimated number of attributes.



Determining the BMC ProactiveNet architecture size required for your environment

Deployments of BMC ProactiveNet are categorized, based on their total attributes, as small, medium, or large. For information about the number of computers and hardware requirements for each deployment size, see “Hardware requirements” on page 12.

Some additional variables can affect the size of the architecture. By default, the average polling rate is 5 minutes. For example, an average polling rate of 2 minutes for all monitors could double the attribute estimates. These variables are listed as special considerations in “Deployment Configuration Guidelines” on page 4.

If you have an environment that performs external event management, with or without data collection, the architecture size is affected. For external event management recommendations see “Event management sizing recommendations” on page 26, and “Hybrid management sizing recommendations” on page 51.

Determining the number of BMC ProactiveNet Agents and Servers required for your environment

In this last step, you determine the number of BMC ProactiveNet remote agents for your environment. In this scenario BMC PATROL Adapters are used, this step is simplified a little. All monitors and attributes that are collected through an adapter have basically the same level of impact on any given agent and server.

With BMC PATROL Adapters, a single 32-bit BMC ProactiveNet Agent can accommodate up to 125,000 attributes. There are many other variables that come into play that can lower or raise this limit (for example, poll frequency and hardware). A single 64-bit BMC ProactiveNet Agent for BMC PATROL Adapter can collect data for more than 125,000 attributes based on the memory (maxheap) allocated to this agent.

Table 1 The total number of attributes in sample scenario 1 using BMC PATROL for data collection

BMC Performance Managers InstancesAttributes per

deviceEstimated attributes

PATROL for UNIX and Linux 7000 75 220,000

PATROL for Microsoft Windows 5300 180 580,000

Totals 12,300 255 800,000



Table 4 on page 8 summarizes the recommendation for 64-bit BMC ProactiveNet Agent. To estimate the number of 32-bit BMC ProactiveNet Agents required (for 5 minutes stats polling), divide the total number of attributes by 125,000 (and round up). To estimate the number of 64-bit BMC ProactiveNet Agents required (for 2 or 5 minutes stats polling), divide the total number of attributes by 800,000 (and round up). The assumption here is each agent has 8 GB RAM for it.

BMC ProactiveNet Server scaling recommendations

Table 2 lists the sizing constraints for a BMC ProactiveNet Server performing data collection on Windows or Solaris platforms, based on the total number of attributes monitored. The maximum capacity ranges mentioned below were determined partly by lab measurement and partly by usage data from enterprise class, customer environments.

BMC ProactiveNet Agent scaling recommendations

Table 3 lists the sizing constraints for a BMC ProactiveNet Agent based on the total number of attributes collected. See also “Deployment Configuration Guidelines” on page 4 and the considerations that provide context for deploying adapters and monitors on ProactiveNet Agents.

Platform: Windows 2008 R2 (32-bit or 64-bit), Intel Core i7, 2 Core, 2 GB RAM, 3.067 GHz Frequency, 2400 MHz Bus-speed

Table 2 Recommendations on the number of attributes per BMC ProactiveNet Server for data collection with a polling rate of 5 minutes

ArchitectureAttributes monitored

Events per day CPU Memory Hard Drive

Small 50 K or less 2 K or less 2 8 GB 100 GB

Medium 50 K–400 K 2 K–5 K 4 16 GB 200 GB

Large 400 K-800 K 10 K 8 32 GB 300 GB

Table 3 Recommendations on the number of attributes per 32-bit BMC ProactiveNet Agent

Monitor type

BMC PATROL Adapter

BMC Adapter

VMWare Adapter

TM-ARTAdapter

Number of attributes

(Polling Interval: 5 minutes stats poll and 15 minutes auto-sync)

125,000 125,000 50,000 45,000


Additional guidelines for a data collection environment

Platform: Windows 2008 R2 (64-bit), Intel Core i7, 2 Core, 2 GB RAM, 3.067 GHz Frequency, 2400 MHz Bus-speed

The limits shown above can be used for rough estimates but do not necessarily give all the information required for sizing. You must also consider all the factors, for example:

■ network topology■ security


This section provides further guidelines that you should consider when deploying a BMC ProactiveNet data collection environment.

BMC ProactiveNet Agent and Server considerations

Sizing limits

The number of monitors and attributes a BMC ProactiveNet Agent or Server can handle is limited. See “BMC ProactiveNet Server scaling recommendations” on page 7.

Table 4 Recommendations on the number of attributes per 64-bit BMC ProactiveNet Agent

Monitor type Number of attributes Polling interval Monitor instance

BMC PATROL Adapter 800,000 5 minutes stats poll 15 minutes auto-sync)

90 K to 100 K

NOTE The 800,000 attributes monitored through PATROL Agents were from static KMs and with KPI mode.

WARNING If you reduce the polling interval to less than the recommended values, it may put heavy load on the CPUs of the BMC ProactiveNet servers. It may also result in restarting the remote BMC ProactiveNet Agent several times.



Distributed locations

Independent of the limits of a BMC ProactiveNet Agent, the environment can require that you install a BMC ProactiveNet Agent on a separate machine. For example, it is best to install a BMC ProactiveNet Agent on every remote network where you are collecting data.

N-1 agent to hardware consolidation

If more than one BMC ProactiveNet Agent is required, you can install multiple BMC ProactiveNet Agents on one computer rather than allocating a separate computer for each. As a general guideline, you should add additional resources as per the proxy agent, 1 CPU and 2 GB of memory for each additional agent installed on a computer.

BMC ProactiveNet Agent proxy

Using a BMC ProactiveNet Agent proxy minimizes the number of connections between two different networks. It allows multiple BMC ProactiveNet Agents to talk to the server through a designated proxy. The BMC ProactiveNet Agent proxy can talk to the BMC ProactiveNet Server over standard TCP/IP (with SSL). This setup requires only one open port between the server and the BMC ProactiveNet Agent proxy.

Figure 1 BMC ProactiveNet Agent proxy architecture


Adapter data collection


This section provides the considerations that you should take into account when using the following adapters in your environment

■ BMC PATROL Adapters

■ BMC TM ART Adapters

BMC PATROL Adapters

The BMC PATROL Adapter uses a component called the Integration Service for PATROL that is installed as part of the BMC ProactiveNet Remote Agent (for very small environments, you can install it locally, on the server).

■ The proxy can send data from multiple PATROL Agents to BMC ProactiveNet.

■ Integration Service for PATROL is deployed on all the BMC ProactiveNet Agents. The adapters must be created on these agents.

■ In a large environment multiple BMC ProactiveNet agents will be collecting data through 1 or more Integration Service for PATROL. It is recommended that Integration Service for PATROL be deployed in at least each different network where PATROL agents are located. It is also recommended to distribute PATROL agents on Integration Service for PATROL so that the load on the agents is not more than the suggested numbers.

■ The BMC ProactiveNet Agent and Server connection can cross network boundaries because the BMC ProactiveNet Agent and Server connection supports more flexible connection options currently (TCP/IP, SSL, HTTP/S) than the proxy.

■ Integration Service for PATROL is highly scalable.

■ A single Integration Service for PATROL can collect data from 1000 PATROL Agents.

■ Data collection was successful in BMC ProactiveNet environment with 1000 PATROL Agents and each agent collecting approximately 850 attributes. In this scenario, the Integration Service for PATROL was deployed with a dedicated 64-bit BMC ProactiveNet agent.

■ Minimize the number of Integration Service for PATROL that are used to collect data from PATROL agents. This can be accomplished by using 64-bit BMC ProactiveNet agent that has good hardware configuration (16 GB RAM and 8 CPU).

■ To configure automated workflow, see the BMC ProactiveNet Administrator Guide.

■ Use the following guidelines when using Integration Service for PATROL:



■ Do not exceed 800 K attributes per Integration Service for PATROL while using 64-bit BMC ProactiveNet agent.

■ Allocate a separate Integration Service for PATROL to each remote network.

■ For administration purpose the client computer (that runs administrations) should have access to the Integration Service for PATROL.

If the BMC ProactiveNet Agent that is running and controlling the Integration Service for PATROL is dedicated, it is easier to manage and size. However, it does not have to be dedicated in all cases. As an example, if BMC PATROL agents in a different network are collecting only 40,000 attributes, it is possible to use a single BMC ProactiveNet Agent to run both the adapter and the Integration Service for PATROL (as opposed to having two BMC ProactiveNet Agents located on two different hosts in the remote network).

Figure 2 BMC PATROL Adapter environment

BMC TM ART Adapters

Using the BMC TM ART integration to pull data from BMC TM ART central can have a slight impact on the BMC TM ART application. The integration uses the TM ART servlet API to pull data, which can impact performance. BMC recommends that you implement the transactions that are pulled into BMC ProactiveNet system using a phased approach so that you can observe both systems after each block of transactions is created.

Keep the BMC ProactiveNet Agents that run the BMC TM ART transaction monitors close to the BMC TM ART central server. When the BMC ProactiveNet Agent and BMC TM ART server are in different networks, latency problems occur and the scaling estimates are impaired.


Hardware requirements

Hardware requirements

Hardware requirements for BMC ProactiveNet server

This section provides a summary of hardware requirements for BMC ProactiveNet server, to consider when determining the size of your environment for data management, event management, hybrid management (data collection and event management), and impact management.

WARNING Do not use 32-bit hardware to deploy BMC ProactiveNet server. BMC strongly recommends using 64-bit hardware to deploy BMC ProactiveNet server. If you are an upgrade user and using 32-bit hardware, BMC strongly recommends upgrading to 64-bit hardware. No performance or scalability testing is performed on a 32-bit hardware.

Table 5 Hardware requirements for BMC ProactiveNet server in small, medium and large environments (part 1 of 2)

Data Management

Event Management

HybridManagement

Impact Management

SMALL ENVIRONMENT

Operating system

■ Windows 2008 R2 (64-bit), Intel Core i7, 2x4 Core, 3.067 GHz Frequency, 2400 MHz Bus-speed and 16 threads or equivalent

■ SPARC Enterprise T-Series OR M-Series Servers, 2x4 Core, 3 GHz, UltraSPARC T2 and 32 threads or more

RAM 8 GB 4 GB 8 GB 8 GB

Storage configuration

10 K SAS disk or SAN storage




MEDIUM ENVIRONMENT

Operating system









LARGE ENVIRONMENT


Hardware requirements for Business Objects reporting

Hardware requirements for Business Objects reporting

This section provides a summary of hardware requirements for Business Objects reporting, to consider when determining the size of your environment for event reporting, and impact reporting.

Operating system





■ Tier 1 SAN storage (2-4 Gbps SAN dedicated channel)

Table 6 Hardware requirements for Business Objects and Report Engine

Business Objects Report Engine

Operating system ■ Windows 2008 R2 (64-bit), Intel Core i7, 2x4 Core, 3.067 GHz Frequency, 2400 MHz Bus-speed and 16 threads or equivalent

RAM 4 GB 4 GB

Storage configuration 80 GB 40 GB

Oracle Database ■ Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production

Table 5 Hardware requirements for BMC ProactiveNet server in small, medium and large environments (part 2 of 2)

Data Management

Event Management

HybridManagement

Impact Management


Hardware requirements for Remote Agent

Hardware requirements for Remote Agent

Table 7 provides a summary of hardware requirements for Remote Agent, to consider when determining the size of your environment for data management, and hybrid management.

Hardware requirements for Oracle Database Server

This section provides a summary of the hardware requirements for Oracle Database server, to consider when determining the size of your environment for data management, event management, hybrid management (data collection and event management), impact management and Business objects reporting.

Table 7 Hardware requirements for Remote Agent

Data ManagementHybrid

Management

SMALL ENVIRONMENT


RAM 4 GB 4 GB

Storage configuration 10 K SAS disk or SAN storage 10 K SAS disk or SAN storage

MEDIUM ENVIRONMENT


RAM 8 GB 8 GB


LARGE ENVIRONMENT


RAM 8 GB 8 GB



Hardware requirements for Oracle Database Server

Table 8 Hardware requirements for Oracle Server

Data Manage-

ment

Event Manage-

ment

HybridManage-

ment

Impact Manage-

ment

Business Objects

Reporting


RAM 16 GB 16 GB 16 GB 16 GB 16 GB


■ 200 GB, 10 K SAS disk or SAN storage

Oracle database ■ Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production


Oracle Database tuning recommendations


There are a number of BMC ProactiveNet properties and Oracle Database parameters that can be tuned to optimize performance. Table 9 provides the most common properties and changes that you should consider before installing BMC ProactiveNet.

Table 9 Tuning recommendations for Oracle Database (part 1 of 2)

Parameter Value / Command Description

Setting the number of processes and sessions

alter system set processes = 1000 scope=spfile;

alter system set sessions = 1000 scope=spfile;

You can set the number of processes and sessions to 1000.

Tun following commands on the database and restart the database.

Connect to the database as system or sys with ‘sysdba’ mode.

Setting the Sga_max_size

lter system set sga_max_size=0 scope=spfile

Reset sga_max_size to 0

Setting for Memory Allocation

alter system set memory_max_target=8192M scope=spfile

alter system set memory_target=8192M scope=spfile

Set memory to half of the system memory

Ex: If system as 16 GB of RAM then set to memory_max_target=8192M

Follow these steps to resize available REDO log files before BMC ProactiveNet installation start.

Setting of REDO01 alter database add logfile group Inactive group number ('Path\Redo Filename Without Group NumberInactive group number.LOG') size 500m reuse;

To avoid "cannot allocate new log," error

For status of redo log file

select group#, status from v$log;


To avoid "cannot allocate new log," Error






To avoid "cannot allocate new log," Error



Check status of redo log files:


alter system switch logfile;

alter system switch logfile;

Status of one redo log file should be CURRENT, and other two should be ACTIVE

set audit_trail

set scope

Alter system set audit_trail=none scope=spfile

Alter audit_trail and scope values

set CONNECT_TIMEOUT_LISTENER

CONNECT_TIMEOUT_LISTENER = 0’

Add CONNECT_TIMEOUT_LISTENER = 0’ in listener.ora file

Table 9 Tuning recommendations for Oracle Database (part 2 of 2)

Parameter Value / Command Description


Data management

Data managementBMC Knowledge Management (KM) collects data from different sources. Data management manages the data into features like dynamic base lining, intelligent thresholds, RCA, dynamic thresholds, prediction, and abnormality detection.

Data management sizing recommendations

The following section provides sizing recommendations for data management.

Small environment

A small BMC ProactiveNet data collection environment typically collects 50,000 or fewer attributes. In a very small environment, one that collects 25,000 or fewer attributes, you could use one server with a local agent acting as the data collector.

When planning a small environment, consider the following guidelines:

■ If you use the BMC PATROL Adapter, install the Integration Service for PATROL on the agent.

■ If you expect more than five concurrent users or if the average polling intervals are less than five minutes, use a medium architecture setup.

■ If you collect data across networks or firewalls, consider using a remote agent to minimize the number of connections to manage across networks and firewalls.

■ To improve I/O throughput, locate the operating system and database on separate disks, each with its own disk controllers.

Medium environment

A medium environment typically collects 50,000 to 400,000 attributes. Distributing the data collection to remote agents off-loads much of the performance to the collectors, and keeps the server dedicated to the primary server processes (analytical engine, object cache, and agent controller). The number of remote agent computers required depends on several factors, such as the total number of monitor instances extracted from the adapters, the topology of the network or location of firewalls (which can require proxy agents), and the size of the remote agent computers.

When planning a medium environment, consider the following guidelines:

■ An agent does not require a dedicated physical machine. You can install multiple agents on a remote computer as long as 1 CPU and 2 GB of memory are allocated for each agent installed.


Data management sizing recommendations

■ A 64-bit agent can handle a higher number of attributes.

■ You can deploy agents within a Virtual Machine (VM) as long as the VM meets the resource requirements.

■ If you expect the total number of attributes for the environment to grow beyond 400,000 attributes, use a large-environment deployment so that the system can accommodate growth smoothly.

■ If you use a BMC PATROL Adapter, install the Integration Service for PATROL on all the remote agents that are identified for creating the adapter.

■ The local data collection agent residing on the BMC ProactiveNet Server collects metrics about only BMC ProactiveNet performance.

■ BMC recommends that you tune the Java Virtual Machines (JVMs) as described in “Tested environment for concurrent users” on page 72.

Large environment

A large environment typically collects around 800,000 attributes. Distributing the data collection to remote agents off-loads much of the performance to the collectors so that the server can be dedicated to the primary server processes (analytical engine, object cache, and agent controller). The number of remote agent computers required depends on several factors, such as total number of monitor instances extracted from the adapters, the topology of the network or location of firewalls (which can require proxy agents), and the size of the remote agent computers.

When planning a large environment, consider the following guidelines:

■ Configure each BMC ProactiveNet server so that it contains an entire line of business, rather than spreading the monitoring from any line of business or application across servers.

■ An agent does not require a dedicated physical machine. You can install multiple agents on a remote computer as long as 1 CPU and 2 GB of memory are allocated for each agent.

■ A 64-bit agent can handle a higher number of attributes when sufficient memory is allocated.

■ You can deploy agents within a VM as long as the VM meets the resource requirements.


■ The data collection agent residing on the server collects metrics about only BMC ProactiveNet performance.



Data management sizing chart

Data management sizing chart

Table 10 provides a summary of the characteristics for Data Management for small, medium, and large environments.

Table 10 BMC ProactiveNet sizing chart for data management

Smallenvironment

Mediumenvironment

Largeenvironment

DATA

Number of devices 2 K 5 K 10 K

Total parameters 50 K 400 K 800 K

Monitor instances 20 K 50 K 90 K

KPI Mode Yes Yes Yes

Polling interval: (Stats Poll, Auto-Sync) in minutes

5, 15; 5, 10; 5, 5; 2, 15

5, 15; 5, 10; 5, 5; 2, 15

5, 15; 5, 10; 5, 5; 2, 15

RATE retention 3 months 3 months 3 months

Remote Agents 1 1 1

Adapter Type PATROL PATROL PATROL

RAW retention 8 days 8 days 8 days

UI

Concurrent operational users

10 20 30

Concurrent admin 1 1 1

Groups 1 K 2 K 3 K

SLOs 20 40 60

CONFIGURATION

Jserver MaxHeap 2 GB 6 GB 8 GB

Rate MaxHeap 2 GB 4 GB 8 GB

Agent Controller MaxHeap 1 GB 1.5 GB 2 GB

Local Agent MaxHeap 0.5 GB 0.5 GB 1 GB

Remote Agent MaxHeap 4 GB 6 GB 8 GB


Data management tuning recommendations


Table 11 provides the JVM tuning guidelines for each range of total attributes collected per server in a data management environment. JVM tuning is required.

A 32-bit JVM can support a MaxHeap of only 1.5 GB. A MaxHeap setting that is greater than 1.5 GB requires a 64-bit JVM. When using the local agent for data collection, change the size of the local agent JVM heap. The property is LOCMaxHeap for local agents and MaxHeap for remote agents.

NOTE ■ A 32-bit remote BMC ProactiveNet Agent can scale up to 125 K attributes for every

2 CPU/2 GB RAM.■ A 64-bit remote BMC ProactiveNet Agent can scale up to 800 K attributes for every

4 CPU/8 GB RAM.

Table 11 Tuning parameters for data management (part 1 of 3)

Parameter name File name Description Recommended value

Heap tuning parameter

MaxHeap for Jserver Pnjserver.conf MaxHeap allocated to Jserver Process.

■ Small: 2048 MB■ Medium: 6144 MB■ Large: 8192 MB

MaxHeap for Rate Pnrate.conf MaxHeap allocated to Rate Process


MaxHeap for Agent Controller

Pnagentcntl.conf MaxHeap allocated to Agent Controller Process


MaxHeap for Agent (Local)

Pnagent.conf MaxHeap allocated for local agent


BMC ProactiveNet database server parameter

COMDefine -c (Windows)

pndbsrv.conf Initial cache size of database server

■ Small: 1 G■ Medium: 2 G■ Large: 3 G

setenv dbsrvicache (Solaris)

startdbsrv7 Initial cache size of database server


Cell tuning parameters

EventDBSize Mcell.conf The number of events retained in repository.

Set it higher for a higher event rate.



EventDBKeepClosed Mcell.conf The minimum age in seconds of CLOSED events before they are removed from the repository.

Set it lower if event rate is high.

StateBuildSize Mcell.conf The maximum size in Kilobytes of a transaction file before it is transformed into a new saved state when the statebuilder runs again.

Set it higher for a higher event rate to avoid frequent statebuilder runs.

Other tuning parameters

pronet.apps.agent.agentmon.agentstatusrefreshperiod

pronet.conf Duration after which the agent status cache is refreshed on the agent controller.

■ Small: 45000■ Medium: 90000■ Large: 180000

pronet.apps.agent.watchdog.sleeptime

pronet.conf Frequency at which the agent writes a KEEPALIVE message to the agent controller.


pronet.apps.agent.pollperiod.allowednoreplies.tcp

pronet.conf Number of retries the agent controller makes before marking an agent UNREACHABLE.


pronet.jvm.maxthreadlimit

pronet.conf Maximum number of threads permitted for the agent JVM (buffer 10% for the instances to be discovered).


pronet.apps.agent.pollperiod

pronet.conf Frequency at which the agent controller polls each agent for status. This time is in milliseconds.


pronet.jserver.cachemodule.threadpool.max.size

pronet.conf This time is in seconds.


pronet.jserver.databasemodule.threadpool.max.size



pronet.jserver.dbconnectionpool.maxdbconnectionsize






BMC ProactiveNet Server Bandwidth Utilization

BMC ProactiveNet Server Bandwidth Utilization

In BMC ProactiveNet Server networks, the bandwidth is often measured as the amount of data that as carried from BMC ProactiveNet Agent (PATROL Proxy Enabled) to BMC ProactiveNet Server in a given time period

The following table gives hardware, software, and BMC ProactiveNet Server load details while measuring Network Bandwidth Utilization between BMC ProactiveNet Server and BMC ProactiveNet Agent (PATROL Proxy Enabled).

pronet.rate.maxdbconnections

pronet.conf Number of DB connections the analytical engine (rate process) can make at one time.


pronet.apps.agentcontroller.msghandler.workerpoolsize

pronet.conf Agent controller worker pool size.


pronet.apps.agentcontroller.dbwriter.maxmsgcachelimit

pronet.conf Agent controller Database Writer max cache limit.


Remote Agent tuning parameters

MaxHeap for Remote Agent

pronet.conf MaxHeap allocated for Remote Agent.














Time consumed by different functions


The following is the pre-defined setup, before collecting values in BMC ProactiveNet.

The following are the BMC ProactiveNet Sybase Database back-up and restores details:

■ Each incremental log file size takes an average of 1.35 GB.

BMC ProactiveNet Server Physical Server

BMC ProactiveNet version 8.6

Operating System Windows Server 2008 R2

No. of processors 8

Memory 32 G

BMC ProactiveNet Agent (PATROL Proxy enabled)

Virtual machine

BMC ProactiveNet version 8.6

Operating System Windows Server 2008 R2

No. of processors 4

Memory 16 G

Bandwidth utilization

Device 10 K (1 K PATROL agents, 9 K systems)

Monitor instance 125 K

Attributes 850 K

Polling 5 minutes stats, 15 minutes auto sync

Average Network traffic measured for 2 Hours between BMC ProactiveNet server and BMC ProactiveNet Agent (PATROL Proxy)

74,416 bytes per sec

Devices 10 K (1 K PATROL agents, 9 K systems)

Groups 2100

Monitor Instance 115 K

ProactiveNet event 5 K per day

Attribute 750 K

Polling 5 minutes stats, 15 minutes autosync

Database size 60 GB



■ Time taken to restore each incremental log file is around 30 minutes.

■ BMC ProactiveNet stores a maximum of 7 database restore log files (6 from Monday through Saturday and 1 that comes with the full backup).

The following table shows the Remote BMC ProactiveNet Agent start times with Sybase Database and Oracle Database.

The following table shows the start-up times for BMC ProactiveNet processes.

Table 12 Time taken to restore BMC ProactiveNet Sybase Database

No. Backups Time taken to restore

1 1 Incremental backup file 30 minutes

2 1 Full backup + 1 incremental backups file 1 hour

3 1 Full backup + 6 incremental backups file 3.5 hours

Table 13 Remote BMC ProactiveNet Agent start-up times with Data Management setup

No. Agent start time with Time taken in minutes

1 Sybase Database 7

2 Oracle Database 8

Table 14 Start-up times for BMC ProactiveNet Processes for Data Management

httpd jserverpronet_agnet pronet_cntl tunnelproxy rate mcell acell

1 second 8 minutes 4 seconds 5 minutes 2 seconds 12 minutes 1 second 1 second


Event management

Event managementBMC ProactiveNet event management is the method used for monitoring, processing, maintaining, and responding to events that occur in IT resources used by business enterprises, including computer systems, network services and applications.

Event management sizing recommendations

The following section provides sizing recommendations for event management.

Small environment

Refer to Table 5 on page 12 to view the characteristics of a small BMC ProactiveNet event management environment used to collect and manage events in a centralized IT infrastructure.

When planning a small BMC ProactiveNet event management environment, consider the following guidelines:

■ In a small environment you can host the server and event adapters on the same host, but PATROL integration must be on a separate system.

■ Event correlation, de-duplication, and normalization are distributed on processing cells.

Figure 3 Small BMC ProactiveNet event management environment



Medium environment

Refer to Table 5 on page 12 to view the characteristics of a medium BMC ProactiveNet event management environment used to collect and manage events for Centralized IT Infrastructure.

When planning a medium event management environment, consider the following guidelines:

■ Monitoring tools are feeding events to processing cell.

■ Processing cells are performing event correlation, de-duplication, normalization and feeding this data to BMC ProactiveNet Server

■ BMC Atrium CMDB is installed on a different system (Please see BMC Atrium CMDB documents for Hardware requirement).

■ BMC Atrium CMDB is feeding devices to the BMC ProactiveNet Server.

Figure 4 Medium BMC ProactiveNet event management environment



Large environment

Refer to Table 5 on page 12 to view the characteristics of a large BMC ProactiveNet event management environment which collects and manages events for a distributed IT infrastructure.

When planning a large event management environment, consider the following guidelines:

■ The BMC Atrium CMDB is feeding devices to BMC ProactiveNet Server with automatic sync up.

■ Install BMC Event Manager in each remote location. These remote event managers collect events directly from the event sources, filter sympathetic events, and apply normalization and de-duplication rules to other events. Important events only are then propagated to the event manager of BMC ProactiveNet Server.

■ Each remote location runs the BMC Event Manager instance as well as adapters and integration components. This requires one dedicated computer with the considerations listed in “Tested environment for concurrent users” on page 72.

Figure 5 Large BMC ProactiveNet event management environment


Event management sizing chart

Event management sizing chart

Table 15 provides a summary of the characteristics for event management for small, medium, and large environments.

* Concurrent operational user interacts with BMC ProactiveNet Operational Web-based user interface 24 hours a day 7 days a week.

Table 15 BMC ProactiveNet sizing chart for event management

Smallenvironment

Mediumenvironment

Largeenvironment

UI

Concurrent operational users*

10 20 30


Groups 100 250 500

EVENT

Intelligent events per day 0 0 0

External events per day 100 K 200 K 400 K

Event adapters 2 5 10

Remote cells 5 10 20

Event DB size default 300 K 530 K

Event DB keep closed default default default

State build size default default default

Event retention default default default

Static event collectors 10 25 50

Levels for collectors 5 5 5

Remote agents 0 0 0

Number of event adapters 2 5 10

CONFIGURATION



Agent Controller MaxHeap 1 GB 1.5 GB 2 GB

Local Agent MaxHeap 0.5 GB 0.5 GB 0.5 GB

Remote Agent MaxHeap N/A N/A N/A


Event management tuning recommendations


Table 16 lists the names, file names, descriptions, and recommended values for the tuning parameters in an environment that performs only event management.

Table 16 Tuning parameters for event management (part 1 of 2)



MaxHeap for Jserver Pnjserver.conf MaxHeap allocated to JServer Process.

■ Small: 2048 MB■ Medium: 4096

MB■ Large: 8192 MB



























pronet.conf Frequency at which the agent controller polls each agent for status.









pronet.conf Number of Max Database connections.


Table 16 Tuning parameters for event management (part 2 of 2)





The following table lists the predefined multi-cell setup, before collecting values in BMC ProactiveNet.

The following table shows the multi-cell setup details with number of Master cell and collection cells configured in BMC ProactiveNet.

Devices 10 K (1 K PATROL agents, 9 K systems)

Events to master cell 200 K per day

Number of collection cells 10

Events to collection cells 30 K per day

Groups 500

Table 17 Event rate for Master cell and collection cells

For load 500 K Events per day

Operating system Windows 2008 R2 (64-bit), 2x4 Core, 3 GHz

Event Rate to Master cell 200 K Events per day

Event Rate to Collection cells (collection cells were configured with rule-based processing)

30 K Events per day

Duration of streaming 20 K Events per day for collection cells

7 days

Duration of streaming 30 K Events per day for collection cells

6 days



The following table shows the CPU and Memory consumed by BMC ProactiveNet process with multi-cell setup and Event rush to Master cell and collection cells.

The following table shows time consumed to start by all BMC ProactiveNet processes with multi-cell setup.

Table 18 CPU and Memory consumption by BMC ProactiveNet process with Event rush

Process

200 K Events per day for Master cell and 20 K Events per Day

for collection cells

200 K Events per day for Master cell and 30 K Events per Day

for collection cells

CPU Memory CPU Memory

PnAgent 5% 120MB 5% 120MB

PwTray 0.5% 4MB 0.5% 4MB

acell 0.1% 11MB 0.05% 12MB

dbsr 1% 230MB 1% 300MB

httpd 0.2% 55MB 0.25% 55MB

jserver 4% 2700MB 3% 3000MB

mcell 10% 900MB 10% 1000MB

pronet_cntl 0.05% 90MB 0.05% 90MB

rate 0.15% 190MB 0.025% 180MB

services 0.2% 33MB 0.15% 30MB

tunnelproxy 0.05% 20MB 0.025% 20MB

Table 19 Start-up times for BMC ProactiveNet processes for Event Management

httpd jserverpronet_agnet

pronet_cntl

tunnelproxy rate mcell acell

25seconds

11minutes

3minutes

15seconds

17seconds

15minutes

3second

30second



The following table shows the CPU and Memory consumed by Collection cells with Event rush.

Table 20 CPU and Memory consumption by collection cells with Event rush

Collection cells20 K Events per day for

for collection cells30 K Events per day for collection

cells

CPU Process Size CPU Process size

mcell_cell1 0.50% 180MB 0.50% 190MB

mcell_cell2 0.50% 100MB 0.50% 180MB

mcell_cell3 0.50% 160MB 0.50% 200MB

mcell_cell4 0.50% 180MB 0.50% 200MB

mcell_cell5 0.50% 180MB 0.50% 190MB

mcell_cell6 0.03% 45MB 0.02% 60MB

mcell_cell7 0.50% 180MB 0.50% 190MB

mcell_cell8 0.08% 60MB 0.05% 80MB

mcell_cell9 0.06% 180MB 0.50% 190MB

mcell_cell10 0.03% 100MB 0.03% 100MB


Impact Management

Impact ManagementBMC ProactiveNet server can be set up to display the health of key service models. This setup supports creating (or importing) Configuration Items (CIs) and displaying the impact on them due to events. Unlike Data and Event Only setup, the focus is on monitoring critical business services.

Impact Management sizing recommendations

This section provides recommendations for a BMC ProactiveNet environment that provides impact management.

Small environment

Refer to Table 5 on page 12 to view the characteristics of a small BMC ProactiveNet impact management environment used to manage events and their impact in a centralized IT infrastructure. When planning a small impact management environment, consider the following guidelines:

■ In a small environment, you can host the server and event adapters on the same host, but PATROL integration must be on a separate system.

■ Event correlation, de-duplication, and normalization are distributed on processing cells.

■ The BMC Atrium CMDB feeds configuration items and relationships to the BMC ProactiveNet Server with automated and manual publish mode.

Figure 6 Small BMC ProactiveNet Impact Management environment



Medium environment

Refer to Table 5 on page 12 to view the characteristics of a medium BMC ProactiveNet impact management environment used to manage events and their impact for Centralized IT Infrastructure.

When planning a medium impact management environment, consider the following guidelines:


■ Processing cells are performing event correlation, de-duplication, normalization and feeding this data to BMC ProactiveNet Server.


Figure 7 Medium BMC ProactiveNet Impact Management environment



Large environment

Refer to Table 5 on page 12 to view the characteristics of a large BMC ProactiveNet impact management environment is one used to manage events and their impact in a centralized IT infrastructure.

A total number of 10000 configuration items can be published at a time.

When planning a large impact management environment, consider the following guidelines:

■ Install BMC Atrium CMDB on different systems (see BMC Atrium CMDB documents for hardware requirement).

■ Processing cells are performing event correlation, de-duplication, normalization and feeding this data to BMC ProactiveNet Server.


Figure 8 Large BMC ProactiveNet Impact Management environment


Impact Management sizing chart

Impact Management sizing chart

Table 21 provides a summary of the characteristics for impact management for small, medium, and large environments.

Table 21 BMC ProactiveNet sizing chart for Impact Management

Smallenvironment

Mediumenvironment

Largeenvironment

UI


10 20 30

Concurrent Admin 1 1 1

IMPACT

CIs in CMDB 100 K 100 K 100 K

Services in CMDB 15 25 50

CIS in ProactiveNet Server

5 K 10 K 20 K

CIS per cell 5 K 10 K 20 K

CIS in ProactiveNet Server

5 K 10 K 20 K

CIS per Service Model (Max)

2 K 5 K 10 K

Services in ProactiveNet Server

15 25 50

CONFIGURATION


Rate MaxHeap default default default

Agent Controller MaxHeap

default default default

Local Agent MaxHeap

default default default

Remote Agent MaxHeap

N/A N/A N/A


Impact Management tuning recommendations

Impact Management tuning recommendations

Table 22 lists parameter names, file names, descriptions, and recommended values for the parameters in an environment that performs only impact management.

Table 22 Tuning parameters for Impact Management (part 1 of 2)



MaxHeap for Jserver Pnjserver.conf MaxHeap allocated to JServer Process.

■ Small: 2048 MB■ Medium: 4096

MB■ Large: 8192 MB
























The following table lists the predefined setup, before collecting values in BMC ProactiveNet.
















DestinationBufferKeepSent

smmgr.conf Maximum time for the cell to reply success or failure of the upload. For large models, BMC recommends to have a larger value.


No CIs 20 K

No Service Models 4

No of Levels 6

No Events per day 100 K

Table 22 Tuning parameters for Impact Management (part 2 of 2)



Recommended AR configuration settings

The following table shows time consumed by all BMC ProactiveNet processes with Impact setup.

Recommended AR configuration settings

To support the BMC ProactiveNet sizing chart for Impact Management, BMC Software recommends making the following configuration changes in Mid-Tier and AR Application.

These configuration settings ensure that BMC ProactiveNet can support publishing large service models with large numbers of CIs.

Table 23 Start-up times for BMC ProactiveNet processes with Impact setup

httpd jserverpronet_

cntltunnelproxy rate mcell acell

Agent controller

2 seconds 2 minutes53 seconds

1 minute26 seconds

1 minute1 second

1 minute18 seconds

4 seconds 1 minute1 second

1 minute22 seconds

NOTE All settings can be manually inserted into their respective configuration files. Program restart is necessary if configurations are changed in the configuration files directly.

WARNING ■ These configuration changes are recommended exclusively for optimizing BMC

ProactiveNet Impact Management functionality.

■ Refer to the AR System 7.6.04 documentation available on the Customer Support website at http://www.bmc.com/support.


http://www.bmc.com/support

Recommended AR System Mid-Tier configuration settings


Table 24 Recommended AR System Mid-Tier configuration settings (part 1 of 5)

Setting Value

Location of configuration

file

Configuration Parameter and

Value Manual StepsSetting

Limitations

Definition Change Check Interval

86400 sec mid-tier_install_dir/WEB-INF/classes/config.properties

arsystem.cache_update_interval=86400

1. Login to http://hostname/arsys/shared/config/config.jsp with default password arsystem

2. Click Cache Settings link on left navigation.

3. In Definition Change Check Interval field, enter 86400.

4. Click Save Changes

Generic

Pooling max total connections

80 (default)

mid-tier_install_dir/WEB-INF/classes/config.properties

arsystem.pooling_max_connections_per_server=80


2. Click General Settings on left navigation.

3. In Maximum connections per server, enter 80.

4. Click Save Changes.

5. Restart Mid-tier for this change to take effect.

Generic default

Resource Check Interval


arsystem.resource_expiry_interval=86400



3. In Resource Check Interval field, enter 86400.


Generic / company policy determined



Cache persistence

Enable mid-tier_install_dir/WEB-INF/classes/config.properties

arsystem.ehcache.diskPersistent=true

arsystem.ehcache.overflowToDiskTemp=false



3. Check the Enable Cache Persistence box.


Generic

Prefetch Forms

Enable mid-tier_install_dir/WEB-INF/classes/prefetchConfig.xml

Change contents of XML. Refer to Mid-Tier Guide document for detailed steps on what to change.

1. Login to http://hostnamearsys/shared/config/config.jsp with default password arsystem


3. Refer to Mid-Tier Guide document for detailed steps on what to change.


Company policy determined

Log setting -> log level

Server mid-tier_install_dir/WEB-INF/classes/config.properties

arsystem.log_level=Severe


2. Click Log Settings link on left navigation.

3. In Log Level menu, select Severe.


Generic / production only

Form expiration


arsystem.formhtmljs_expiry_interval=3600

N/A Generic


Setting Value


file



Limitations



JVM heap min and max heap size

1 GB In Windows, it is present in the registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Procrun 2.0\Tomcat5\Parameters\Java

In Unix, it is located in tomcat_install_dir/bin/catalina.sh

In Windows:

Name:JvmMs

Type:REG_DWORD

Data: (decimal) 1024

Name:JvmMx

Type:REG_DWORD

Data: (decimal) 1024

In Unix:

JAVA_OPTS=-Xms1024m –Xmx1024m

In Windows:

1. Start -> BMC Software -> AR System -> BMC Remedy Mid Tier -> Configure Tomcat

2. In Tomcat Properties dialog, go to Java tab.

3. In Initial memory pool field, enter 1024. In Maximum memory pool, enter 1024.

4. Click OK.

5. Restart Mid-tier.

In Unix:

None.

Hardware configuration based


Setting Value


file



Limitations



Tomcat max threads

500 tomcat_install_dir/conf/server.xml

Look for your web server’s connector port number. Default is 8080. Each connector has the maxThreads parameter.

Connector URIEncoding="UTF-8" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false" maxHttpHeaderSize="8192" maxSpareThreads="75" maxThreads="500" minSpareThreads="25" port="8080" redirectPort="8443"/



Setting Value


file



Limitations



Tomcat accept count

100 tomcat_install_dir/conf/server.xml

Look for your web server’s connector port number. Default is 8080. Each connector has the acceptCount parameter.

Connector URIEncoding="UTF-8" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false" maxHttpHeaderSize="8192" maxSpareThreads="75" maxThreads="500" minSpareThreads="25" port="8080" redirectPort="8443"/



Setting Value


file



Limitations


Recommended AR Application Server configuration settings


AR System server connects to the database and maintains a pool of persistent connections based on the thread settings as defined in the AR System configuration files. The configuration file is located at ar_install_dir/conf/ar.cfg

Table 25 Recommended AR Application Server configuration settings (part 1 of 2)

AR Server threads Value



Limitations

Set Delay-Recache-Time

5 minutes (300 seconds)

Delay-Recache-Time: 300

None Generic

Max-Entries-Per-Query

0 Max-Entries-Per-Query: 0

1. Open AR System Administration Server Information.

2. Go to Configuration Tab.

3. In Max Entries Returned By GetList, enter 0.

4. Click OK.

Generic

Next-Id-block-size

100 Next-ID-Block-Size: 100



3. In Next Request ID Block Size field, enter 100.

4. Click OK.

Generic

Server-Side-Table-Chunk-Size

1000 Server-Side-Table-Chunk-Size: 1000



3. In Server Table Field Chunk Size field, enter 1000.

4. Click OK

Generic



Unqualified Searches

Uncheck Allow-Unqual-Queries: F



3. Uncheck Allow Unqualified Searches.

4. Click OK.


Development Cache mode

Uncheck Cache-Mode: 0 1. Open AR System Administration Server Information.


3. Uncheck Development Cache Mode.

4. Click OK.

Production only

Turn off all logging

Uncheck Logging (API/SQL/Filter) along with other logging

Debug-mode: 0 1. Open AR System Administration Server Information.

2. Go to Log Files Tab.

3. Make sure none of the options are checked.

4. Click OK.

Generic / Production only

Submitter Mode

Locked Submitter-Mode: 1


2. Go to License Tab.

3. Select Locked for Submitter Mode.

4. Click OK.

5. Restart AR Server.


Table 25 Recommended AR Application Server configuration settings (part 2 of 2)

AR Server threads Value



Limitations



Thread Recommendations

The Fast and List queue values can be configured in ar_install_dir/conf/ar.cfg with the following parameters and values:

— Private-RPC-Socket: 390601 1 1





Fast and List thread settings are hardware configuration based limitation.

There is no configuration file to configure the Customer Access Interface (CAI) plug-in registry value. Entry is saved in the database. Do manual steps 7-9.

Manual Steps

1 Login to the User Tool as an Administrator.

2 Open up the AR System Administration Console.

3 Select to System -> General -> Server Information

4 Enter port and Queues in Server Information Dialog.

5 For each type of thread, modify the min threads and max threads for the RPC program as listed below in the chart. Please note that we are sharing the queue for Loopback and CAI Thread.

6 Click OK.

7 Open CAI Plugin Registry form in new mode.

8 Create an entry with following values:

■ Private Queue #*: 390626■ Number of Threads*: 3

9 Click Save.

10 Restart ARServer for the CAI Plugin threads to take affect.



CAI plugin registry setting is a hardware configuration limitation and dependent on fast/list thread settings.

Below is an example of the AR Server Configuration screen and the CAI Plugin Registry screen. Note that values have to match.

Table 26 Fast and List thread settings

Queue Number Purpose

No. of Threads

(min / max) Comments

Private-RPC-Socket: 390601 PAlert Queue 1

Private-RPC-Socket: 390603 Escalation Queue 1 Ensure there are escalations using these threads.

Private-RPC-Socket: 390620 Fast Queue 6

Private-RPC-Socket: 390626 Loopback Socket Queue / CAI Thread

3 Use same queue as CAI to share threads. So only one entry is needed. Create entry in the CAI Plugin Registry form with that private queue number matching number of threads

Private-RPC-Socket: 390635 List queue 6 Set min and max to the same number


Hybrid management

Hybrid managementHybrid management is a real-time enterprise environment which combines data management and event management. Hybrid management collects data and monitors events from different computers, network systems and applications, and calculates the impact between the systems.

Hybrid management sizing recommendations

The following section provides sizing recommendations for hybrid management of both data collection and event management.

The systems require sufficient memory for the analytical engine component to perform all of the tasks quickly. Most data that it uses is cached in memory so that baseline and abnormality generation on virtually every attribute in the system can be done behind the scenes.

BMC ProactiveNet currently uses an embedded database (Sybase Adaptive Server Anywhere or Sybase ASA) that always runs on the same system as the core server components. The embedded database is optimized for BMC ProactiveNet.

Small environment

Refer to Table 5 on page 12 to view the characteristics of a small BMC ProactiveNet event management environment used to collect and manage events in a centralized IT infrastructure.

When planning a small data collection and event management environment, consider the following guidelines:

■ In a very small environment that collects 25,000 or fewer attributes, you could use one server with a local agent acting as the data collector.

■ If you use the BMC PATROL Adapter, install the Integration Service for PATROL on the agent.

■ If you expect more than five concurrent users or if the average polling intervals are quicker than five minutes, use a medium architecture setup.

NOTE In a hybrid environment, the resources are shared between the data collection and event management functions. Therefore, a hybrid environment handles fewer attributes than a dedicated data collection environment and fewer events than a dedicated event management environment. This statement assumes that the hybrid and each of the dedicated environments use comparable hardware.



■ If you collect data across networks or firewalls, consider using a remote agent to minimize the number of connections to manage across the networks or firewalls.

■ To improve I/O throughput, locate the operating system and database on separate disks, with their own disk controllers.

■ In a small environment you can host server and event adapters on the same host. PATROL integration needs to be on separate system.

■ Event correlation, de-duplication and normalization is distributed on processing cells.

Medium environment

Refer to Table 5 on page 12 to view the characteristics of a medium BMC ProactiveNet hybrid management environment.

When planning a medium data collection and event management environment, consider the following guidelines:

■ The BMC Atrium CMDB is feeding devices to BMC ProactiveNet Server.


■ A 64-bit agent can handle a larger number of attributes.


■ If you expect the total number of attributes for the environment to grow beyond 400,000 attributes, use it a large-environment deployment so that the system can accommodate growth smoothly.


■ The data collection agent residing on the server collects metrics about only BMC ProactiveNet performance.



■ Processing cells are performing event correlation, de-duplication, normalization and feeding this data to BMC ProactiveNet Server

■ BMC Atrium CMDB is installed on different system (Please see BMC Atrium CMDB documents for Hardware requirement)



Large environment

Refer to Table 5 on page 12 to view the characteristics of a large BMC ProactiveNet data collection and event management environment.

When planning a large data collection and event management environment, consider the following guidelines:

■ The BMC Atrium CMDB feeds devices to the BMC ProactiveNet Server with automatic sync-up.

■ Configure each BMC ProactiveNet server so that it contains an entire line of business, rather than spreading the monitoring from any line of business or application across servers.


■ A 64-bit agent can scale to much higher attributes. Make sure the memory allocated for this agent is sufficient.



■ For optimum performance, minimize the number of monitors running on the local agent that resides on the BMC ProactiveNet server.

■ The data collection agent residing on the server should collect metrics about only BMC ProactiveNet performance.


■ Install BMC Event Manager in each remote location. These remote event managers' collects events directly from the event sources, filter sympathetic events and apply normalization and de-duplication rules to other events. Only important events are then propagated to the event manager of BMC ProactiveNet Server.

■ Each remote location runs the BMC Event Manager instance as well as adapters and integration components and requires one dedicated computer with following specification. “BMC ProactiveNet Agent scaling recommendations” on page 7.


Hybrid management sizing chart

Hybrid management sizing chart

Table 27 provides a summary of the characteristics for hybrid management for small, medium, and large environments.

Table 27 BMC ProactiveNet sizing chart for hybrid management (part 1 of 2)

Smallenvironment

Mediumenvironment

Largeenvironment

DATA

Number of devices 2 K 5 K 10 K

Total parameters 50 K 250 K 500 K

Monitor instances 10 K 30 K 65 K

KPI Mode YES YES YES

RAW retention default default default

RATE retention default default default

Remote Agents 1 1 1

Adapter Type PATROL PATROL PATROL

Polling interval: (Stats Poll, Auto-Sync)

5,15 5,15 5,15

UI


10 20 30


Groups 100 300 700

EVENT

Intelligent events per day 500 1 K 2 K

External events per day 50 K 100 K 200 K

Event adapters 0 0 0

Remote cells 0 0 0

Event DB size default default default

Event DB keep closed default default default

State build size default default default

Event retention default default default

Static event collectors 0 0 0

Levels for collectors 0 0 0


Hybrid management tuning recommendations


Table 28 provides the JVM tuning guidelines for a server that performs both data collection and event management.

Remote agents 0 0 0

Number of event adapters 0 0 0

CONFIGURATION



Agent Controller MaxHeap

1 GB 1.5 GB 2 GB

Local Agent MaxHeap default default default

Remote Agent MaxHeap 2 GB 4 GB 8 GB

Table 28 Tuning parameters for data and event management (part 1 of 2)



MaxHeap for Jserver Pnjserver.conf MaxHeap allocated to Jserver Process.


MaxHeap for Rate Pnrate.conf MaxHeap allocated to Rate Process


MaxHeap for Agent Controller

Pnagentcntl.conf MaxHeap allocated to Agent Controller Process





MaxHeap for Agent (Remote)

Pnagent.conf MaxHeap allocated for remote agent





Table 27 BMC ProactiveNet sizing chart for hybrid management (part 2 of 2)

Smallenvironment

Mediumenvironment

Largeenvironment
























pronet.conf This time is in seconds. ■ Small: 15■ Medium: 20■ Large: 40


pronet.conf This time is in seconds. ■ Small: 15■ Medium: 20■ Large: 40




pronet.rate.maxdbconnections

pronet.conf Number of DB connections the analytical engine (rate process) can make at one time.


Table 28 Tuning parameters for data and event management (part 2 of 2)



Cloud management

Cloud managementBMC ProactiveNet supports the BMC Cloud Lifecycle Management environment. In the BMC Cloud Lifecycle Management environment, you can use BMC ProactiveNet to monitor the performance of virtual machine monitors (VMMs, also called hypervisors).

When planning your deployment, it is helpful to consider factors such as your end-user community, your network infrastructure, and security issues.

End Users

How you build your cloud is determined in part by the number and distribution of the tenants and end users you support. Answering the following questions will help you understand the number, type, and distribution of the infrastructure resources that you need to build your cloud:

■ How big is your user community?

■ How is your user community distributed geographically?

■ If you represent a service-provider organization, how many tenants will you support, and how many users are associated with each tenant?

■ How will you manage end-user and administrator access to your cloud?

■ How will you manage access to the My Services Portal?

Network Infrastructure

At the heart of your cloud planning is your network infrastructure. You must decide how to organize the pods, network containers, and resource pools in your cloud.

Much of your network-infrastructure planning will be consumed by BMC Cloud Lifecycle Management as service blueprints to enable automated delivery of resources that support services your end users request.

■ How many pods do you need to support your tenants and end users?

■ How should your pods be distributed geographically? Consider whether you will have staff to support those pods on-site, or whether you will provide support remotely.

■ How many network containers do you need in each pod?

■ How will you assign resources in network containers? For example, will you assign resources to specific tenants or level of service?

■ How will you build resource pools? For example, will resources be grouped according to performance, geographic location, or some other criteria?


Cloud management sizing recommendations

■ How many physical and virtual servers do you need?

■ How will you address failover and availability concerns?

■ How should you build your pre-production environment? Prior to making the cloud available to your end users, you will need an environment in which to develop and test your cloud. Do you need only environments for development, testing, and production? If you represent a service provider organization, should you make a pre-production environment available to your tenants?


BMC Cloud Lifecycle Management provides an end-to-end workflow to help you be successful with your cloud implementation. The workflow provides guidelines for building your cloud, preparing services to be requested and delivered in that cloud, keeping your cloud operational, and retiring services and resources.

The CLM Install Planner allocates components based on predefined templates that provide a streamlined approach to sizing and configuring your deployment. Based on your requirements, you will select a template when you launch the Install Planner that closely matches your planned deployment scenario.

The template types are:

■ Small deployment

■ Medium deployment

■ Large deployment



Small deployment

Select the small template for deployments of 10,000 virtual devices.

Figure 9 High level architecture for small BMC ProactiveNet Server deployment



Medium deployment

Select the medium template for deployments of 25,000 virtual devices.

Figure 10 High level architecture for medium BMC ProactiveNet Server deployment



Large deployment

Select the large template for deployments of 50,000 virtual devices.

Figure 11 High level architecture for large BMC ProactiveNet Server deployment


Cloud Management hardware requirements

Cloud Management hardware requirements

Table 29 provides a summary of hardware requirements for Cloud Management, to determine the number of BMC ProactiveNet Central Servers, BMC ProactiveNet Servers, and DCH, and BMC BladeLogic Servers for small, medium and large environments.

Hardware requirements for Servers in Cloud Management

Table 30 provides a summary of server hardware requirements for servers in Cloud Management (BMC ProactiveNet Central Servers, BMC ProactiveNet Servers, DCH and BMC BladeLogic servers).

Table 29 Server requirements for small, medium and large Cloud deployments

Environment

No. of BMC ProactiveNet

Central Servers

No. of BMC ProactiveNet

Servers No. of DCH

No. of BMC BladeLogic

Servers

Small 1 1 1 1

Medium 1 3 3 1

Large 1 5 5 1

Table 30 Hardware requirements for Servers in Cloud Management

BMC ProactiveNet

Central Server

BMC ProactiveNet

Server

BMC ProactiveNet

Data Collection

Host

BMC BladeLogic

Servers

Operating system ■ Windows 2008 R2 (64-bit), 3 GHz, and 8 threads


CPUs 4 4 4 2

Storage configuration ■ 10 K SAS disk or SAN storage


Cloud Management sizing chart


Table 31 provides the number of monitor instances and attributes for small, medium and large environments.

Table 32 provides the parameter information for BMC ProactiveNet Central Server, BMC ProactiveNet Server and BMC ProactiveNet Data Collection Host in Cloud Management.

Table 31 Monitor instances and attributes in Cloud Management

Size of environment Devices Monitor Instances Attributes

Small 10,000 25 K 45 K

Medium 30,000 75 K 135 K

Large 50,000 125 K 225 K

Table 32 Tuning parameters for Cloud Management (part 1 of 3)

Server Parameter Name File Name DescriptionRecommended

Value

BMC ProactiveNet Central Server

Max Heap for Jserver

pnjserver.conf Max Heap allocated for Jserver Process

Default

Max Heap for Rate

pnrate.conf Max Heap allocated for Rate Process

Default

Max Heap for Agent Controller

pnagentcntl.conf Max Heap allocated for Agent Controller Process

Default

Max Heap for Agent (Local)

pnagent.conf Max Heap allocated for Agent Process

Default

COMDefine - c pndbsrv.conf Initial cache size for db server

Default



BMC ProactiveNet Server

Max Heap for Jserver

pnjserver.conf Max Heap allocated for Jserver Process

4096 MB

Max Heap for Rate pnrate.conf Max Heap allocated for Rate Process

4096 MB

Max Heap for Agent Controller

pnagentcntl.conf Max Heap allocated for Agent Controller Process

2048 MB

Max Heap for Agent (Local)

pnagent.conf Max Heap allocated for Agent Process

1024 MB

COMDefine - c pndbsrv.conf Initial cache size for db server

3072 MB



180000



120000



4



100000



180000


pronet.conf This time is in seconds. 40







Value


Virtual Center details used for monitoring

Virtual Center details used for monitoring

Table 33 provides details of the virtual centers used for monitoring.

BMC ProactiveNet Data Collection Host

Max heap for Agent

pnagent.conf Max heap allocated for Agent Process

8192 MB



120000



100000



180000

Table 33 Virtual Center details used for monitoring

Virtual Center 1 Virtual Center 2

Version of the Virtual Center Used 4.0.0, 208111 4.1.0,2587902

Number of Data Centers 4 6

Number of ESX Servers 156 41

Clusters Per VC 7 5

Number of Resource Pools/VC 107 275

Number of VMs 2300 2900



Value


Reports Management

Reports ManagementBMC ProactiveNet Performance Management Reporting is an advanced reporting platform. It uses the SAP® BusinessObjects Enterprise product as the host for BMC ProactiveNet Performance Management to administer and publish reports. It also uses Oracle® Database as the application database. BMC ProactiveNet Performance Management Reporting contains impact report and event report templates.

■ Event report templates—display operator response time to an event, event counts, top event sources, and other event details.

■ Impact report templates—display data based on a service's availability, failures, repairs and incidents, and the time related to each.

Data for these templates is obtained from the Oracle database. BMC ProactiveNet Performance Management Reporting also enables you to create ad hoc reports and offers more flexibility when compared to BMC Event and Impact Reporting. The product is intended for customers who are using BMC ProactiveNet Performance Management 8.5 or higher versions.

Architecture

BMC ProactiveNet Performance Management systems propagate events and component status changes from BMC ProactiveNet servers to BMC ProactiveNet Report Engine. BMC ProactiveNet Report Engine then aggregates and summarizes the events and component status changes and stores the processed data in the Oracle database. The impact reports are supplemented with associated service information

Figure 12 shows the architecture for BMC ProactiveNet Performance Management Reporting.

Figure 12 BMC ProactiveNet Performance Management reporting architecture


Event Reports

Event Reports

Table 34 shows the hardware consumed by Oracle database for 8 days with 200 K events per day.

Table 35 shows the minimum CPU and memory consumption by events reports.

BMC ProactiveNet Business Objects reporting engine pulls the following types of pre-defined Event Reporting from the database:

■ Event Summary by Priority and Event Class■ Event Summary by Priority and Host■ Event Summary by Priority and Host – Details■ Event Summary by Priority and Location■ Event Summary by Priority and Location – Details■ Event Summary by Priority and Object■ Event Summary by Priority and Object - Details

Table 34 Oracle Database Size for 8 days with 200 K events per Day

No. Database Database size Events rate Total Events

1 Oracle 2.78 GB 200 K per day 1650 K

Table 35 CPU and Memory consumption by Event Reports

No. Process CPU UsageMemory Used

in MB Component

1 Crystalras.exe < 5% 39 Business Objects

2 CMS.exe < 5% 50 Business Objects

3 BMCProactiveNetReportEngine < 15% 600 BMC ProactiveNet

4 Oracle Server Process < 20% 2252 Oracle


Impact Reports

The following are pre-defined Event Reports Types generated by Business Objects reporting engine.

Impact Reports

Table 37 shows the hardware consumed by Oracle database for 6 service models with 20 K CI and 6 levels.

Table 38 shows the minimum CPU and memory consumption by Impact Reports.

Table 36 Pre-defined Event Reports Types generated by Business Objects

No. File nameNo. of records in

reportReport type (file

size)

Total time to generate

reports (sec)

1 BPPM01.02 - Event Summary by Priority and Event Class

323,832 Excel (37 kb)PDF (142 kb)

230

2 BPPM01.03 - Event Summary by Priority and Host

63,007 Excel (242 kb) PDF (821 kb)

342

3 BPPM01.03a - Event Summary by Priority and Host - Details

2,579 Excel (39 kb) PDF (124 kb)

83

4 BPPM01.04 - Event Summary by Priority and Location

1,266,750 Excel, PDF 578

5 BPPM01.04a - Event Summary by Priority and Location - Details

1,072,836 Excel (39 kb) PDF (119 kb)

507

6 BPPM01.05 - Event Summary by Priority and Object

2 Excel (17 kb) PDF (56 kb)

15

7 BPPM01.05a - Event Summary by Priority and Object - Details

1 Excel (13 kb) PDF (42 kb)

79

Table 37 Oracle database size for 6 service models with 20 K CI and 6 levels

No. Database Database size Service models Total CIs Levels

1 Oracle 2000 K 6 20 K 6

Table 38 CPU and memory consumption by Impact Reports

No. Process CPU UsageMemory Used

in MB Component

1 Crystalras.exe < 5% 39 Business Objects

2 CMS.exe < 5% 47 Business Objects

3 BMCProactiveNetReportEngine < 5% 320 BMC ProactiveNet

4 Oracle Server Process < 20% 2230 Oracle


Impact Reports

BMC ProactiveNet Business Objects reporting engine pulls the following types of pre-defined Impact Reporting from the database:

■ Component Availability

■ Component Availability Details

■ Losses Details

■ MTBF

Table 39 shows the pre-defined Impact Reports Types generated by Business Objects reporting engine.

Table 39 Pre-defined Impact Reports Types generated by Business Objects

No. File nameNo. of records in

reportReport Type (file

size)

Total time taken to generate reports (sec)

1 BPPM05.01 - Component Availability

371,647 Excel (24 kb), PDF (82 kb)

5

2 BPPM05.01a - Component Availability - Details

1,699,979 Excel (17 kb), PDF (98 kb)

3

3 BPPM05.02a - Losses - Details 1,884,025 Excel (12 kb), PDF (51 kb)

10

4 BPPM05.03 - MTBF 1,892,027 Excel (34 kb), PDF (94 kb)

60


Component performance and tuning recommendations

Component performance and tuning recommendations

This section provides recommendations and guidelines for performance tuning of various components for data management, event management, impact management, and hybrid management.

Disk subsystems and database

The performance of the disk subsystem used for the BMC ProactiveNet database can significantly affect the scalability of your system. BMC Software recommends that you use the following guidelines:

■ Use RAID 10 or 01 on larger BMC ProactiveNet installations to better satisfy the higher demands on write IO operations

■ Use SAN on medium and large deployments.

■ Performance testing for the sizing numbers in this document was performed on UNIX and NTFS filesystem. Performance problems were observed using Veritas file systems and not recommended for large deployments.

■ Use a larger number of physical disk drives (spindle count) instead of larger capacity disks. Because disk drive throughput performance has not increased at the same rate of disk capacity, you can achieve better performance with a higher number of smaller disks.

■ Defragmentation of the database file should be done every 6 months for large environments.

■ Avoid extending raw data retention by a large amount - this can impact I/O performance.

CPU guidelines

Parallel CPUs usually have a bigger impact on improving user response time than a single CPU with higher clock speed.


Configuration and deployment

Configuration and deployment

■ To minimize connections between networks or across firewalls, use BMC ProactiveNet proxy to consolidate BMC ProactiveNet agents.

■ When using BMC PATROL Adapter, deploy the Integration Service for PATROL strategically so that the connection from the Integration Service for PATROL does not need to span across networks or firewalls – instead use the BMC ProactiveNet agent connection to do this (or the BMC ProactiveNet Proxy).

■ Deploy monitors and users in a phased approach (validating after gradual increments).

Data collection

Focus collection on KPIs. You do not need to pull all metrics and monitors into BMC ProactiveNet.

■ Leverage Abnormality generated Detailed Diagnostics to pull in more detailed level (and non-KPI info).

■ Poll only critical monitor instances at quick poll intervals (less than 5 minutes).

■ Distribute monitors and adapters across agents in an intelligent fashion.

Reports and views

■ Configure views and graphs to update on demand, rather than at regular intervals.

■ Configure reports at less frequent intervals unless absolutely required.

■ Keep Report and View durations to a minimum. Long report periods (reports which span a long durations) can cause substantial impact.

■ Report scoping can have a large impact on report generation. Use group scoping whenever possible.

■ Schedule daily report generation for off-peak time frames (for example, 2:00 a.m.).


Tested environment for concurrent users

Tested environment for concurrent usersThe following steps were followed to test 30 concurrent users in different large environments including data collection, external event management, impact management, and data collection and event management:

■ 30 different users were created on BMC ProactiveNet Server.

■ 30 concurrent users logged on to the BMC ProactiveNet Server. The users included both the restricted and unrestricted users.

For example, if the number of restricted users was 10, then there were 20 unrestricted users.

■ 50% of the users accessed Event View, Tile View, Grid View, and Event Operations page and the rest 50% of the users randomly accessed other pages.

■ BMC ProactiveNet Operations console was accessed using Microsoft Internet Explorer 7.0 and above and Mozilla Firefox 3.5 and above.

NOTE If all the users are on the same network, the response times for the user interfaces are found to be better.


Frequently asked questions

Frequently asked questionsThis section provides answers to the following frequently asked questions:

■ Does increasing data retention have an impact on performance?

■ What was the data retention used in the scalability testing?

■ How can I monitor more than 10 remote cells from BMC ProactiveNet Administration Console?

■ What is the average number of parameters that a PATROL Agent can collect?

■ How can I tell if the load on the system exceeds its capacity?

■ What is the best way to deploy and configure my adapters across agents?

■ Are there any settings or tuning requirements for the database?

■ Why are the memory requirements so large?

■ How does clustering of the web server, application server, or agent impact the scale estimates?

■ Is there any recommendation if baselining is done for all metrics (non-KPIs)?

Does increasing data retention have an impact on performance?

If a high performance SAN, or equivalent, is used for data storage, you should experience acceptable performance even if you double the default data retention (raw or condensed). If more than double the retention is desired, BMC Software recommends that you only increase retention on the condensed data (the impact is lower). BMC Software recommends that you retain raw data for no more than 16 days and condensed data for no more than 1 year (365 days).

What was the data retention used in the scalability testing?

For data collection, we used 30 days for stats data and 90 days for rate and baseline data.

How can I monitor more than 10 remote cells from BMC ProactiveNet Administration Console?

You have to disconnect few cells and connect to the cells that you want to monitor. At any given time, you cannot connect to more than 10 remote cells.



What is the average number of parameters that a PATROL Agent can collect?

The average number is 850 parameters per PATROL Agent, and it usually depends on the KMs that are loaded. This was tested on Windows and UNIX machines.

How can I tell if the load on the system exceeds its capacity?

The following are the most common issues that arise when capacity is exceeded:

■ The analytical engine runs out of memory. If this occurs, OutOfMemory exceptions are logged in the BMC ProactiveNet log file by rate process. This usually means that you need to increase MaxHeap. See “Tested environment for concurrent users” on page 72.

■ There are gaps in data collection across all monitors sporadically, or there are artificial alarm delays after a threshold condition has been violated. You might also see gaps in the data shown in graphs. When this occurs, you might see pending, cache size limit exceeded, and dropping messages logged in the BMC ProactiveNet log file.

Gaps in data could result from memory issues or I/O bottlenecks. If you see no OutOfMemory exceptions logged, it is probably an I/O issue. Check the I/O by looking at % disk busy for the disks that are used (for example, the iostat cmd on Solaris). If the system consistently shows that % disk busy is above 30%, there is most likely an I/O problem.

■ User response becomes much slower when using the web interface. If it is slow for all interactions, this indicates a problem with memory or CPU. If it is only slow when graphing, this indicates an I/O constraint.

■ Check the out-of-the-box monitors that BMC ProactiveNet creates on the server. If you see sustained (minutes) CPU spikes above 80%, this usually indicates some resource issue (not necessarily a lack of CPU).

What is the best way to deploy and configure my adapters across agents?

In general it depends on what you are trying to accomplish. For best performance, it is always better to have the agent that runs the adapter installed in the same network as the server from which it is pulling data. This ensures that the adapter calls (for example, web service and database queries) do not have latency issues. The BMC ProactiveNet Server and Agent connection bundles up the data more efficiently, which creates better cross network traffic.

It is possible to use one large adapter to pull in data from a BMC ProactiveNet application, but there are times when it is better to use multiple adapters across one (or many) BMC ProactiveNet Agents. If you use separate adapters for different application types, you can set different polling intervals for the high priority applications (this allows more scaling in the end). You could also do this for different application instances, as well (not just for application types).



Are there any settings or tuning requirements for the database?

Because BMC ProactiveNet uses an embedded database, most settings are optimized out-of-the-box.

Why are the memory requirements so large?

For the analytical engine to perform all of the tasks quickly, the majority of the data it operates on is cached in memory. Keep in mind that baseline and abnormality generation is performed behind the scenes on virtually every attribute in the system. The trade-off for performing more quickly on base lining and abnormality generation is that more memory is consumed.

How does clustering of the web server, application server, or agent impact the scale estimates?

Clustering addresses continued operation in the event of a failure. It does not address performance. The scale estimates produced by this document represent the minimum number of computers required to support a given workload. A clustered environment requires additional computers. You should use the estimates provided in this document to ensure that, in the case of a failure, the remaining components continue to operate.

Monitors that measure response time by simulating a client request can require property tuning in order to avoid response time skew. See “Tested environment for concurrent users” on page 72.

Is there any recommendation if baselining is done for all metrics (non-KPIs)?

No. In a controlled lab for a large environment, we were able to scale up to 200,000 metrics only.


Where to view the latest product information

Where to view the latest product informationThe latest product information is available on the Customer Support website at http://www.bmc.com/support.

From the Customer Support site, you can perform several tasks, including:

■ Viewing the latest product documentation (manuals, release notes, flashes, technical bulletins, online Help, and parameter information).

■ Subscribing to proactive alerts to receive e-mail messages that inform you of new release notes, flashes, and technical bulletins for your products.

■ Searching for existing product resolutions and frequently asked questions (FAQs).

TIP If you do not already have a user name and password that allow you to fully access the Customer Support site, you can register for a user name and password on the site.

© Copyright 2011 BMC Software, Inc.

BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with the U.S. Patent and Trademark Office, and may be registered or pending registration in other countries. All other BMC trademarks, service marks, and logos may be registered or pending registration in the U.S. or in other countries. All other trademarks or registered trademarks are the property of their respective owners.

Linux is the registered trademark of Linus Torvalds.

IBM, DB2 Universal Database, iSeries, Informix, Lotus, Domino, and WebSphere are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both.

UNIX is the registered trademark of The Open Group in the US and other countries.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

SAP and R/3 are trademarks or registered trademarks of SAP AG in Germany and in several other countries.

BMC Software considers information included in this documentation to be proprietary and confidential. Your use of this information is subject to the terms and conditions of the applicable End User License Agreement for the product and the proprietary and restricted rights notices in the product documentation.

BMC SOFTWARE INC2101 CITYWEST BLVD, HOUSTON TX 77042-2827, USA• 713 918 8800Customer Support: 800 537 1813 (United States and Canada) or contact your local support center


http://www.bmc.com/support

bppm best practices performance scalability

Documents