wdavdaemon cpu usage issue and possible tuning point

CHUNSIK KIM

Thank you for reaching out to Microsoft Q&A.

Q1. Is periodic 10–20% CPU usage by wdavdaemon on Linux expected?

Yes — within specific conditions, this is considered expected behavior.

Microsoft documents that Defender for Endpoint on Linux performs continuous and background activities that can cause periodic CPU spikes, even when no malware alerts are generated. These activities include:

What typically causes periodic CPU usage

Real‑time protection (RTP) continuously monitoring file and process activity

File system event bursts, especially from cron jobs, log rotation, package updates, or backups

Signature / engine updates followed by internal cache validation (housekeeping)

Audit / eBPF event ingestion (depending on kernel and configuration)

Microsoft explicitly notes that:

Applications or system processes that access many resources such as CPU, Disk, and Memory over a short timespan can lead to performance issues in Defender for Endpoint on Linux. [learn.microsoft.com]

Early‑morning spikes are commonly correlated with:

OS maintenance jobs

Backup windows

Log rotation

Scheduled update jobs

When this becomes abnormal

According to Microsoft guidance, CPU usage should be investigated when:

wdavdaemon sustains high CPU for extended periods (not short bursts) [learn.microsoft.com]

CPU usage correlates with specific directories or processes repeatedly

Performance degradation affects workloads or SSH responsiveness

Microsoft recommends using built‑in diagnostic tooling before considering remediation.

Conclusion for Q1

Short‑lived 10–20% CPU spikes, especially during off‑peak hours, are expected and normally associated with background scanning and event processing. It is considered abnormal only when sustained or workload‑impacting.

Microsoft Doc: https://learn.microsoft.com/en-us/defender-endpoint/linux-support-perf

Q2. Why did CPU % drop after downsizing from 8 vCPU → 4 vCPU?

Your observation aligns with how CPU utilization is measured and how Defender behaves on Linux.

Key documented factors

1. Linux CPU % is per‑core relative

Microsoft clarifies that Linux CPU percentages are reported per CPU, not aggregated like Windows.

Each core represents 100%, so total available CPU scales linearly with vCPU count.

CPU values displayed on Linux are relative and not absolute — each CPU counts as 100%.

This means:

1 core at 100% on an 8‑vCPU VM = 12.5% overall

1 core at 100% on a 4‑vCPU VM = 25% overall

So a drop from ~20% to ~10% does not imply less work, just different denominator math.

2. Defender uses internal concurrency limits

Microsoft does not document dynamic scaling tied directly to VM SKU, but states that:

Defender’s scanning and RTP pipelines use bounded concurrency

Work is processed in short bursts, not linear scaling with cores

This explains:

Similar work completed

Lower reported CPU % on smaller SKUs

Comparable protection effectiveness

3. Shorter execution bursts

Microsoft notes that Defender activity often appears as short, high‑intensity bursts, not sustained loads.

Conclusion for Q2

Your observation is consistent with:

Linux CPU accounting behavior

Defender’s bounded concurrency model

Burst‑based execution

It does not indicate degraded protection.

Q3. Supported tuning options to reduce CPU impact (RHEL 9.4)

Microsoft supports performance tuning while keeping protection enabled, primarily through diagnostics‑driven exclusions and telemetry optimization.

recommended options

1. Identify noisy paths using built‑in diagnostics

Microsoft provides official diagnostic commands to identify hot directories and processes:

Real‑time protection statistics

Hot event sources

eBPF statistics (if enabled)

These tools are the only supported way to justify exclusions.

https://learn.microsoft.com/en-us/defender-endpoint/linux-support-perf

2. Configure targeted exclusions (not broad ones)

Microsoft explicitly supports:

Directory exclusions

Process exclusions

File extension exclusions

Only for high‑frequency, trusted workloads. [learn.microsoft.com]

Docs for your reference:

Configure custom exclusions for Microsoft Defender Antivirus - Microsoft Defender for Endpoint | Microsoft Learn

Microsoft warns against:

Excluding system paths broadly

Blanket exclusions without diagnostics

3. Prefer eBPF over auditd (where supported)

Microsoft documents that eBPF‑based telemetry can significantly reduce CPU overhead compared to auditd on newer kernels.

Troubleshoot performance issues for Microsoft Defender for Endpoint on Linux - Microsoft Defender for Endpoint | Microsoft Learn

This is supported on modern RHEL kernels, including RHEL 9.x.

4. Validate no competing security agents

Microsoft explicitly warns that multiple active security products can cause excessive CPU consumption.

Not supported

Manual CPU throttling of wdavdaemon

Nice / cgroup manipulation

Disabling RTP as a permanent solution

please do. thanks

Thanks for the reply.

If the CPU metric is based on 'Total Percentage' from Azure Monitor, scaling down from 8 vCPUs to 4 vCPUs should logically result in a higher utilization percentage, not a lower one. A 10% usage on a 4-vCPU VM represents a smaller absolute amount of compute power than 20% on an 8-vCPU VM. It is counter-intuitive that the agent consumes fewer total resources simply because the capacity was reduced.

Does the wdavdaemon automatically scale its workload or thread count based on the available vCPU count? If so, does it mean the protection level or scanning speed is being throttled on smaller VMs.

Is there a specific threshold where MDE reduces its background activity based on the VM's instance size? I need to understand why the total resource consumption dropped significantly after the downgrade.

We are observing this behavior through Azure Monitor metrics, which represent the aggregated CPU utilization of the entire VM. Can you explain the technical mechanism that causes this 'inverse' resource usage pattern?

I would like to raise a counter-argument regarding the "per-core relative" explanation provided.

The data I am referencing is based on Azure Monitor's CPU Percentage metric, which calculates the aggregated utilization of the entire VM (Total System % = 100%), not the individual core usage seen in Linux top commands.

Given this context, the observed behavior (20% usage on 8 vCPUs vs. 10% on 4 vCPUs) presents a logical inconsistency that needs further technical clarification:

Inverse Resource Consumption: If the metric represents the total percentage of the VM's capacity, a 20% load on an 8-vCPU instance is significantly higher in absolute compute power than a 10% load on a 4-vCPU instance. It is counter-intuitive that the agent's total resource consumption would drop so drastically simply because the system's capacity was reduced.

Does wdavdaemon Self-Throttle? Does the MDE agent (wdavdaemon) automatically scale its workload, thread count, or scanning intensity based on the available vCPU count? If so, does this mean that the level of protection or background scanning thoroughness is lower on smaller VM instances?

Technical Mechanism for "Relative" Trends: If Azure Monitor is the source of truth, "relative" scaling usually implies that the percentage should increase when vCPUs are removed. Could you explain the specific technical mechanism within MDE that causes this "inverse" relationship where total system overhead decreases on lower-spec machines?

I am looking for a deeper explanation of how the agent manages its background tasks (e.g., scheduled scans, signature updates, or cleanup) in relation to the host's hardware limits.