# Remote Agent Memory Limits
This guide helps you diagnose Remote Agent polling problems caused by memory exhaustion or worker limits.
Memory problems are usually visible during large polling cycles, Redfish polling, SNMP walks, OS installation tasks, or when too many devices are assigned to one Remote Agent.
# Common Symptoms
Typical symptoms include:
- polling starts but stops before all devices are processed,
- graphs become stale even though the Remote Agent is online,
- the queue worker restarts repeatedly,
- some polling jobs fail without updating device metrics,
- logs contain memory-related PHP errors.
Common log messages:
Allowed memory size exhausted
PHP Fatal error: Allowed memory size of ... bytes exhausted
Worker exceeded memory limit
Killed
# Where Memory Limits Apply
The Remote Agent uses queue workers for background tasks. The worker limits are configured per queue type.
The current queue groups include:
- default / remote queue - general Remote Agent jobs,
- polling queue - device polling jobs,
- long-running queue - long tasks such as OS installation.
The polling queue usually has a lower memory limit than long-running tasks. This is intentional: polling jobs should stay small and finish quickly. If polling jobs need much more memory, it usually means that the agent is overloaded or one of the polled devices returns unusually large data.
# First Checks
Check the Remote Agent status:
easydcim-control agent status
Check recent logs:
easydcim-control agent logs -f
If you have direct shell access to the Remote Agent, also check the application logs:
ls -lah /opt/easydcim_remote/storage/logs/
grep -R "Allowed memory\|exhausted\|Worker exceeded memory\|Killed" /opt/easydcim_remote/storage/logs/ | tail -50
Check Horizon workers:
easydcim-control agent shell -- php artisan horizon:status
easydcim-control agent shell -- php artisan horizon:supervisors
# How to Identify the Source
# If all polling jobs are affected
The Remote Agent may be overloaded.
Check:
- number of devices assigned to the Remote Agent,
- polling execution time,
- whether the execution time is over 600 seconds,
- whether many devices use slow protocols such as Redfish or SNMP,
- whether the master panel API is slow when returning
/polling/devices.
Recommended actions:
- split devices between more Remote Agents,
- disable unsupported polling modules for devices that do not use them,
- reduce unnecessary polling scope,
- verify server resources: CPU, RAM, disk I/O.
# If only one device is affected
One device may return very large or malformed data, or one protocol may be slow.
Check the device-specific polling log:
ls -lah /opt/easydcim_remote/storage/logs/polling-log-[DEVICE_ID]-*.log
tail -200 /opt/easydcim_remote/storage/logs/polling-log-[DEVICE_ID]-$(date +%F).log
Then verify the protocol used by that device:
- for network ports and traffic, check SNMP,
- for PDU power usage, check SNMP,
- for server power and sensors, check Redfish.
See also: Graph Data Freshness.
# When Increasing Memory Is Not Enough
Increasing memory can hide the symptom but does not always fix the root cause.
Do not rely only on higher memory limits if:
- polling execution time keeps growing,
- workers restart repeatedly,
- the same device fails every cycle,
- the agent processes hundreds or thousands of devices alone,
- the master panel API is slow before polling even starts.
In these cases, scale horizontally by adding another Remote Agent or reduce the polling workload.