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.
For Web GUI requirements we use our slowest page,
/ports/ as an example.
For minimum requirements you should consult the documentation of your Linux distribution as well as Apache and MySQL.
A small Observium installation will probably never use more than 5-10MB of RAM it self, but it relies upon Apache and MySQL which will also use RAM. It should be possible to run Apache and MySQL in ~128MB of RAM, but at least 256MB is recommended for a small installation.
Web GUI page generation depends upon a single core, the faster the clock rate of the CPU, the faster the page generation, regardless of the number of cores. Multiple cores will help speed up graph loading, which are loaded in parallel, usually 4 at a time.
- A 3.2GHz Xeon E3-1225 V2 should take 0.15 seconds to generate /ports/ with 6k ports.
The poller can be run in parallel. Depending upon the average latency of the devices you're monitoring and the I/O throughput of your storage you should run 2-8 pollers per CPU so as not to waste CPU cycles.
- A quad-core 2.13GHz Xeon E5506 should scale to ~20k ports.
- A quad-core 3.4GHz i7-3770 should scale to ~40k ports.
The most RAM-intensive page is /ports/. This page currently uses ~16.5MB per 1000 ports. The PHP process must to be permitted enough memory to generate this page.
A 6k port installation uses ~29MB of RAM to generate /ports/
Poller memory usage is negligible.
Each port will use ~3MB of storage for RRDs, and each host will add another 5-50MB, depending upon the operating system and the number of ports.
- A 5,000 port installation will generate ~8GB of RRDs.
- A 11,000 port installation will generate ~23GB of RRDs.
Storage I/O Throughput#
Storage I/O throughput is the most serious bottleneck on many large deployments.
- A single 7200RPM drive will handle the RRD I/O of about 5,000 ports. This can be increased by using RAID-0 or faster (10k, 15k) drives.
An SSD will allow much, much faster I/O, but may be susceptible to corruption due to the heavy write load, so frequent backups to a magnetic disk is recommended. A RAM disk can be used to provide enough I/O capacity, but requires automated backup/restore, preferably to a magnetic disk as an SSD may not like the frequent massive write load.