When trying to do a microprofiler dump sometimes it will cause a large lagspike and produce a unusable dump.
This doesn’t happen on every server but when it does it’s consistent throughout it’s lifetime.
Video showing the lag spike:
Screenshot of the unusable dump:
Expected behavior
The server to remain unaffected and produce a readable dump.
A private message is associated with this bug report
Thanks for the report! We’ll follow up when we have an update for you.
Thank you for the attached video. We are investigating the issue, and it seems that due to the freeze at the moment of capturing, the calculation of new frames does not occur, resulting in a technically valid dump that essentially contains 0 frames… And, of course, this only occurs in the production environment, which makes fixing it more difficult. We have a couple of theories as to why this might be happening, and we will share new information here when we have it.
OK, I have a workaround: when creating a server dump, immediately after the first (non-functional) dump is completed, start recording the second dump right away, and it will be valid. Yes, this won’t eliminate the server freeze that occurs during the first dump, but at least you’ll get a valid second dump.
A bit of background: it appears that in the second half of September, a function we used in the microprofiler code began to take an excessively long time in the production server environment, causing a freeze at the moment the dump starts (resulting in a null dump). However, its result is cached, and when the second dump is quickly initiated, it uses this cached result, preventing the freeze and allowing the dump frames to accumulate properly.
We are working on a fix.
