-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Shared-data cluster Query Profile Metric Problems with accuracy #45669
Comments
instance是6,pipeline还有还有自己的并行度:
并行度是4,所以io task一共是 4*6 |
instance number is not the smallest concurrency granularity in StarRocks,every instance will use multi threads in io thread pool to execute io task |
got it ! so, according to profile results blew, can we surmise that there is a data skew problem, whether or not it hits the block cache. a demo that hits the cache - IOTimeLocalDisk: 355.869ms
- __MAX_OF_IOTimeLocalDisk: 25s710ms
- __MIN_OF_IOTimeLocalDisk: 51.257us
- IOTimeRemote: 0ns a demo that misses the cache - IOTimeLocalDisk: 6.265ms
- __MAX_OF_IOTimeLocalDisk: 70.878ms
- __MIN_OF_IOTimeLocalDisk: 0ns
- IOTimeRemote: 4s430ms
- __MAX_OF_IOTimeRemote: 55s242ms
- __MIN_OF_IOTimeRemote: 0ns FYI, we enabled the Block Cache, by set starlet_use_star_cache=true |
Backgrounds
We tried to use sr replace elasticsearch to build the logging platform, and then during the testing process, we found that the query latency was very high, so we used query profile to locate the problem.
Problem description
With this query profile result, it looks like there's a data skew problem,but there is something wrong with the metric data.
According to the sr document, InstanceNum means Number of all FragmentInstances for this Fragment, so the number of fragmentInstances for this Fragment is 6, but the iotime metrics above seems to be not correct, max iotime divided by 6 is also much larger than the average iotime.
StarRocks version
The text was updated successfully, but these errors were encountered: