BPPM Best Practices Performance Scalability

Best Practices for BMC ProactiveNet Performance Management Performance and Scalability
Version: 8.6 July, 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.
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.
This document contains the following topics: Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Deployment Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Sizing a BMC ProactiveNet environment for data collection . . . . . . . . . . . . . . . . . . 4 Additional guidelines for a data collection environment . . . . . . . . . . . . . . . . . . . . . 8 Adapter data collection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Hardware requirements for BMC ProactiveNet server . . . . . . . . . . . . . . . . . . . . . . 12 Hardware requirements for Business Objects reporting . . . . . . . . . . . . . . . . . . . . . 13 Hardware requirements for Remote Agent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Hardware requirements for Oracle Database Server . . . . . . . . . . . . . . . . . . . . . . . . 14 Oracle Database tuning recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Data management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Data management sizing recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Data management sizing chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Data management tuning recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 BMC ProactiveNet Server Bandwidth Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Time consumed by different functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Event management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Event management sizing recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Event management sizing chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Event management tuning recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 *204678* *204678*
*204678*
Time consumed by different functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact Management sizing recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact Management sizing chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact Management tuning recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . Time consumed by different functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Recommended AR configuration settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Recommended AR System Mid-Tier configuration settings . . . . . . . . . . . . . . . . . Recommended AR Application Server configuration settings. . . . . . . . . . . . . . . . Hybrid management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hybrid management sizing recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hybrid management sizing chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hybrid management tuning recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cloud management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cloud management sizing recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cloud Management hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware requirements for Servers in Cloud Management . . . . . . . . . . . . . . . . . Cloud Management sizing chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtual Center details used for monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reports Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Event Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Component performance and tuning recommendations. . . . . . . . . . . . . . . . . . . . . . . . Disk subsystems and database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CPU guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration and deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tested environment for concurrent users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Frequently asked questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Where to view the latest product information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32 35 35 38 39 40 41 42 47 51 51 54 55 57 58 62 62 63 65 66 66 67 68 70 70 70 71 72 73 76
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
Introduction
Introduction
BMC 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 Guidelines

This 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.
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 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
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.
Table 1
The total number of attributes in sample scenario 1 using BMC PATROL for data collection
Instances 7000 5300 12,300 Attributes per device 75 180 255 Estimated attributes 220,000 580,000 800,000
BMC Performance Managers PATROL for UNIX and Linux PATROL for Microsoft Windows Totals
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 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. Table 2
Recommendations on the number of attributes per BMC ProactiveNet Server for data collection with a polling rate of 5 minutes Attributes monitored 50 K or less 50 K400 K 400 K-800 K Events per day 2 K or less 2 K5 K 10 K CPU 2 4 8 Memory 8 GB 16 GB 32 GB Hard Drive 100 GB 200 GB 300 GB
Architecture Small Medium Large
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. Table 3 Recommendations on the number of attributes per 32-bit BMC ProactiveNet Agent
BMC PATROL Adapter BMC Adapter VMWare Adapter TM-ART Adapter
Monitor type Number of attributes (Polling Interval: 5 minutes stats poll and 15 minutes auto-sync)
125,000
125,000
50,000
45,000
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
Additional guidelines for a data collection environment
Table 4
Recommendations on the number of attributes per 64-bit BMC ProactiveNet Agent

Number of attributes 800,000 Polling interval 5 minutes stats poll 15 minutes auto-sync) Monitor instance 90 K to 100 K
Monitor type BMC PATROL Adapter
NOTE
The 800,000 attributes monitored through PATROL Agents were from static KMs and with KPI mode.
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
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.

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.
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 64bit 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:
10
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.
11
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 Hybrid Management 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 8 GB 4 GB 10 K SAS disk or SAN storage 8 GB 10 K SAS disk or SAN storage 8 GB 10 K SAS disk or SAN storage
RAM Storage configuration
10 K SAS disk or SAN storage
MEDIUM 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 16 GB 8 GB 10 K SAS disk or SAN storage 16 GB 10 K SAS disk or SAN storage 16 GB 10 K SAS disk or SAN storage
LARGE ENVIRONMENT
12
Hardware requirements for Business Objects reporting
Table 5
Hardware requirements for BMC ProactiveNet server in small, medium and large environments (part 2 of 2)
Data Management Event Management Hybrid Management Impact Management
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 32 GB 16 GB 32 GB 32 GB
Tier 1 SAN storage (2-4 Gbps SAN dedicated channel)
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. Table 6 Hardware requirements for Business Objects and Report Engine
Business Objects Operating system RAM Storage configuration Oracle Database

Report Engine
Windows 2008 R2 (64-bit), Intel Core i7, 2x4 Core, 3.067 GHz Frequency, 2400 MHz Bus-speed and 16 threads or equivalent 4 GB 80 GB Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production 4 GB 40 GB
13
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. Table 7 Hardware requirements for Remote Agent
Hybrid Management
Data Management SMALL ENVIRONMENT Operating system RAM Storage configuration MEDIUM ENVIRONMENT Operating system RAM Storage configuration LARGE ENVIRONMENT Operating system RAM Storage configuration

Windows 2008 R2 (64-bit), Intel Core i7, 2x4 Core, 3.067 GHz Frequency, 2400 MHz Bus-speed and 16 threads or equivalent 4 GB 4 GB 10 K SAS disk or SAN storage
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.
14
Hardware requirements for Oracle Database Server
Table 8
Hardware requirements for Oracle Server

Data Management Event Management Hybrid Management Impact Management Business Objects Reporting
Operating system RAM Storage configuration Oracle database
Windows 2008 R2 (64-bit), Intel Core i7, 2x4 Core, 3.067 GHz Frequency, 2400 MHz Bus-speed and 8 threads or equivalent 16 GB 16 GB 16 GB 16 GB 16 GB
200 GB, 10 K SAS disk or SAN storage Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
15
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 alter system set processes = 1000 scope=spfile; alter system set sessions = 1000 scope=spfile; Description 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 number of processes and sessions
Setting the Sga_max_size Setting for Memory Allocation
lter system set sga_max_size=0 scope=spfile alter system set memory_max_target=8192M scope=spfile alter system set memory_target=8192M scope=spfile
Reset sga_max_size to 0 Set memory to half of the system memory Ex: If system as 16 GB of RAM then set to memory_max_target=8192 M
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; Setting of REDO02 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;
16
Table 9
Tuning recommendations for Oracle Database (part 2 of 2)

Parameter Value / Command alter database add logfile group Inactive group number ('Path\Redo Filename Without Group NumberInactive group number.LOG') size 500m reuse; Description To avoid "cannot allocate new log," Error For status of redo log file select group# , status from v$log;
Setting of REDO03
Check status of redo log files:
select group# , status from v$log; alter system switch logfile; alter system switch logfile;
Status of one redo log file should be CURRENT, and other two should be ACTIVE Alter audit_trail and scope values Add CONNECT_TIMEOUT_LIS TENER = 0 in listener.ora file
set audit_trail set scope set CONNECT_TIMEOU T_LISTENER
Alter system set audit_trail=none scope=spfile CONNECT_TIMEOUT_LISTENE R = 0
17
Data management
Data management
BMC 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.
18
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. 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 data collection agent residing on the 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.
19
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
Small environment DATA Number of devices Total parameters Monitor instances KPI Mode Polling interval: (Stats Poll, Auto-Sync) in minutes RATE retention Remote Agents Adapter Type RAW retention UI Concurrent operational users Concurrent admin Groups SLOs CONFIGURATION Jserver MaxHeap Rate MaxHeap Agent Controller MaxHeap Local Agent MaxHeap Remote Agent MaxHeap 2 GB 2 GB 1 GB 0.5 GB 4 GB 6 GB 4 GB 1.5 GB 0.5 GB 6 GB 8 GB 8 GB 2 GB 1 GB 8 GB 10 1 1K 20 20 1 2K 40 30 1 3K 60 2K 50 K 20 K Yes 5, 15; 5, 10; 5, 5; 2, 15 3 months 1 PATROL 8 days 5K 400 K 50 K Yes 5, 15; 5, 10; 5, 5; 2, 15 3 months 1 PATROL 8 days 10 K 800 K 90 K Yes 5, 15; 5, 10; 5, 5; 2, 15 3 months 1 PATROL 8 days Medium environment Large environment
20
Data management tuning recommendations
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 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. Table 11 Tuning parameters for data management (part 1 of 3)
File name Pnjserver.conf Description MaxHeap allocated to Jserver Process. MaxHeap allocated to Rate Process MaxHeap allocated to Agent Controller Process MaxHeap allocated for local agent Recommended value

Parameter name Heap tuning parameter MaxHeap for Jserver
Small: 2048 MB Medium: 6144 MB Large: 8192 MB Small: 2048 MB Medium: 4096 MB Large: 8192 MB Small: 1024 MB Medium: 1536 MB Large: 2048 MB Small: 512 MB Medium: 512 MB Large: 1024 MB Small: 1 G Medium: 2 G Large: 3 G Small: 1024 MB Medium: 2048 MB Large: 3072 MB
MaxHeap for Rate
Pnrate.conf
MaxHeap for Agent Controller MaxHeap for Agent (Local)
Pnagentcntl.conf
Pnagent.conf
BMC ProactiveNet database server parameter COMDefine -c (Windows) setenv dbsrvicache (Solaris) Cell tuning parameters EventDBSize Mcell.conf The number of events Set it higher for a retained in repository. higher event rate. pndbsrv.conf Initial cache size of database server Initial cache size of database server

startdbsrv7
21
Table 11
Tuning parameters for data management (part 2 of 3)

File name Mcell.conf Description Recommended value The minimum age in Set it lower if event rate is high. seconds of CLOSED events before they are removed from the repository. The maximum size in Kilobytes of a transaction file before it is transformed into a new saved state when the statebuilder runs again. Duration after which the agent status cache is refreshed on the agent controller. Frequency at which the agent writes a KEEPALIVE message to the agent controller. Number of retries the agent controller makes before marking an agent UNREACHABLE. Maximum number of threads permitted for the agent JVM (buffer 10% for the instances to be discovered). Frequency at which the agent controller polls each agent for status. This time is in milliseconds. This time is in seconds. This time is in seconds. This time is in seconds. Set it higher for a higher event rate to avoid frequent statebuilder runs.
Parameter name EventDBKeepClosed
StateBuildSize
Mcell.conf
Other tuning parameters pronet.apps.agent.age pronet.conf ntmon.agentstatusref reshperiod pronet.apps.agent.wa pronet.conf tchdog.sleeptime

Small: 45000 Medium: 90000 Large: 180000 Small: 30000 Medium: 60000 Large: 120000
pronet.apps.agent.pol pronet.conf lperiod.allowednorep lies.tcp
Small: 4 Medium: 4 Large: 4
pronet.jvm.maxthrea dlimit
pronet.conf
pronet.apps.agent.pol pronet.conf lperiod
pronet.jserver.cachem pronet.conf odule.threadpool.max .size pronet.jserver.databa pronet.conf semodule.threadpool. max.size pronet.jserver.dbconn pronet.conf ectionpool.maxdbcon nectionsize
Small: 10 Medium: 20 Large: 40 Small: 10 Medium: 20 Large: 40 Small: 15 Medium: 25 Large: 50
22
BMC ProactiveNet Server Bandwidth Utilization
Table 11
Tuning parameters for data management (part 3 of 3)

File name Description Number of DB connections the analytical engine (rate process) can make at one time. Agent controller worker pool size. Agent controller Database Writer max cache limit. MaxHeap allocated for Remote Agent. Frequency at which the agent writes a KEEPALIVE message to the agent controller. Maximum number of threads permitted for the agent JVM (buffer 10% for the instances to be discovered). Frequency at which the agent controller polls each agent for status. This time is in milliseconds. Recommended value

Parameter name
pronet.rate.maxdbcon pronet.conf nections
pronet.apps.agentcon pronet.conf troller.msghandler.w orkerpoolsize pronet.apps.agentcon pronet.conf troller.dbwriter.max msgcachelimit Remote Agent tuning parameters MaxHeap for Remote pronet.conf Agent pronet.apps.agent.wa pronet.conf tchdog.sleeptime
Small: 10 Medium: 20 Large: 30 Small: 50000 Medium: 50000 Large: 60000 Small: 2048 MB Medium: 6144 MB Large: 8192 MB Small: 50000 Medium: 50000 Large: 100000
pronet.jvm.maxthrea dlimit
pronet.conf
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).
23
Time consumed by different functions
BMC ProactiveNet Server BMC ProactiveNet version Operating System No. of processors Memory
Physical Server 8.6 Windows Server 2008 R2 8 32 G
BMC ProactiveNet Agent (PATROL Proxy enabled) BMC ProactiveNet version Operating System No. of processors Memory
Virtual machine 8.6 Windows Server 2008 R2 4 16 G
Bandwidth utilization Device Monitor instance Attributes Polling Average Network traffic measured for 2 Hours between BMC ProactiveNet server and BMC ProactiveNet Agent (PATROL Proxy) 10 K (1 K PATROL agents, 9 K systems) 125 K 850 K 5 minutes stats, 15 minutes auto sync 74,416 bytes per sec

The following is the pre-defined setup, before collecting values in BMC ProactiveNet.
Devices Groups Monitor Instance ProactiveNet event Attribute Polling Database size 10 K (1 K PATROL agents, 9 K systems) 2100 115 K 5 K per day 750 K 5 minutes stats, 15 minutes autosync 60 GB
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.
24
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). Time taken to restore BMC ProactiveNet Sybase Database
Backups 1 2 3 1 Incremental backup file 1 Full backup + 1 incremental backups file 1 Full backup + 6 incremental backups file Time taken to restore 30 minutes 1 hour 3.5 hours
Table 12
No.
The following table shows the Remote BMC ProactiveNet Agent start times with Sybase Database and Oracle Database. Table 13
No. 1 2
Remote BMC ProactiveNet Agent start-up times with Data Management setup
Agent start time with Sybase Database Oracle Database Time taken in minutes 7 8
The following table shows the start-up times for BMC ProactiveNet processes. Table 14
httpd 1 second
Start-up times for BMC ProactiveNet Processes for Data Management

jserver pronet_ agnet pronet_cntl tunnelproxy 2 seconds rate mcell acell 1 second
8 minutes 4 seconds 5 minutes
12 minutes 1 second
25
Event management
Event management
BMC 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. Small BMC ProactiveNet event management environment
Figure 3
26
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. Medium BMC ProactiveNet event management environment
Figure 4
27
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. Large BMC ProactiveNet event management environment
Figure 5
28
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.
Table 15
BMC ProactiveNet sizing chart for event management

Small environment Medium environment Large environment
UI Concurrent operational users* Concurrent admin Groups EVENT Intelligent events per day External events per day Event adapters Remote cells Event DB size Event DB keep closed State build size Event retention Static event collectors Levels for collectors Remote agents Number of event adapters CONFIGURATION Jserver MaxHeap Rate MaxHeap Agent Controller MaxHeap Local Agent MaxHeap Remote Agent MaxHeap 2 GB 2 GB 1 GB 0.5 GB N/A 4 GB 4 GB 1.5 GB 0.5 GB N/A 8 GB 8 GB 2 GB 0.5 GB N/A 0 100 K 2 5 default default default default 10 5 0 2 0 200 K 5 10 300 K default default default 25 5 0 5 0 400 K 10 20 530 K default default default 50 5 0 10 10 1 100 20 1 250 30 1 500
* Concurrent operational user interacts with BMC ProactiveNet Operational Web-based user interface 24 hours a day 7 days a week.
29
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)
File name Pnjserver.conf Description MaxHeap allocated to JServer Process. Recommended value

Small: 2048 MB Medium: 4096 MB Large: 8192 MB Small: 512 MB Medium: 512 MB Large: 512 MB
MaxHeap for Agent (Local) Cell tuning parameters EventDBSize EventDBKeepClosed
Pnagent.conf
MaxHeap allocated for local agent
Mcell.conf Mcell.conf
The number of events Set it higher for a retained in repository. higher event rate. The minimum age in Set it lower if event rate is high. seconds of CLOSED events before they are removed from the repository. The maximum size in Kilobytes of a transaction file before it is transformed into a new saved state when the statebuilder runs again. Duration after which the agent status cache is refreshed on the agent controller. Frequency at which the agent writes a KEEPALIVE message to the agent controller. Number of retries the agent controller makes before marking an agent UNREACHABLE. Set it higher for a higher event rate to avoid frequent statebuilder runs.
StateBuildSize
Mcell.conf
Other tuning parameters pronet.apps.agent.age pronet.conf ntmon.agentstatusref reshperiod pronet.apps.agent.wa pronet.conf tchdog.sleeptime

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

File name pronet.conf Description Maximum number of threads permitted for the agent JVM (buffer 10% for the instances to be discovered). Frequency at which the agent controller polls each agent for status. This time is in seconds. This time is in seconds. Number of Max Database connections. Recommended value

Parameter name pronet.jvm.maxthrea dlimit
Small: 45000 Medium: 90000 Large: 180000 Small: 10 Medium: 20 Large: 40 Small: 10 Medium: 20 Large: 40 Small: 15 Medium: 25 Large: 50
pronet.jserver.cachem pronet.conf odule.threadpool.ma x.size pronet.jserver.databa pronet.conf semodule.threadpool. max.size pronet.jserver.dbconn pronet.conf ectionpool.maxdbcon nectionsize
31

The following table lists the predefined multi-cell setup, before collecting values in BMC ProactiveNet.
Devices Events to master cell Number of collection cells Events to collection cells Groups 10 K (1 K PATROL agents, 9 K systems) 200 K per day 10 30 K per day 500
The following table shows the multi-cell setup details with number of Master cell and collection cells configured in BMC ProactiveNet. Table 17
For load Operating system Event Rate to Master cell Event Rate to Collection cells (collection cells were configured with rule-based processing) Duration of streaming 20 K Events per day for collection cells Duration of streaming 30 K Events per day for collection cells
Event rate for Master cell and collection cells

500 K Events per day Windows 2008 R2 (64-bit), 2x4 Core, 3 GHz 200 K Events per day 30 K Events per day 7 days 6 days
32
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. Table 18 CPU and Memory consumption by BMC ProactiveNet process with Event rush
200 K Events per day for Master cell 200 K Events per day for Master cell and 20 K Events per Day and 30 K Events per Day for collection cells for collection cells CPU PnAgent PwTray acell dbsr httpd jserver mcell pronet_cntl rate services tunnelproxy 5% 0.5% 0.1% 1% 0.2% 4% 10% 0.05% 0.15% 0.2% 0.05% Memory 120MB 4MB 11MB 230MB 55MB 2700MB 900MB 90MB 190MB 33MB 20MB CPU 5% 0.5% 0.05% 1% 0.25% 3% 10% 0.05% 0.025% 0.15% 0.025% Memory 120MB 4MB 12MB 300MB 55MB 3000MB 1000MB 90MB 180MB 30MB 20MB
Process
The following table shows time consumed to start by all BMC ProactiveNet processes with multi-cell setup. Table 19
httpd 25 seconds
Start-up times for BMC ProactiveNet processes for Event Management

jserver 11 minutes pronet_ agnet 3 minutes pronet_ cntl 15 seconds tunnel proxy 17 seconds rate 15 minutes mcell 3 second acell 30 second
33
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
20 K Events per day for for collection cells CPU mcell_cell1 mcell_cell2 mcell_cell3 mcell_cell4 mcell_cell5 mcell_cell6 mcell_cell7 mcell_cell8 mcell_cell9 mcell_cell10 0.50% 0.50% 0.50% 0.50% 0.50% 0.03% 0.50% 0.08% 0.06% 0.03% Process Size 180MB 100MB 160MB 180MB 180MB 45MB 180MB 60MB 180MB 100MB 30 K Events per day for collection cells CPU 0.50% 0.50% 0.50% 0.50% 0.50% 0.02% 0.50% 0.05% 0.50% 0.03% Process size 190MB 180MB 200MB 200MB 190MB 60MB 190MB 80MB 190MB 100MB
Collection cells
34
Impact Management
Impact Management
BMC 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. Small BMC ProactiveNet Impact Management environment
Figure 6
35
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:

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. The BMC Atrium CMDB feeds configuration items and relationships to the BMC ProactiveNet Server with automated and manual publish mode. Medium BMC ProactiveNet Impact Management environment
Figure 7
36
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. The BMC Atrium CMDB feeds configuration items and relationships to the BMC ProactiveNet Server with automated and manual publish mode. Large BMC ProactiveNet Impact Management environment
Figure 8
37
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

Small environment Medium environment Large environment
UI Concurrent operational users Concurrent Admin IMPACT CIs in CMDB Services in CMDB CIS in ProactiveNet Server CIS per cell CIS in ProactiveNet Server CIS per Service Model (Max) Services in ProactiveNet Server CONFIGURATION Jserver MaxHeap Rate MaxHeap Agent Controller MaxHeap Local Agent MaxHeap Remote Agent MaxHeap 2 GB default default default N/A 4 GB default default default N/A 8 GB default default default N/A 100 K 15 5K 5K 5K 2K 15 100 K 25 10 K 10 K 10 K 5K 25 100 K 50 20 K 20 K 20 K 10 K 50 10 1 20 1 30 1
38
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)
File name Pnjserver.conf Description MaxHeap allocated to JServer Process. Recommended value

Small: 2048 MB Medium: 4096 MB Large: 8192 MB Small: 512 MB Medium: 512 MB Large: 512 MB
MaxHeap for Agent (Local) Cell tuning parameters EventDBSize
Pnagent.conf
MaxHeap allocated for local agent
Mcell.conf
The number of events Set it higher for a retained in higher event rate. repository. The minimum age in Set it lower if event seconds of CLOSED rate is high. events before they are removed from the repository. The maximum size in Kilobytes of a transaction file before it is transformed into a new saved state when the statebuilder runs again. Duration after which the agent status cache is refreshed on the agent controller. Frequency at which the agent writes a KEEPALIVE message to the agent controller. Number of retries the agent controller makes before marking an agent UNREACHABLE. Set it higher for a higher event rate to avoid frequent statebuilder runs.
EventDBKeepClosed
Mcell.conf
StateBuildSize
Mcell.conf
Other tuning parameters pronet.apps.agent.ag pronet.conf entmon.agentstatusre freshperiod pronet.apps.agent.wa pronet.conf tchdog.sleeptime

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

File name pronet.conf Description Maximum number of threads permitted for the agent JVM (buffer 10% for the instances to be discovered). Frequency at which the agent controller polls each agent for status. This time is in milliseconds. This time is in seconds. This time is in seconds. Number of Max Database connections. Maximum time for the cell to reply success or failure of the upload. For large models, BMC recommends to have a larger value. Recommended value

Parameter name pronet.jvm.maxthrea dlimit
pronet.jserver.cachem pronet.conf odule.threadpool.ma x.size pronet.jserver.databa pronet.conf semodule.threadpool. max.size pronet.jserver.dbconn pronet.conf ectionpool.maxdbcon nectionsize DestinationBufferKee smmgr.conf pSent

The following table lists the predefined setup, before collecting values in BMC ProactiveNet.
No CIs No Service Models No of Levels No Events per day 20 K 4 6 100 K
40
Recommended AR configuration settings
The following table shows time consumed by all BMC ProactiveNet processes with Impact setup. Table 23
httpd
Start-up times for BMC ProactiveNet processes with Impact setup

jserver pronet_ cntl tunnel proxy rate mcell acell Agent controller
2 seconds 2 minutes 1 minute 1 minute 1 minute 4 seconds 1 minute 1 minute 53 seconds 26 seconds 1 second 18 seconds 1 second 22 seconds
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.
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.
41
Recommended AR System Mid-Tier configuration settings

Table 24 Recommended AR System Mid-Tier configuration settings (part 1 of 5)
Location of configuration file Configuration Parameter and Value Setting Limitations
Setting
Value
Manual Steps
Definition 86400 sec Change Check Interval
arsystem.cache_up midtier_install_dir date_interval=8640 0 /WEBINF/classes/c onfig.properti es
Generic 1. Login to http://hostname/arsys/s hared/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
Pooling max total connections
80 (default)
arsystem.pooling_ midtier_install_dir max_connections_ per_server=80 /WEBINF/classes/c onfig.properti es
Generic 1. Login to http://hostname/arsys/s default hared/config/config.jsp with default password arsystem 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.
Resource 86400 sec Check Interval
arsystem.resource midtier_install_dir _expiry_interval=8 6400 /WEBINF/classes/c onfig.properti es
1. Login to http://hostname/arsys/s hared/config/config.jsp with default password arsystem 2. Click Cache Settings link on left navigation. 3. In Resource Check Interval field, enter 86400. 4. Click Save Changes.
Generic / company policy determined
42
Table 24
Recommended AR System Mid-Tier configuration settings (part 2 of 5)

Location of configuration file midtier_install_dir /WEBINF/classes/c onfig.properti es Configuration Parameter and Value arsystem.ehcache. diskPersistent=tru e arsystem.ehcache. overflowToDiskTe mp=false Setting Limitations
Setting Cache persistence
Value Enable
Manual Steps
Generic 1. Login to http://hostname/arsys/s hared/config/config.jsp with default password arsystem 2. Click Cache Settings link on left navigation. 3. Check the Enable Cache Persistence box. 4. Click Save Changes.
Prefetch Forms
Enable
midtier_install_dir /WEBINF/classes/p refetchConfig. xml
Change contents of XML. Refer to Mid-Tier Guide document for detailed steps on what to change.
Company 1. Login to http://hostnamearsys/sh policy determined ared/config/config.jsp with default password arsystem 2. Click Cache Settings link on left navigation. 3. Refer to Mid-Tier Guide document for detailed steps on what to change. 4. Click Save Changes.
Log setting -> Server log level
arsystem.log_level midtier_install_dir =Severe /WEBINF/classes/c onfig.properti es
Generic / 1. Login to http://hostname/arsys/s production hared/config/config.jsp only with default password arsystem 2. Click Log Settings link on left navigation. 3. In Log Level menu, select Severe. 4. Click Save Changes.
Form expiration
3600 sec
arsystem.formhtml N/A midtier_install_dir js_expiry_interval =3600 /WEBINF/classes/c onfig.properti es
Generic
43
Table 24

Location of configuration file Configuration Parameter and Value Setting Limitations
Setting
Value
Manual Steps In Windows:
JVM heap min 1 GB and max heap size
In Windows, it In Windows: is present in Name:JvmMs the registry: HKEY_LOCA L_MACHINE \SOFTWARE \Apache Software Foundation\P rocrun 2.0\Tomcat5\ Parameters\Ja va Type:REG_DWOR D Data: (decimal) 1024 Name:JvmMx Type:REG_DWOR D
Hardware configuration 1. Start -> BMC Software -> based 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.
Data: (decimal) In Unix, it is 1024 located in tomcat_install_ dir/bin/catali In Unix: na.sh JAVA_OPTS=Xms1024m Xmx1024m
In Unix: None.
44
Table 24

Location of configuration file Configuration Parameter and Value Setting Limitations Hardware configuration based
Setting Tomcat max threads
Value 500
Manual Steps
tomcat_install_ Look for your web dir/conf/serv servers connector er.xml port number. Default is 8080. Each connector has the maxThreads parameter. Connector URIEncoding=" UTF-8" acceptCount=" 100" connectionTim eout="20000" disableUpload Timeout="true " enableLookups ="false" maxHttpHeader Size="8192" maxSpareThrea ds="75" maxThreads="5 00" minSpareThrea ds="25" port="8080" redirectPort= "8443"/
45
Table 24

Location of configuration file Configuration Parameter and Value Setting Limitations Hardware configuration based
Setting
Value
Manual Steps
Tomcat accept 100 count
tomcat_install_ Look for your web dir/conf/serv servers connector er.xml port number. Default is 8080. Each connector has the acceptCount parameter. Connector URIEncoding=" UTF-8" acceptCount=" 100" connectionTim eout="20000" disableUpload Timeout="true " enableLookups ="false" maxHttpHeader Size="8192" maxSpareThrea ds="75" maxThreads="5 00" minSpareThrea ds="25" port="8080" redirectPort= "8443"/
46
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)

Configuration Parameter and Value Delay-Recache- None Time: 300 Max-EntriesPer-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. Setting Limitations Generic Generic
AR Server threads
Value
Manual Steps
Set Delay5 minutes Recache-Time (300 seconds) Max-EntriesPer-Query 0
Next-Idblock-size
100
Next-ID-BlockSize: 100
1. Open AR System Administration Server Information. 2. Go to Configuration Tab. 3. In Next Request ID Block Size field, enter 100. 4. Click OK.
Generic
1000 Server-SideTable-ChunkSize
Server-SideTable-ChunkSize: 1000
1. Open AR System Administration Server Information. 2. Go to Configuration Tab. 3. In Server Table Field Chunk Size field, enter 1000. 4. Click OK
Generic
47
Table 25
Recommended AR Application Server configuration settings (part 2 of 2)

Configuration Parameter and Value Allow-UnqualQueries: F Setting Limitations Generic / company policy determined
AR Server threads Unqualified Searches
Value Uncheck
Manual Steps 1. Open AR System Administration Server Information. 2. Go to Configuration Tab. 3. Uncheck Allow Unqualified Searches. 4. Click OK.
Development Uncheck Cache mode
Cache-Mode: 0
1. Open AR System Administration Server Information. 2. Go to Configuration Tab. 3. Uncheck Development Cache Mode. 4. Click OK.
Production only
Turn off all logging
Debug-mode: 0 Uncheck Logging (API/SQL/Fil ter) along with other logging
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
SubmitterMode: 1
1. Open AR System Administration Server Information. 2. Go to License Tab. 3. Select Locked for Submitter Mode. 4. Click OK. 5. Restart AR Server.
Generic / company policy determined
48
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 Private-RPC-Socket: 390603 1 1 Private-RPC-Socket: 390620 6 6 Private-RPC-Socket: 390626 3 3 Private-RPC-Socket: 390635 6 6 Fast and List thread settings are hardware configuration based limitation. There is no configuration file to configure the Customer Access Interface (CAI) plugin 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.
49
CAI plugin registry setting is a hardware configuration limitation and dependent on fast/list thread settings. Table 26 Fast and List thread settings
No. of Threads (min / max) 1 1 Ensure there are escalations using these threads. 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 Set min and max to the same number
Queue Number Private-RPC-Socket: 390601 Private-RPC-Socket: 390603
Purpose PAlert Queue Escalation Queue
Comments
Private-RPC-Socket: 390620 Private-RPC-Socket: 390626
Fast Queue Loopback Socket Queue / CAI Thread
6 3
Private-RPC-Socket: 390635
List queue
Below is an example of the AR Server Configuration screen and the CAI Plugin Registry screen. Note that values have to match.
50
Hybrid management
Hybrid management
Hybrid 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.
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.
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.
51
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. 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 larger number of attributes. You can deploy agents within a 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 it 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 data collection agent residing on the 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. 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 different system (Please see BMC Atrium CMDB documents for Hardware requirement)
52
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. 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 scale to much higher attributes. Make sure the memory allocated for this agent is sufficient. You can deploy agents within a VM as long as the VM meets the resource requirements. 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. 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. BMC recommends that you tune the Java Virtual Machines (JVMs) as described in Tested environment for concurrent users on page 72. 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.
53
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)
Small environment DATA Number of devices Total parameters Monitor instances KPI Mode RAW retention RATE retention Remote Agents Adapter Type Polling interval: (Stats Poll, Auto-Sync) UI Concurrent operational users Concurrent admin Groups EVENT Intelligent events per day External events per day Event adapters Remote cells Event DB size Event DB keep closed State build size Event retention Static event collectors Levels for collectors 500 50 K 0 0 default default default default 0 0 1K 100 K 0 0 default default default default 0 0 2K 200 K 0 0 default default default default 0 0 10 1 100 20 1 300 30 1 700 2K 50 K 10 K YES default default 1 PATROL 5,15 5K 250 K 30 K YES default default 1 PATROL 5,15 10 K 500 K 65 K YES default default 1 PATROL 5,15 Medium environment Large environment
54
Hybrid management tuning recommendations
Table 27
BMC ProactiveNet sizing chart for hybrid management (part 2 of 2)

Small environment Medium environment 0 0 Large environment 0 0
Remote agents Number of event adapters CONFIGURATION Jserver MaxHeap Rate MaxHeap Agent Controller MaxHeap Local Agent MaxHeap Remote Agent MaxHeap
0 0
2 GB 2 GB 1 GB default 2 GB
4 GB 4 GB 1.5 GB default 4 GB
8 GB 8 GB 2 GB default 8 GB

Table 28 provides the JVM tuning guidelines for a server that performs both data collection and event management. Table 28 Tuning parameters for data and event management (part 1 of 2)
File name Pnjserver.conf Description MaxHeap allocated to Jserver Process. MaxHeap allocated to Rate Process Recommended value

Small: 2048 MB Medium: 4096 MB Large: 8192 MB Small: 2048 MB Medium: 4096 MB Large: 8192 MB Small: 1024 MB Medium: 1536 MB Large: 2048 MB Small: 512 MB Medium: 512 MB Large: 1024 MB Small: 2048 MB Medium: 4096 MB Large: 8192 MB
MaxHeap for Rate
Pnrate.conf
MaxHeap for Agent Controller MaxHeap for Agent (Local) MaxHeap for Agent (Remote) Cell tuning parameters EventDBSize
Pnagentcntl.conf MaxHeap allocated to Agent Controller Process Pnagent.conf MaxHeap allocated for local agent MaxHeap allocated for remote agent
Pnagent.conf
Mcell.conf
The number of events retained in repository.
Set it higher for a higher event rate.
55
Table 28
Tuning parameters for data and event management (part 2 of 2)

File name Mcell.conf Description The minimum age in seconds of CLOSED events before they are removed from the repository. The maximum size in Kilobytes of a transaction file before it is transformed into a new saved state when the statebuilder runs again. Duration after which the agent status cache is refreshed on the agent controller. Frequency at which the agent writes a KEEPALIVE message to the agent controller. Number of retries the agent controller makes before marking an agent UNREACHABLE. Maximum number of threads permitted for the agent JVM (buffer 10% for the instances to be discovered). Frequency at which the agent controller polls each agent for status. This time is in seconds. Recommended value Set it lower if event rate is high.
Parameter name EventDBKeepClosed
StateBuildSize
Mcell.conf
Set it higher for a higher event rate to avoid frequent statebuilder runs.
Other tuning parameters pronet.apps.agent.agen tmon.agentstatusrefres hperiod pronet.apps.agent.watc hdog.sleeptime pronet.conf

pronet.conf
pronet.apps.agent.pollp eriod.allowednoreplies. tcp pronet.jvm.maxthreadli mit
pronet.conf
pronet.conf
pronet.apps.agent.pollp eriod pronet.jserver.cachemo dule.threadpool.max.si ze pronet.jserver.database module.threadpool.ma x.size pronet.jserver.dbconne ctionpool.maxdbconnec tionsize pronet.rate.maxdbconn ections
pronet.conf
Small: 45000 Medium: 90000 Large: 180000 Small: 15 Medium: 20 Large: 40 Small: 15 Medium: 20 Large: 40 Small: 20 Medium: 25 Large: 50 Small: 25 Medium: 45 Large: 90
pronet.conf
pronet.conf
This time is in seconds.
pronet.conf
Number of Max Database connections. Number of DB connections the analytical engine (rate process) can make at one time.
pronet.conf
56
Cloud management
Cloud management
BMC 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 enduser 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?
57
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
58
Small deployment
Select the small template for deployments of 10,000 virtual devices. Figure 9 High level architecture for small BMC ProactiveNet Server deployment
59
Medium deployment
Select the medium template for deployments of 25,000 virtual devices. Figure 10 High level architecture for medium BMC ProactiveNet Server deployment
60
Large deployment
Select the large template for deployments of 50,000 virtual devices. Figure 11 High level architecture for large BMC ProactiveNet Server deployment
61
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.
Table 29
Server requirements for small, medium and large Cloud deployments

No. of BMC ProactiveNet Central Servers 1 1 1 No. of BMC ProactiveNet Servers 1 3 5 No. of BMC BladeLogic Servers 1 1 1
Environment Small Medium Large
No. of DCH 1 3 5
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 30
Hardware requirements for Servers in Cloud Management

BMC ProactiveNet Data Collection Host
BMC ProactiveNet Central Server Operating system RAM CPUs Storage configuration

BMC ProactiveNet Server
BMC BladeLogic Servers
Windows 2008 R2 (64-bit), 3 GHz, and 8 threads 8 GB 4 16 GB 4 16 GB 4 4 GB 2
62
Cloud Management sizing chart

Table 31 provides the number of monitor instances and attributes for small, medium and large environments. Table 31
Small Medium Large
Monitor instances and attributes in Cloud Management

Devices 10,000 30,000 50,000 Monitor Instances 25 K 75 K 125 K Attributes 45 K 135 K 225 K
Size of environment
Table 32 provides the parameter information for BMC ProactiveNet Central Server, BMC ProactiveNet Server and BMC ProactiveNet Data Collection Host in Cloud Management.
Table 32
Server
Tuning parameters for Cloud Management (part 1 of 3)

Parameter Name Max Heap for Jserver Max Heap for Rate Max Heap for Agent Controller Max Heap for Agent (Local) COMDefine - c File Name pnjserver.conf pnrate.conf pnagentcntl.conf Description Max Heap allocated for Jserver Process Max Heap allocated for Rate Process Max Heap allocated for Agent Controller Process Max Heap allocated for Agent Process Initial cache size for db server
Recommended Value
BMC ProactiveNet Central Server
Default Default Default
pnagent.conf pndbsrv.conf
Default Default
63
Table 32
Server

Parameter Name
Max Heap for Jserver Max Heap for Rate Max Heap for Agent Controller Max Heap for Agent (Local) COMDefine - c pronet.apps.agent. agentmon.agentst atusrefreshperiod pronet.apps.agent. watchdog.sleepti me pronet.apps.agent. pollperiod.allowe dnoreplies.tcp
File Name
pnjserver.conf pnrate.conf pnagentcntl.conf
Description
Max Heap allocated for Jserver Process Max Heap allocated for Rate Process Max Heap allocated for Agent Controller Process Max Heap allocated for Agent Process Initial cache size for db server Duration after which the agent status cache is refreshed on the agent controller. Frequency at which the agent writes a KEEPALIVE message to the agent controller. Number of retries the agent controller makes before marking an agent UNREACHABLE. Maximum number of threads permitted for the agent JVM (buffer 10% for the instances to be discovered). Frequency at which the agent controller polls each agent for status. This time is in seconds.
Recommended Value 4096 MB 4096 MB 2048 MB
BMC ProactiveNet Server
pnagent.conf pndbsrv.conf pronet.conf
1024 MB 3072 MB 180000
pronet.conf
120000
pronet.conf
pronet.jvm.maxthr eadlimit
pronet.conf
100000
pronet.apps.agent. pollperiod pronet.jserver.cach emodule.threadpo ol.max.size pronet.jserver.data basemodule.threa dpool.max.size pronet.jserver.dbc onnectionpool.ma xdbconnectionsize
pronet.conf
180000
pronet.conf
40
pronet.conf
40
pronet.conf
50
64
Virtual Center details used for monitoring
Table 32
Server

Parameter Name
Max heap for Agent pronet.apps.agent. watchdog.sleepti me pronet.jvm.maxthr eadlimit
File Name
pnagent.conf pronet.conf
Description
Max heap allocated for Agent Process Frequency at which the agent writes a KEEPALIVE message to the agent controller. Maximum number of threads permitted for the agent JVM (buffer 10% for the instances to be discovered). Frequency at which the agent controller polls each agent for status. This time is in milliseconds.
Recommended Value 8192 MB 120000
BMC ProactiveNet Data Collection Host
pronet.conf
100000
pronet.apps.agent. pollperiod
pronet.conf
180000
Virtual Center details used for monitoring

Table 33 provides details of the virtual centers used for monitoring. Table 33 Virtual Center details used for monitoring
Virtual Center 1 Version of the Virtual Center Used Number of Data Centers Number of ESX Servers Clusters Per VC Number of Resource Pools/VC Number of VMs 4.0.0, 208111 4 156 7 107 2300 Virtual Center 2 4.1.0,2587902 6 41 5 275 2900
65
Reports Management
Reports Management
BMC 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 templatesdisplay operator response time to an event, event counts, top event sources, and other event details. Impact report templatesdisplay 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
66
Event Reports
Event Reports
Table 34 shows the hardware consumed by Oracle database for 8 days with 200 K events per day. Table 34
No. 1
Oracle Database Size for 8 days with 200 K events per Day
Database size 2.78 GB Events rate 200 K per day Total Events 1650 K
Database Oracle
Table 35 shows the minimum CPU and memory consumption by events reports.
Table 35
No. 1 2 3 4
CPU and Memory consumption by Event Reports

CPU Usage < 5% < 5% < 15% < 20% Memory Used in MB 39 50 600 2252 Component Business Objects Business Objects BMC ProactiveNet Oracle
Process Crystalras.exe CMS.exe BMCProactiveNetReportEngine Oracle Server Process
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
67
Impact Reports
The following are pre-defined Event Reports Types generated by Business Objects reporting engine. Table 36 Pre-defined Event Reports Types generated by Business Objects
No. of records in report 323,832 63,007 2,579 1,266,750 1,072,836 Report type (file size) Excel (37 kb) PDF (142 kb) Excel (242 kb) PDF (821 kb) Excel (39 kb) PDF (124 kb) Excel, PDF Excel (39 kb) PDF (119 kb) Excel (17 kb) PDF (56 kb) Excel (13 kb) PDF (42 kb) Total time to generate reports (sec) 230 342 83 578 507
No. 1 2 3 4 5
File name BPPM01.02 - Event Summary by Priority and Event Class BPPM01.03 - Event Summary by Priority and Host BPPM01.03a - Event Summary by Priority and Host - Details BPPM01.04 - Event Summary by Priority and Location BPPM01.04a - Event Summary by Priority and Location Details BPPM01.05 - Event Summary by Priority and Object BPPM01.05a - Event Summary by Priority and Object - Details
6 7
2 1
15 79
Impact Reports
Table 37 shows the hardware consumed by Oracle database for 6 service models with 20 K CI and 6 levels. Table 37
No. 1
Oracle database size for 6 service models with 20 K CI and 6 levels

Database size 2000 K Service models 6 Total CIs 20 K Levels 6 Oracle
Database
Table 38 shows the minimum CPU and memory consumption by Impact Reports. Table 38
No. 1 2 3 4
CPU and memory consumption by Impact Reports

CPU Usage < 5% < 5% < 5% < 20% Memory Used in MB 39 47 320 2230 Component Business Objects Business Objects BMC ProactiveNet Oracle
Process Crystalras.exe CMS.exe BMCProactiveNetReportEngine Oracle Server Process
68
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. of records in report 371,647 1,699,979 1,884,025 1,892,027 Report Type (file size) Excel (24 kb), PDF (82 kb) Excel (17 kb), PDF (98 kb) Excel (12 kb), PDF (51 kb) Excel (34 kb), PDF (94 kb) Total time taken to generate reports (sec) 5 3 10 60
No. 1 2 3 4
File name BPPM05.01 - Component Availability BPPM05.01a - Component Availability - Details BPPM05.02a - Losses - Details BPPM05.03 - MTBF
69
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.
70
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.).
71
Tested environment for concurrent users
Tested environment for concurrent users

The 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.
72
Frequently asked questions

This 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.
73
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).
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6 74
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.
75
Where to view the latest product information
Where to view the latest product information

The latest product information is available on the Customer Support website at http://www.bmc.com/support.
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.
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).
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 INC 2101 CITYWEST BLVD, HOUSTON TX 77042-2827, USA 713 918 8800 Customer Support: 800 537 1813 (United States and Canada) or contact your local support center
76

BPPM Best Practices Performance Scalability

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

BPPM Best Practices Performance Scalability

Enviado por

Direitos autorais:

Formatos disponíveis

Best Practices for BMC ProactiveNet Performance Management Performance and Scalability

Version: 8.6 July, 2011 (revision)

Deployment Configuration Guidelines

Deployment Configuration Guidelines

Sizing a BMC ProactiveNet environment for data collection

Sizing a BMC ProactiveNet environment for data collection

Sizing using BMC PATROL Performance Manager

Estimate the total number of monitor instances

Calculate the total number of attributes

Sizing a BMC ProactiveNet environment for data collection

Sizing a BMC ProactiveNet environment for data collection

BMC ProactiveNet Server scaling recommendations

Architecture Small Medium Large

BMC ProactiveNet Agent scaling recommendations

Additional guidelines for a data collection environment

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

Monitor type BMC PATROL Adapter

network topology security

Additional guidelines for a data collection environment

BMC ProactiveNet Agent and Server considerations

Additional guidelines for a data collection environment

N-1 agent to hardware consolidation

BMC ProactiveNet Agent proxy

Adapter data collection

Adapter data collection

BMC PATROL Adapters BMC TM ART Adapters

BMC PATROL Adapters

Adapter data collection

BMC TM ART Adapters

SMALL ENVIRONMENT Operating system

RAM Storage configuration

10 K SAS disk or SAN storage

MEDIUM ENVIRONMENT Operating system

RAM Storage configuration

10 K SAS disk or SAN storage

Hardware requirements for Business Objects reporting

RAM Storage configuration

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

Hardware requirements for Business Objects reporting

Hardware requirements for Remote Agent

Hardware requirements for Remote Agent

10 K SAS disk or SAN storage

10 K SAS disk or SAN storage

10 K SAS disk or SAN storage

Hardware requirements for Oracle Database Server

Hardware requirements for Oracle Database Server

Hardware requirements for Oracle Server

Operating system RAM Storage configuration Oracle database

Oracle Database tuning recommendations

Oracle Database tuning recommendations

Tuning recommendations for Oracle Database (part 1 of 2)

Setting the number of processes and sessions

Setting the Sga_max_size Setting for Memory Allocation

Oracle Database tuning recommendations

Tuning recommendations for Oracle Database (part 2 of 2)

Check status of redo log files:

set audit_trail set scope set CONNECT_TIMEOU T_LISTENER

Alter system set audit_trail=none scope=spfile CONNECT_TIMEOUT_LISTENE R = 0

Data management sizing recommendations

Data management sizing recommendations

Data management sizing chart

Data management sizing chart

Data management tuning recommendations