High Memory Utilization on Security Onion 2.4.200 Standalone Deployment

[shreyas172003]

Version

2.4.200

Installation Method

Network installation on Red Hat derivative like Oracle, Rocky, Alma, etc. (unsupported)

Description

upgrading

Installation Type

Standalone

Location

cloud

Hardware Specs

Meets minimum requirements

CPU

4

RAM

15

Storage for /

250

Storage for /nsm

250

Network Traffic Collection

tap

Network Traffic Speeds

Less than 1Gbps

Status

Yes, all services on all nodes are running OK

Salt Status

No, there are no failures

Logs

No, there are no additional clues

Detail

Recently upgraded my Security Onion deployment from 2.4.190 → 2.4.200 on a standalone EC2 instance and I’m seeing unexpectedly high memory utilization.
CPU usage stays around 50–60%, and memory usage spikes to 95% after a few hours of uptime.
I’ve checked systemd services, Elastic and Suricata logs. Restarting services temporarily reduces memory, but it quickly climbs again.
Stopping and starting the EC2 instance temporarily frees memory, but the issue returns after some time.

Has anyone experienced high memory usage after upgrading to 2.4.200?
Are there known memory leaks or processes in this version causing high RAM consumption?
Any recommendations for monitoring or tuning memory usage on standalone deployments?

Guidelines

• I have read the discussion guidelines at Read before posting! #1720 and assert that I have followed the guidelines.

[cm-ops]

Do you know what component is using the most CPU?

[shreyas172003]

I checked both top and htop.

From top:

Top Memory Consumers
Elasticsearch (java) → ~4.9 GB (32%)
Stenographer (stenotype) → ~2.0 GB (13%)
Logstash (java) → ~977 MB (6%)
InfluxDB → ~864 MB (5%)

From htop:

The highest CPU usage is coming from:
salt-master (python3.10) ~38%
salt-minion (python3.10) ~24%
auditd ~41%

Elasticsearch (java) processes are only using 4–10% each.

[cm-ops]

Are you using a t3a.2xlarge? The resources are low for a standalone - https://docs.securityonion.net/en/2.4/cloud-amazon.html#single-node-grid

[shreyas172003]

We are currently using a t3.xlarge instance, and this high memory usage problem started occurring after upgrading from Security Onion 2.4.190 → 2.4.200. Over time (about 1–2 weeks), the swap space fills up, which causes us to lose access to the server and the dashboard. The only temporary fix is to stop and start the EC2 instance, which frees up some swap space for a short period, but the issue eventually returns.