Performance tuning

This topic provides recommendations for tuning your environment for the best performance. These recommendations are based on the testing results obtained for the embedded PostgreSQL database.

Advanced configuration settings

This section contains information about the advanced configuration settings for TrueSight Network Automation.

Right-sizing the Java heap

Use the following guidelines to estimate the setting for initial and maximum memory based on the number of devices. The actual values depend on how your system is used. If required, these values can be adjusted later.

Number of devices

Recommended initial memory

Recommended maximum memory

Up to 1000

1024 MB

2048 MB

1001–5000

1024 MB

4096 MB

5001–25,000

1024 MB

16,384 MB

Note

The default values for the initial memory and maximum memory are 1024 MB and 2048 MB. If you want to modify these values for performance improvement, run the installation program again and modify the values of the Initial Memory Allocation and Maximum Memory Allocation parameters on the Memory and System Options panel.


Recommendations

If you upload OS images larger than 300 MB, the maximum Java heap size must be set to process large files. BMC recommends that you set your maximum Java heap size to three times your maximum OS image file size.

Setting maximum threads and database connections

The administrator can set the maximum number of threads that can be concurrently running by setting the maxConcurrentDeviceActions parameter in the global.properties.imported file.

Example
#
# Maximum number of device action threads that can be executing concurrently
# at any one time via our DeviceTaskManager thread pooling mechanism. Note
# the system will force the maximum number of allowed db connections
# (versant.maxActive) to be:
# 2 x maxConcurrentDeviceActions + "additionalDBConnections" (global.properties).
# If this turns out to be over 170, you will have to bump up the max_connections
# value in postgresql.conf in Postgres to match it.
# Default = 20
#
# maxConcurrentDeviceActions=20

You can set the additionalDBConnections setting in the global.properties file as follows:

Example
# The additional number of db connections required in excess of twice
# the number of maxConcurrentDeviceActions threads allowed. These excess
# connections are reserved for other misc system activity (e.g. browser and web
# service connections, system background activities).
# Affects versant.maxActive in database.properties. See the description of
# versant.maxActive for details.
# additionalDBConnections=30

If the values you specify for the maxConcurrentDeviceActions and additionalDBConnections parameters lead to a need for more than 170 database connections (according to the "(2 x maxConcurrentDeviceActions) + additionalDBConnections" formula mentioned above), and you are using PostgreSQL, then you need to edit the postgresql.conf file to assign a higher value for the max_connections property. If you are using embedded PostgreSQL, Network Automation installation program appends the line max_connections = 170 to the bottom of the postgresql.conf file (located in the BCAN_DATA/db directory) automatically. You need to modify the value in this line. 

Use the following guidelines to estimate the setting for threads and database connections based on the number of devices. The actual values depend on how your system is used. If required, these values can be adjusted later.

Property to be set

File name

Up to 5000 devices

5001–25000 devices

reportThreadPoolSize

BCAN_DATA/global.properties

10 (default)

10

Embedded PostgreSQL database

maxConcurrentDeviceactions

BCAN_DATA/global.properties.imported

20 (default)

120

maxConnections

BCAN_DATA/db/postgresql.conf

180 (default)

360

versant.l2CacheMaxObjects

BCAN_DATA/database.properties

20000 (default)

50000

versant.l2QueryCacheMaxQueries

BCAN_DATA/database.properties

1000 (default)

3000

Recommendations for optimizing performance

This section contains information about optimizing performance for Network Automation.

Application Server hardware recommendations

The application server specifications in the following table are based on the number of managed devices. These specifications are for a live production environment.

Application server hardware specifications

Number of managed devices

Processor speed

Number of processors

Memory 

Up to 5,000

3 GHz

2

8 GB

5001–25,000

3 GHz

8

24 GB

The application server and database can run on the same host computer or different host computers or virtual machines (VMs).

Note

When uploading OS images larger than 300 MB to Network Automation, the system running PostgreSQL must have enough RAM when Network Automation writes large OS image files to the database. BMC recommends that the system running PostrgeSQL have RAM greater than three times your maximum OS image file size.

If you are running the Network Automation application server and PostgreSQL on the same computer, make sure you have sufficient cumulative RAM.


Scheduled tasks

You can schedule the following tasks. For tasks that are resource-intensive, BMC recommends that they be staggered in their kick-off times so as not to run them simultaneously. Consider staggering the purge time, device imports of large numbers of devices, configuration exports of large spans of devices, jobs that run on large spans of devices like entire realm or entire network (for example, the nightly backup), and policies that send large reports.

  • Policies: A set of conditions that when met cause the system to perform a set of actions. The Policies tab is used to manage, schedule, and review the status of time and event-based policies. See Managing-policies.
  • Jobs: Network-related actions initiated by users, web services, policies, and device import tasks are tracked centrally as Jobs. Jobs are administered via Network > Actions > Jobs. See Managing-jobs.
  • Device import:
    • Administered via Admin > Network Admin > Device Import.
    • When creating a Device Import task, the administrator can schedule it to run now or later, and can set it to repeat if necessary.
    • See Managing-device-import-tasks.
  • Rule import/export:
    • Rule import is administered via Network > Import/Export > Rule Import.
    • Rule export is administered via Network > Import/Export > Rule Export.
    • When creating a Rule Import (or Export) task, the administrator can choose to run the task now or schedule it for later, and can set it to repeat if necessary.
    • See Importing-rules and Exporting-rules.
  • Configuration import/export:
    • Configuration Import is administered via Network > Import/Export > Configuration Import.
    • Configuration Export is administered via Network > Import/Export > Configuration Export.
    • When creating a Configuration Import (or Export) task, the administrator can choose to run the task now or schedule it for later, and can set it to repeat if necessary.
    • See Importing a configuration and Exporting a configuration .
  • Purge time:
    • Purge time is the time of day that when the purge manager runs. Purge manager deletes events, jobs, dormant policies, offline devices, historical configuration, and historical hardware inventories based on site policy. See Purge Settings for instructions on setting the purge policy.
    • Purge time is controlled by the purgeTime parameter in the global.properties file. The default is midnight. If this value is changed, it doesn't take effect until a restart of BCA-Networks Web Server occurs.

Remote databases

BMC recommends that you run the Network Automation database server and application server on the same computer (if possible), to minimize communication overhead between them. This assumes that the computer is powerful enough to handle the load of both the servers.

Note

If you use a remote Network Automation database server, ensure that the computer it runs on is of at least comparable power (in terms of speed and number of CPUs) as the computer on which the Network Automation application server is running.

Purge settings

Administrators can configure the system to purge events, jobs, policies, and historical configurations according to their requirements. To set the purge criteria for events, job, and policies, see the Purge Settings in the Managing system parameters page. To set the purge criteria for historical configurations, see Adding-or-editing-a-realm.

Logging

This section addresses settings for the Network Automation logging.

Logger

Network Automation uses the Java Logger for all logging. Refer to the following documentation for Logger details: http://docs.oracle.com/javase/7/docs/api/java/util/logging/Logger.html .

Log Levels

The supported log levels in descending order are:

  • SEVERE (highest value)
  • WARNING
  • INFO
  • CONFIG
  • FINE
  • FINER
  • FINEST (lowest value)

Log file maintenance

The administrator can configure logging by modifying the logging.properties file or editing the logging properties. The default log level can be set as follows:

Example
#
# Default log level for misc classes.
#
.level=WARNING

The administrator can also configure the size of the log files and the number of log files maintained.

Example
#
# FileHandler log configuration. Ena log messages will accumulate in
# BCA-Networks.log.0. Whenever it reaches 1 mb its contents will be rotated
# to BCA-Networks.log.1, and any existing BCA-Networks.log.1 file will be rotated
# to BCA-Networks.log.2, and so on up to BCA-Networks.log.4 (any existing
# BCA-Networks.log.4 file will be dropped). Restarts of ena will cause new
# log messages to be appended to the existing BCA-Networks.log.0 file.
#
java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter
java.util.logging.FileHandler.level=ALL
java.util.logging.FileHandler.pattern=%h/log/BCA-Networks.log.%g
java.util.logging.FileHandler.limit=1000000
java.util.logging.FileHandler.count=5
java.util.logging.FileHandler.append=true

Device-related logging

There are additional logging parameters for device-related logging. These are also set in the logging.properties file.

Example
# For debugging device data transfers; will not delete ena-*.tmp files;
# see device agent path settings for where these tmp file are located.
#
# com.bmc.bcan.agent.shared.imported.network.fileTransfer.TransferFile.level=ALL
# com.bmc.bcan.engine.network.devices.DeviceActionUtil.level=ALL

# For debugging device interactions, the following will include the data
# sent to and received from devices in the log in ascii and binary formats,
# as well as some trace of command processing and property setting.
#
# com.bmc.bcan.agent.shared.imported.network.util.level=ALL
# com.bmc.bcan.agent.shared.imported.network.devices.comm.level=ALL

# For debugging device imports; will not delete intermediate XML files; the
# files land in c:\windows\temp (windows) or BCA-Networks-Data/tmp (unix).
#
# com.bmc.bcan.engine.database.imports.DeviceImportTransformer.level=ALL

Reports

You can improve the performance of reports that display differences or discrepancy between the configurations such as Change Summary and Discrepancy Summary when the configuration is very large (> 50, 000 lines). You can switch to a faster GNU Diff-based BMSI package by performing the following steps:

  1. Download the BMSI gnudiff-1.7.jar file from http://search.maven.org/#search|ga|1|gnudiff.

  2. Place the BMSI gnudiff-1.7.jar file in the BCAN_HOME/tomcat/lib directory.

    Note

    On a Linux installation, ensure that the file owner and permissions match the other files in this directory.

  3. Do the following changes in the BCAN_DATA/global.properties file:
    1. Find the property named differencingEngine.
    2. Uncomment the line and set it to BMSI.

      The resultant line should look like: differencingEngine=BMSI
  4. Restart the web server service.

Related topic

Tools-and-scripts

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*