Submit a ticketCall us

whitepaperYour VM Perplexities Called, and They Need You to Read This.

Virtualization can give you enormous flexibility with future workloads and can be a key enabler for other areas, like cloud computing and disaster recovery. So, how can you get a handle on the performance challenges in your virtual environment and manage deployments without erasing the potential upside? Learn the four key areas you need to be focusing on to help deliver a healthy and well-performing data center.

Get your free white paper.

Home > Success Center > Server & Application Monitor (SAM) > SAM Documentation > Scalability Engine Guidelines for Server & Application Monitor

Scalability Engine Guidelines for Server & Application Monitor


Created by Caroline Juszczak, last modified by Lori Krell_ret on Mar 28, 2017

Views: 753 Votes: 0 Revisions: 4

Using Orion Scalability Engines 


SAM Scalability Engine Guidelines

Stackable Polling Engines

SAM 6.3 and later

2 polling engines can be installed on a single server.

Remote Office Poller

SAM 5.5 and later

Main Polling Engine Limits

~8 — 10K component monitors per polling engine

25 — 50 concurrent Orion Web Console users

Scalability Options

One Additional Polling Engine (APE) for every 8 — 10K component monitors.

Maximum of 150K component monitors per primary SAM installation (1 Orion server + 14 APEs). 

Starting in Orion Platform 2018.2, a maximum of 100 APEs per instance.

WAN and/or Bandwidth Considerations

Minimal monitoring traffic is sent between the Orion server and any APEs connected over a WAN. Most traffic related to monitoring is between an APE and the Orion database server.

Bandwidth requirements depend on the size of the relevant component monitor. Based on 67.5 kB / WMI poll and a 5-minute polling frequency, the estimate is 1.2 Mbps for 700 component monitors. See How do SNMP and WMI polling compare?

WMI is best suited for environments where latency is < 100ms. See also WMI Security Blog.

Scalability Engine Deployment Options

Installing Additional Polling Engines

Activating Stackable Poller Licenses

Frequently Asked Questions

Does each module have its own polling engine?

No, an Additional Polling Engine may have all relevant modules installed on it, and it performs polling for all installed modules. An Additional Polling Engine works the same way as your Main Polling Engine on your main server.

For example, if you have NPM and SAM installed, install one Additional Polling Engine and it performs polling for both NPM and SAM.

Are polling limits cumulative or independent? For example, can a single polling engine poll 12k NPM elements AND 10k SAM monitors together?

Yes, a single polling engine can poll up to the limits of each module installed, if sufficient hardware resources are available.

Are there different size license available for the Additional Polling Engine?

No, the Additional Polling Engine is available with an unlimited license.

Can you add an Additional Polling Engine to any size module license?

Yes, you can add an Additional Polling Engine to any size license.

Adding an Additional Polling Engine does not increase your license size. For example, if you are licensed for an NPM SL100, adding an Additional Polling Engine does not increase the licensed limit of 100 nodes/interfaces/volumes, but the polling load is spread across two polling engines.

What happens if the connection from a polling engine to the Orion Database Server is lost?

If there is a connection outage to the Orion Database Server, polling engines use Microsoft Message Queuing (MSMQ) to cache the polled data on the Additional Polling Engine servers.

The amount of data that can be cached depends on the disk space available on the polling engine server. The default storage space is 1 GB. Up to one hour of data can be cached.

When the connection to the database is restored, the Orion Database Server is updated with the locally cached data, the oldest data is processed first.

If the database connection is broken for a longer than an hour, the collector queue becomes full, the newest data is discarded until a connection to the database is re-established.






Last modified