Installation Recommendations


Where to Install the SentryOne Components

The SentryOne client, monitoring service, and database are typically installed as follows:

  • The SentryOne database is installed on a SQL Server instance on your network.
  • The SentryOne client is installed on your workstation computer(s) with network connectivity to the SentryOne database.
  • The SentryOne monitoring service is a Windows service and is installed on a dedicated server or VM with network connectivity to the SentryOne database server and monitored targets.
    • For monitoring cloud targets, the SentryOne monitoring service may be installed either on-premises, or on a Windows virtual machine (IaaS) in the respective cloud platform.

Note:  Installing the SentryOne database on Azure SQL Database Managed Instance is supported.

The SentryOne clients and monitoring services are each configured to connect to the same SentryOne database during setup. 

Important:  The SentryOne database must be installed on a SQL Server 2008 or higher instance. Azure SQL Database is not supported for the SentryOne database. For more information, see the System Requirements section.

Use Fast Storage for the SentryOne Database

High disk latency (>5ms per read IO avg, >1-2ms per write IO avg) can limit scalability and cause sluggishness with the SentryOne client. The greater the number of monitored targets, the more data is collected and stored in the SentryOne database, and the more fast storage becomes important. Modern flash or hybrid storage systems should be used for maximum scalability and performance.

Monitor the SentryOne Database (FREE)

You should always monitor the SentryOne database with SQL Sentry to ensure there are no CPU, memory, or disk bottlenecks. A free license is included in every SentryOne installation for this purpose. Simply add the SQL Server as a monitored target.

Install Components on the Same Network

Install the SentryOne client, monitoring service, and database on the same network for the best performance. For example, if the SentryOne client or monitoring service connect to a SentryOne database over a slow wide area network link or VPN over the internet, performance may suffer.

If a slow connection from your workstation to the SentryOne database is unavoidable, it is recommended to install the SentryOne client on a “jump box” on the same network as the database, and access it via RDP or another remote desktop technology.

Installing the SentryOne Monitoring Service and Database on the Same Computer

For smaller environments, you may want to install a monitoring service on the same SQL Server machine where the SentryOne database is located. Doing so minimizes network overhead for communications between the monitoring service and the database. However, bear in mind that they will share the same compute resources which may cause CPU contention. For more information, see System Requirements.

Installing Multiple SentryOne Clients and Monitoring Services

Depending on the size of your SQL Server environment, you may need to install multiple SentryOne clients and monitoring services. Typically, each DBA has the SentryOne client installed on their workstation, and enough monitoring services are installed to handle the monitored target load (see examples below).

Apply the SentryOne Scalability Pack for more than 250 Targets

The SentryOne Scalability Pack implements partitioned clustered columnstore indexing, In-memory OLTP, and additional optimizations to achieve maximum scalability and performance, with reduced CPU, memory, and disk requirements. Contact us at to schedule pack installation, which is free of charge. For more details, see the SentryOne & Microsoft Achieve SQL Server Monitoring Performance Goals blog post.

Clustering SentryOne Monitoring Services

Multiple monitoring services can be installed to handle more than 100 monitored targets, and/or to provide automatic redundancy and load balancing. There is no configuration required to implement a basic SentryOne cluster.

Note:  Install more than one monitoring service and connect each to the same SentryOne database during setup. They automatically distribute the monitoring load, and if one monitoring service fails, the remaining monitoring service(s) picks up the load automatically. For more information, see the Load Balancing and Fault Tolerance article.

Increased Fault Tolerance for the SentryOne Database

If increased fault tolerance is required for the SentryOne database, install the database on a clustered SQL Server instance.

Note:  Log shipping can also be used with the SentryOne database; however a separate SentryOne license is required for the standby server. Customers can obtain this standby license by visiting our Customer Portal and modifying the server name of their current license key to the name of the standby server and applying this license key to the SentryOne database on the standby server.

Note:  You can also host the SentryOne database on an Availability group.  For more information about Hosting the SentryOne database on an Availability group, see the Hosting SentryOne Database on an Availability group article. 

Important:  Due to performance considerations, we do not support Synchronous-commit mode for the Availability Group hosting the SentryOne database when monitoring over 200 targets or over high latency network links.

We recommend using Asynchronous-commit mode in this scenario.

See the following blogs from Microsoft for more information on this topic:

Implementation Examples - Estimates Only

Monitoring Services and Targets per Site:

Number of Monitoring ServicesMaximum Number of Monitored Targets Range

Each monitoring service requires a dedicated Windows server or VM with these minimum hardware specifications: 

4 cores 2.0+ GHz12 GB

Note:  If monitoring and alerting redundancy is required, more than one monitoring service should be installed in each site. When multiple monitoring services are installed in a site, use an n+1 approach to ensure that if a service fails, the remaining services will be able to handle the monitoring load.

Important:  The actual number of services needed to optimally monitor an environment is heavily dependent on several factors such as:

  • The number of databases on each target
  • The number of disks on each target
  • The workload on each target
  • Geographical placement of datacenters
  • The number of domains and the trust between those domains

SentryOne has settings to limit the maximum number of disks, databases, database files, and indexes to collect for each target, and these can be easily adjusted as needed. The SentryOne support team ( will work with you to ensure optimal configuration and performance.

SentryOne Database Server

Number of TargetsMinimum SpecsRecommended Specs
CPU4 cores 1.6GHz
Memory8 GB RAM
Storage10 GB
EC2 Classdb.m5.xlarge
CPU6 cores 2.0+GHz
Memory12 GB RAM
Storage15 GB
EC2 Classdb.m5.2xlarge
CPU6 cores 1.6GHz
Memory12 GB RAM
Storage20 GB
EC2 Classdb.m5.2xlarge
CPU8 cores 2.0+GHz
Memory16 GB RAM
Storage30 GB
EC2 Classdb.m5.2xlarge
CPU8 cores 1.6GHz
Memory20 GB RAM
Storage50 GB
EC2 Classdb.m5.2xlarge
CPU8 cores 2.0+GHz
Memory32 GB RAM
Storage75 GB
EC2 Classdb.m5.2xlarge
CPU8 cores 1.6GHz
Memory24 GB RAM
Storage100 GB
EC2 Classdb.m3.2xlarge
CPU8 cores 2.0+GHz
Memory32 GB RAM
Storage150 GB
EC2 Classdb.m5.2xlarge
CPU8 cores 1.6GHz
Memory48 GB RAM
Storage200 GB
EC2 Classdb.r3.2xlarge
CPU12 cores 2.0+GHz
Memory64 GB RAM
Storage300 GB
EC2 Classdb.r4.4xlarge
CPU12 cores 2.0+GHz
Memory96 GB RAM
Storage400 GB
EC2 Classdb.r4.4xlarge
CPU16 cores 2.0+GHz
Memory128 GB RAM
Storage600 GB
EC2 Classdb.r5.4xlarge
CPU16 cores 2.0+GHz
Memory96 GB RAM
Storage400 GB
EC2 Classdb.r4.4xlarge
CPU20 cores 2.0+GHz
Memory128 GB RAM
Storage600 GB
EC2 Classdb.r3.8xlarge
CPU20 cores 2.0+GHz
Memory192 GB RAM
Storage800 GB
EC2 Classdb.r4.8xlarge
CPU24 cores 2.0+GHz
Memory256 GB RAM
Storage1.2 TB
EC2 Classdb.r4.16xlarge

Important:  *Requires the SentryOne Scalability Pack.

Note:  The EC2 DB Instance Class Types are provided as examples. Please see the AWS DB Instance Class documentation for the latest types and specifications available.

Important:  When running the SentryOne Database server on VMware, adjustments may need to be made to the recommendations listed above to ensure that the VM is properly rightsized and vNUMA-aligned. Failure to do so can result in subpar performance. Contact as needed for more specific recommendations for your VMware host configuration. 

Additional Information: Please see the following blog post, Virtual Machine vCPU and vNUMA Rightsizing – Rules of Thumb for more information. 

The estimates provided are based on the default configuration of SentryOne. The hardware and resources needed by the SentryOne database to handle a monitored environment is heavily dependent on factors such as:

  • The query workload
  • Retention settings
  • Collection interval settings

For more information see the Performance Analysis Data Capacity Planning article.