-
I had a question about how memray tracks thread/thread count in the live view. I'm using the live view to profile a fastapi service, and was noting that when I do some load testing the thread count seem to inexorably grow as requests keep coming in. If I scroll through these threads, some (most?) of them don't have any information about location/allocation etc. I can't tell if this is some sort of fastapi artifact, or related to how memray tracks async coroutines maybe? If I try to get the thread count for the process using Thanks for any insight you may have, and for the great tool! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
The thread count in the live view is counting all of the threads that have ever been seen, not just the ones that are currently alive - that's why it doesn't match
Those would be ones that at some point performed some allocation, but where all of the memory allocated by that thread has since been freed. That's distinct from whether the thread itself is still alive, though - it's possible for a thread to allocate some big chunk of memory and stash it in a global variable or hand it off to another thread before it exits, in which case the thread will show up as having some allocated memory even though it has died. Perhaps we should prune dead threads from that list once they no longer have any allocations, though... |
Beta Was this translation helpful? Give feedback.
The thread count in the live view is counting all of the threads that have ever been seen, not just the ones that are currently alive - that's why it doesn't match
ps -o nlwp
.Those would be ones that at some point performed some allocation, but where all of the memory allocated by that thread has since been freed. That's distinct from whether the thread itself is still alive, though - it's po…