Skip to content
Notifications
Clear all

Anyone else see a huge performance hit on graphics workstations?

4 Posts
4 Users
0 Reactions
1 Views
(@ci_cd_junkie)
Estimable Member
Joined: 5 months ago
Posts: 134
Topic starter   [#11141]

Okay, I need to get this out there because it's been driving me and my team absolutely bonkers for the last three sprints. We've been rolling out Microsoft Defender for Endpoint (MDE) across the org as part of a big security push, and overall, it's been... fine? For standard developer laptops and servers, the overhead seems manageable.

But we have a dedicated cluster of high-end graphics workstations—think Threadripper PROs, 128GB RAM, NVIDIA RTX A6000 cards, the whole shebang—used for rendering, simulation, and ML training. Since deploying MDE, users are reporting massive, tangible performance degradation during heavy workloads. We're talking:

* Render times in Blender and Unreal Engine increasing by 30-40%.
* CUDA kernel compilation times nearly doubling.
* Intermittent "stuttering" in real-time visualization tools.
* General system latency when moving large datasets (multi-gigabyte files) between NVMe drives.

At first, we blamed drivers or updates, but after a brutal root-cause analysis, all signs point to Defender. The moment we put a machine in "Passive mode" or create an exclusion for the entire project directory (not ideal, I know!), performance snaps back to normal.

My hypothesis is that the real-time protection and, crucially, the **inspection of network traffic** for these data-intensive, local IPC-heavy applications is causing havoc. These aren't scanning a few .py files; they're constantly reading/writing massive binary buffers that Defender wants to peek into.

Has anyone else in the graphics, scientific computing, or HPC world fought this dragon? I'm desperate for concrete config tweaks beyond just adding folder exclusions.

* Are there specific **process exclusions** for common rendering engines or CUDA processes that are safe?
* Has anyone tuned the **real-time protection scan settings** or **cloud-delivered protection timeouts** successfully for this use case?
* Is the **Network Protection** component the real culprit here with localhost/pipe traffic?

I've been scouring the docs and the usual suspects (process excludes, path excludes) but I'm worried we're just papering over a fundamental mismatch. I love the security posture MDE gives us, but we can't have $15k workstations running at 60% efficiency. There's got to be a middle ground between "secure" and "actually usable for its intended purpose."


pipeline all the things


   
Quote
(@emmaw)
Trusted Member
Joined: 1 week ago
Posts: 40
 

Wow, that sounds incredibly frustrating. I've only seen MDE on regular dev machines, so I hadn't considered this kind of high-end use case. Have you looked at whether the performance impact comes from file scanning during those heavy reads/writes, or could it be something else like memory scanning?



   
ReplyQuote
(@chloe22)
Estimable Member
Joined: 6 days ago
Posts: 90
 

It's a good question. On these kinds of machines, the memory scanning and CPU sampling can sometimes be the bigger culprit, not just file I/O. Those workloads are basically hammering the CPU and memory controller non-stop, so any background scanning feels like a direct tax.

We had to create a super granular performance mode policy for our AV on render nodes, excluding not just folders but specific process names and even tuning the scan frequency way down. It's a balance, but it helped a lot.


Raise the signal, lower the noise.


   
ReplyQuote
(@devops_grunt_2024)
Estimable Member
Joined: 4 months ago
Posts: 148
 

Yeah, it's always the AV. The passive mode test gives it away every time. You'll spend weeks chasing drivers or thermal issues before someone finally thinks to toggle the thing that's actively scanning every file handle and memory page.

The real fun starts when you have to explain to the security team that their blanket policy is tanking six-figure hardware. They love hearing that their "endpoint protection" is effectively a 40% performance tax on the actual work. Good luck getting exclusions for project directories approved without a fight.


If it ain't broke, don't 'upgrade' it.


   
ReplyQuote