I can definitely confirm that opening up the Task information (clicking on it / going to logs) frees up the worker.
I let the workflow run for some 14 hours overnight without inspecting it; this morning, it had only gotten through 13k mapped tasks (out of 76k.)
I had the Prefect tab already loaded in my browser, but it was suspended. By reloading the window, without clicking on any UI components, in the main task window (the larger box to the right of the "Activity" column), I could see several tasks in RUNNING with the duration of ~11 hours; and other tasks that were running properly (so not zombies), running for a minute and then transitioning state.
Without doing anything, after a few seconds, the duration of the stalled tasks changes to something on the order of 5 minutes, 8 minutes, etc; down from ~11 hours. (These smaller durations are expected for certain runtime failure cases, based on the timeouts I have set in various places.) But, the duration keeps ticking up from there. I don't understand why Prefect goes from showing 11 hours to the more reasonable time, upon loading; something in the internal state / timing / browser cache must be responsible.
Finally, opening up each of these tasks, after taking a minute or two to load, will show the completed task execution graph. Most of them are failures for exceptions related to my database -- expected FAIL cases. A few of them are SUCCESSes.
Now we've freed some 11 workers.
Checking back two hours later, 56k mapped tasks have completed; compared to 11k completed over the previous 14 hours. Obviously, jolting the tasks increased throughput
Resource usage appears unchanged. And, last night, a few hours into the flow, vCPU usage was around 30%, and memory around 25%, for the Prefect machine. So, no problems there.