RPort Server Sizing

The rportd server can run on relatively low spec servers, depending on how many clients need to be supported and the features enabled. Particularly, enabling monitoring and alerting can significantly increase the server specifications required.

With almost all servers now deployed as virtual machines, you don’t have to worry about server sizing. Your environment can grow. You can get started with RPort on the smallest virtual machine available, with as little as 2GB of RAM and a single CPU. Such a setup can easily handle 500 clients. If you just want to manage your home lab with a handful of devices, RPort runs perfectly on a Raspberry Pi (64bit ARM).

Watch out for the monitoring feature. Storing measurements can require a very fast and large hard drive (see below).

• RAM usage is relatively low (unless the Alerting Service is enabled - see below).
• CPU usage can be relatively high when the server starts and all clients are connecting.
• Setting up SSH connections when clients connect is fairly expensive especially for low powered CPUs. If clients are slow to connect or struggling to connect at all, monitor the CPU utilisation and either add additional vCPUs or use the max_concurrent_ssh_handshakes configuration setting to manage the amount of CPU cores dedicated to SSH connections. If there are a relatively large number of clients relative to the available CPU, adding more CPU cores may not help as more clients will attempt to connect and soon saturate the CPU. In such scenarios, using the configuration setting is recommended.
• Disk usage is fair low, although capturing measurements from clients will significantly increase the disk space required.
• IO is typically low, although again capturing measurements from clients can increase the throughput required.
• Capturing measurements is relatively expensive.
• Running the alerting service is (currently) expensive.
• Always monitor your servers for CPU, Disk and IO utilization and re-size / reconfigure as required.

Monitoring and Alerting add a relatively high load on rportd servers. The additional load depends on the number of clients with active monitoring and the frequency with which measurements are delivered to the server. The size of measurements is principally determined by the number of processes running on each client. In the disk space sizing table, if the number of processes on each client is high then use the higher bounds when calculating the required disk space.

Inbound client updates and measurements are cached in memory. If a large number of clients then the memory requirements can be high. As a rough guide, 1GB-2GB of RAM will be required per 1K clients.

Note that the Alerting Service can be disabled separately from the Monitoring Service, which can continue to run.

If you are not interested in performance data, switch off monitoring. If you wish to have performance data, but monitoring the running processes is not desired, just turn off process monitoring. This reduces the required disc space significantly. Look for the pm_enabled = true|false in the client configuration.

(v)CPUs: 2
RAM: 4GB
SSD Disk Space¹: 3GB (without monitoring or alerting)

(v)CPUs: 4+
RAM: 8GB
SSD Disk Space¹: 5GB (without monitoring or alerting)

(v)CPUs: 8+
RAM: 16GB+
SDD Disk Space¹: 8GB (without monitoring or alerting)

For the disk space calculations, the lower estimate assumed approx 80K per measurement and the upper estimate assumed 150K per measurement. The size of measurements is mostly impacted by the number of processes running on a client. However, in practice these sizes will be very dependent on the individual clients and actual database sizes will vary accordingly. On site evaluations should try to establish the average measurement size to ensure appropriate database sizing.

This column relates to the Alerting Service Technology Preview only, which currently has a limit of approx 25-30 TPS (transactions/measurements per second), so cannot currently be enabled for installations with over approx 2K clients. This constraint will have been removed once the Alerting Service is fully released. Any future related sizing considerations will be covered subsequently here.

The Alerting Service caches client updates and measurements in memory. The table below provides a rough guide to the amount of memory required for a given number of clients.

The current RPort server logs with debug enabled currently consume significant amount of disk space. Approx 5GB per day should be budgeted. No special considerations are required when logging at info level.