Every so often, posts from Bruce Dawson's blog get posted here - one such post was about using Event Tracing for Windows to diagnose an issue with an NTFS lock

Every so often, posts from Bruce Dawson's blog get posted here - one such post was about using Event Tracing for Windows to diagnose an issue with an NTFS lock being held causing 63 cores to idle while 1 does all the work. https://randomascii.wordpress.com/2019/10/20/63-cores-blocked-by-seven-instructions/#more-3282 https://randomascii.wordpress.com/2019/10/20/63-cores-blocke... A few months later, some other people in my team were struggling to diagnose an issue in production where a legacy webapp was struggling to scale up and fully use all 64 cores of the server we needed it to run on. I stepped in to help and remembered that post I'd seen on HN. We used ETW (through Windows Performance Recorder and Windows Performance Analyzer) to profile our app and I looked into the Wait Analysis. Turns out that Entity Framework 6 uses a ReaderWriterLockSlim to guard a cache, and that particular lock performs extremely poorly under heavy contention. Heavy in our case meant that for a single page build of one of this app's "hot path" pages, this lock would be taken a few hundred thousand times. We weren't the first to discover this: https://github.com/dotnet/ef6/issues/1500 https://github.com/dotnet/ef6/issues/1500 What some other people in my team were struggling with for about two weeks was resolved in a single day thanks to me goofing off and reading HN. (We ultimately used a fork of EF6 that didn't suffer from this issue to solve our problem)