So the 80% is correct. I should’ve mentioned that the eviction_target config value’s default is 80% and the eviction_trigger config value is 95%.
if you check the logs:
db.serverStatus().wiredTiger.cache["pages evicted by application threads"]
you’ll see that its not by application threads. The eviction_trigger configuration value (default 95%) is the level at which application threads start to perform eviction.
The 80%, eviction_target is the level that WiredTiger attempts to keep the overall cache usage, so this is normal behavior.
The problem is your eviction threads can’t keep up with the workload, so even though they’re working at 80%, they’re falling behind and creating backlogs that cause your waiting for cache delays.
said another way, that single eviction thread is working flat-out at 80% but can’t keep up with how fast new data is coming in. This single thread becomes insufficient. (especially when the eviction thread must wait for I/O)…meaning it has to pause and wait for disk writes to complete before it can continue cleaning.
this leads to your queries having to wait in line behind this overwhelmed eviction process to get cache space, even though you theoretically have plenty of room. like when you go to a restaurant and having to wait for clean plates even though the restaurant isn’t full 
so you should be able to fix this by adding more eviction workers so cache cleanup doesn’t become a single threaded bottleneck.
apologies for the delay, was heads down in engineering, but made a mental note when i saw this (i was waiting at a restaurant lol)
have a great day!