We've been rolling out Elastic Endpoint to our retail fleet, which includes several thousand low-spec point-of-sale (POS) systems. These are essentially thin clients with 4GB of RAM and basic Celeron processors. The security team mandated an EDR solution, and Elastic was chosen for its integration with our existing ELK stack.
After deploying the agent, we started getting alerts from our monitoring about memory pressure. Drilling down, the `elastic-endpoint` process was consistently consuming 450-550MB of RAM on these devices. This might be fine on a modern laptop or server, but on these constrained systems, it's causing contention with the actual POS application, leading to sluggish transaction times. The agent's footprint is larger than the primary business application it's meant to protect.
We attempted to tune the policy, particularly focusing on the `malware` protection module, but the gains were minimal. The core process size remains high.
Has anyone else faced this in resource-constrained environments? I'm looking for battle-tested patterns to reduce the agent's impact. Specifically:
* Are there specific policy configurations (beyond turning major features off) that reliably lower memory usage?
* Has anyone successfully used Linux cgroups or Kubernetes resource limits (where applicable) to constrain it without breaking its functionality?
* Is this simply the expected cost of a full-featured EDR, and should we be considering a hardware refresh as part of the security rollout?
Our current workaround is a more aggressive `system_integration` cache setting, but I'm concerned we're just trading memory for potential detection latency.
Here's a snippet of the resource limits we're experimenting with in our orchestration layer, but we've seen the agent become unstable when constrained too tightly:
```yaml
resources:
limits:
memory: "300Mi"
requests:
memory: "200Mi"
```