Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Row buffering prevents asynchronous symbols fetching #3265

Closed
kolesnikovae opened this issue May 2, 2024 · 0 comments · Fixed by #3266
Closed

Row buffering prevents asynchronous symbols fetching #3265

kolesnikovae opened this issue May 2, 2024 · 0 comments · Fixed by #3266
Assignees
Labels
performance If there's anything we have to be really good at it's this storage Low level storage matters

Comments

@kolesnikovae
Copy link
Collaborator

When profile rows are fetched, they are first read in into the buffer of a fixed size (128 rows). Therefore, the first profile becomes visible to the consumer only after the buffer is full, or all the rows are read, whichever occurs first. In practice, this delays fetching of symbols for the profiles, as we get the partition ID from the profile entries.

For example, in the screenshot you can see that the resolver starts fetching data only after the profile row iterator finished. There were 43 rows, therefore profiles become visible to it only after all of them were read in into the buffer:

image

This is especially harmful with downsampled profiles, because they are quite big, and the number of rows is relatively low. I think it makes sense to reduce the buffer size to 32: it does not cause an increase in number of reads or anything like this, but if the buffer is too small, read ahead buffering might be inefficient.

@kolesnikovae kolesnikovae added storage Low level storage matters performance If there's anything we have to be really good at it's this labels May 2, 2024
@kolesnikovae kolesnikovae self-assigned this May 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
performance If there's anything we have to be really good at it's this storage Low level storage matters
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant