Skip to content

Hardware Scaling

Observium's RAM and CPU requirements scale linearly primarily around the number of ports for networking-centric installs and the number of devices for server-centric installs.

When selecting hardware for web applications, it's crucial to consider single-threaded performance for both the web and database servers. Interactive elements of your application depend on this performance, as PHP page generation is single-threaded and SQL queries are executed sequentially.

CPU Single core scaling

Base Requirements

Before diving into specific hardware requirements, consult the documentation for your chosen Linux distribution, web server (e.g., Apache, Nginx), and database server (e.g., MySQL, MariaDB). These components have their own minimum requirements and will affect your hardware choices.

A small web application may only require a few tens of MB of RAM, but the web and database servers will also consume memory. We recommend at least 512MB of RAM for a small installation on a Raspberry Pi.

Processor (Web)

Web GUI page generation relies heavily on a single core. The higher the clock rate of the CPU, the faster the page generation, regardless of the number of cores. Multiple cores can speed up graph loading or other parallel tasks.

  • For optimal performance, choose CPUs with high single-core performance. Modern AMD Ryzen or Intel Core i-series processors are excellent choices.
  • Old multi-socket Xeon or EPYC configurations with many low-clock cores are a poor choice for the web UI — a 64-core server CPU at 2.0 GHz will feel slower than a 6-core desktop CPU at 4.5 GHz.
  • When deploying on cloud or virtual infrastructure, choose instance types that favour CPU clock speed over core count for the web server.

Processor (Poller)

Pollers run in parallel, so consider the average latency of the devices you're monitoring and the I/O throughput of your storage. To avoid wasting CPU cycles, aim to run around 2 pollers per core.

  • Scaling pollers for a larger number of devices or ports benefits from both core count and clock speed. Mid-to-high-end AMD Ryzen, Threadripper, Intel Core i7/i9, or current-generation Xeon Scalable processors all work well.
  • On cloud/VM deployments, you can scale horizontally using the distributed poller feature to spread the load across multiple instances.

Memory

Poller memory usage is generally negligible, scaling lightly based on number of ports or other entities on each device. Web UI memory usage scales based on total install size, but will rarely be larger than a few tens of MBs per page load.

The MySQL/MariaDB innodb_buffer_pool_size setting has the biggest impact on memory requirements in larger installations. As a rule of thumb, set it to around 50-70% of available RAM on a dedicated Observium server.

When polling on embedded systems such as Raspberry Pis or similar, poller threads are usually limited by available processor performance before memory capacity.

Storage Capacity

The storage capacity required depends on the amount of data generated by your installation.

  • Each device or port may require a different amount of storage (e.g., 3 MB per port and 5-50 MB per host, depending on the OS and the number of entities).
  • As a rough guide: a 5,000-port installation typically requires around 8 GB of RRD storage, while an 11,000-port installation may need around 23 GB.

Storage I/O Throughput

Storage I/O throughput is the most serious bottleneck on many large deployments.

  • SSD or NVMe storage is strongly recommended. Even a basic SATA SSD will dramatically outperform any spinning disk configuration. NVMe drives offer the best performance for large installations.
  • Spinning disks (HDDs) are not recommended. A single 7200 RPM drive can only handle around 5,000 ports before I/O becomes a bottleneck, and adding faster or more disks is no longer cost-effective compared to SSDs.
  • On cloud infrastructure, choose storage tiers with sufficient IOPS. General-purpose SSD volumes (e.g., AWS gp3, Azure Premium SSD) are usually adequate. Avoid magnetic/standard tiers.
  • If using rrdcached, storage I/O requirements are significantly reduced as writes are batched. See Using rrdcached for details.

Example Sizing

Size Devices Ports CPU RAM Storage
Small up to 50 up to 1,000 2 cores 4 GB 20 GB SSD
Medium 50-500 1,000-10,000 4-8 cores 8-16 GB 50-100 GB SSD
Large 500-2,000 10,000-50,000 8-16 cores 32-64 GB 200+ GB NVMe
Very Large 2,000+ 50,000+ 16+ cores 64+ GB NVMe + rrdcached

These are rough guidelines. Actual requirements depend on the types of devices monitored, polling frequency, and enabled modules. Server-centric installations (many entities per device) will use more resources per device than switch-centric installations.