Use shared mutex for global stacktrace cache#62453
Conversation
|
This is an automatic comment. The PR descriptions does not match the template. Please, edit it accordingly. The error is: Changelog entry required for category 'Improvement' |
|
This is an automatic comment. The PR descriptions does not match the template. Please, edit it accordingly. The error is: Category 'Not for change log' is not valid |
|
This is an automated comment for commit 5d576bb with description of existing statuses. It's updated for the latest CI running ⏳ Click here to open a full report in a separate page
Successful checks
|
| /// Calculation of stack trace text is extremely slow. | ||
| /// We use simple cache because otherwise the server could be overloaded by trash queries. | ||
| /// We use cache because otherwise the server could be overloaded by trash queries. | ||
| /// Note that this cache can grow unconditionally, but practically it should be small. |
There was a problem hiding this comment.
irrelevant to the current PR.
though I see no benefit from caching whole stack as a single entry instead of storing each frame separately.
There was a problem hiding this comment.
Yes, I was also thinking about it. We can lower memory consumption by a factor equal to the stack average depth. And a bit less work for the frames appearing in many stacktraces. Ideally we need to move our cache to StackTrace::forEachFrame/toStringEveryLineImpl function. Though, it will require some effort.
Avoid locking
stacktrace_cache_mutexexclusively as much as possible to lower contention even further. Follow up for #62332Changelog category (leave one):
Modify your CI run:
NOTE: If your merge the PR with modified CI you MUST KNOW what you are doing
NOTE: Checked options will be applied if set before CI RunConfig/PrepareRunConfig step
Include tests (required builds will be added automatically):
Exclude tests:
Extra options:
Only specified batches in multi-batch jobs: