## Overview
In this section, we describe the minimum and recommended hardware specifications for Opsview Monitor servers.
## Recommendations
The recommended hardware configuration is typically capable of monitoring approximately 300 hosts, but this may vary significantly depending on your monitoring configuration.
### Orchestrator Server
Four or more 64-bit CPUs (preferably multi-core)
8GB RAM
100GB available storage (with hardware RAID controller)
### Collectors
64-bit multi-core CPU
2GB RAM
40GB available storage See [Distributed Monitoring](🔗) for more details on setting up Collectors.
### Remote database
4 or more CPU cores (64-bit)
16GB RAM
500GB available storage (with hardware RAID controller)
## Minimum Requirements
The following guideline defines a few setups for different sizes, using AWS as a reference example for the machine flavors. Each host is assumed to have **20 service checks** associated with intervals of **5 minutes**. Keep in mind that these values are a minimum starting point and that we recommend choosing higher specs.
#### 100 Hosts
Host | Components | CPU | Memory | Example AWS Flavor |
1 | All | 4 | 8 GB | c5.xlarge |
**TOTAL:** 4 CPU / 8 GB Memory
#### 650 hosts
Host | Components | CPU | Memory | Example AWS Flavor |
1 | All (Monitoring hosts) | 2 | 8 GB | t2.large |
2 | Collector 1 (Cluster 1) | 2 | 2 GB | t3.small |
**TOTAL:** 4 CPU / 10 GB Memory
#### 1500 hosts
Host | Components | CPU | Memory | Example AWS Flavor |
1 | All (Not monitoring hosts) | 2 | 8 GB | t2.large |
2 | Collector 1 (Cluster 1) | 2 | 2 GB | t3.small |
3 | Collector 2 (Cluster 1) | 2 | 2 GB | t3.small |
4 | Collector 3 (Cluster 1) | 2 | 2 GB | t3.small |
5 | Collector 4 (Cluster 2) | 2 | 2 GB | t3.small |
6 | Collector 5 (Cluster 2) | 2 | 2 GB | t3.small |
7 | Collector 6 (Cluster 2) | 2 | 2 GB | t3.small |
**TOTAL:** 14 CPU / 20 GB Memory
#### 6500 hosts
Host | Components | CPU | Memory | Example AWS Flavor |
1 | Database, Datastore and Messagequeue | 4 | 16 GB | m5.xlarge |
2 | Timeseries | 2 | 4 GB | t2.medium |
3 | Collector 1 (Cluster 1) | 4 | 8 GB | c5.xlarge |
4 | Collector 2 (Cluster 1) | 4 | 8 GB | c5.xlarge |
5 | Collector 3 (Cluster 1) | 4 | 8 GB | c5.xlarge |
6 | Collector 4 (Cluster 2) | 4 | 8 GB | c5.xlarge |
7 | Collector 5 (Cluster 2) | 4 | 8 GB | c5.xlarge |
8 | Collector 6 (Cluster 2) | 4 | 8 GB | c5.xlarge |
9 | Master Server + remaining Components | 4 | 16 GB | m5.xlarge |
**TOTAL:** 34 CPU / 84 GB Memory
## Opsview Monitor Memory Allocation
In the table below, we describe the memory allocation for each section of the Opsview Monitor system. The memory allocations listed below are provided as guidance for most single-server deployments that monitoring approximately 300 devices.
**Note:** Actual requirements depends on the types and numbers of checks being performed on each device.
SYSTEM | MEMORY |
OS | 512MB |
MySQL | 512MB |
Opsview daemons | 512MB |
Opsview web | 1GB |
Monitoring processes | 1GB |
Opsview Reports Module | 1.5GB |
## Achieving maximum scalability
Please refer to [Distributed Monitoring](🔗) and [Distributing Functionality](🔗).
## Virtualized Environments
Opsview Monitor can run in a virtualized environment. In such an environment, disk I/O is the typical bottleneck, and so:
Automatic snapshotting of guest Virtual Machines (VMs) causes significant I/O overhead and we would recommend that this feature is disabled or carefully managed outside of core production hours.
An external storage array should be considered for large scale systems; for example, where thousands of hosts are monitored.
The latest versions of hypervisor software should be installed, as well as the latest recommended drivers for storage and network operations.