Reduce Imunify360 high CPU and RAM usage on cPanel

Imunify360 has a reputation for spiking server load, and on a busy shared cPanel box it earns it — usually during the initial full malware scan, or from the real-time file watcher under heavy upload traffic. The fix is almost never "uninstall it". It's identifying which of the four load-bearing components is actually running hot, then turning that one down.

This is a decision tree, not a settings dump. Find the offending process first, then apply the matching lever.

Identify the component

Run top (or htop) and look at the process name, not just the percentage:

• /opt/alt/php*-imunify/usr/bin/php — the malware scanner (ai-bolit). This is the most common culprit. Its job queue lives at /var/imunify360/aibolit/resident/in/.
• imunify-auditd-log-reader — the syscall monitor feeding Proactive Defense's process logging.
• imunify360-webshield — the WebShield HTTP proxy, almost always a RAM complaint rather than CPU.
• imunify360 / imunify360-resident — the agent daemon itself.

Before you change anything, dump the current effective config so you know your baseline and can roll back:

imunify360-agent config show

Scanner load: lower the intensity

The scanner's CPU, I/O, and RAM ceilings live under MALWARE_SCAN_INTENSITY. Defaults are cpu: 2, io: 2 (both on a 1–7 scale) and ram: 1024 MB. Drop the first two to the floor on a constrained server:

imunify360-agent config update '{"MALWARE_SCAN_INTENSITY": {"cpu": 1, "io": 1}}'

On CloudLinux OS these levels are enforced through LVE; on AlmaLinux or Ubuntu they map to nice and ionice. The same two sliders sit in the WHM UI under Imunify360 → Settings → Malware → Resource consumption — but ram is CLI-only and isn't exposed there.

config update does a partial merge and writes to /etc/sysconfig/imunify360/imunify360.config.d/90-local.config, so don't hand-edit the config file. Changes survive agent updates.

Two settings cut the amount of work rather than throttling it:

imunify360-agent config update '{"MALWARE_SCANNING": {"rapid_scan": true}}'
imunify360-agent config update '{"MALWARE_SCAN_SCHEDULE": {"interval": "week", "hour": 3}}'

rapid_scan skips files already known-clean by cloud hash — the reason a re-scan finishes in ~2 hours when the first full scan took a day or two. Move the schedule to a weekly 3 AM window instead of the default monthly run. And exclude large, trusted directories (backups, media libraries) via Malware Scanner → Ignore List — scanning a multi-gigabyte backup folder is pure wasted load.

Real-time watcher: the sustained I/O case

If load is constant rather than scan-shaped, the real-time watcher is scanning every modified file. First confirm the File Change API optimisation is on (it buffers changed-file lists in the kernel instead of placing per-directory inotify watches):

imunify360-agent config update '{"MALWARE_SCANNING": {"optimize_realtime_scan": true}}'

If that isn't enough, disable the real-time triggers. This is a genuine security trade-off — scheduled scans still run, but uploads aren't caught on write:

imunify360-agent config update '{"MALWARE_SCANNING": {"enable_scan_inotify": false, "enable_scan_modsec": false, "enable_scan_pure_ftpd": false}}'

Proactive Defense and WebShield

If imunify-auditd-log-reader is the hot process, the syscall monitor is the cause:

imunify360-agent config update '{"LOGGER": {"syscall_monitor": false}}'

For Proactive Defense itself, drop it from blocking to logging — KILL mode with PHP Immunity is the heaviest configuration. See Proactive Defense and the PHP shield for what each mode costs:

imunify360-agent config update '{"PROACTIVE_DEFENCE": {"mode": "LOG"}}'

WebShield is the big RAM consumer. The documented heavy lever for a memory-starved server is Low Resource Usage mode, which disables WebShield and switches ModSecurity to the minimised ruleset. Pair this with the WAF false-positive tuning so you don't lose protection you actually rely on.

If you can't pin the load to one component, run imunify360-agent doctor to collect diagnostics, and cross-reference with LVE Manager statistics to confirm whether the load is Imunify or an abusive account it's reacting to. The full command set is in the agent CLI reference. For sizing a license to a high-density node, talk to sales or review the Imunify360 license tiers.

Next steps

• Imunify360 agent CLI reference — the diagnostics commands that confirm root cause
• Tune the Imunify360 WAF false positives — before minimising the ModSecurity ruleset
• Read LVE Manager statistics to find the offender — rule out an abusive account driving the load