Uh oh!
There was an error while loading. Please reload this page.
[Opt](scanner-scheduler) Opt scanner scheduler starvation issue. - #40641
Conversation
doris-robot
commented
Sep 10, 2024
Thank you for your contribution to Apache Doris. Since 2024-03-18, the Document has been moved to doris-website. |
kaka11chen
commented
Sep 10, 2024
run buildall |
86c08f6 to
ca2e7e3Comparekaka11chen
commented
Sep 11, 2024
run buildall |
doris-robot
commented
Sep 11, 2024
TeamCity be ut coverage result: |
ca2e7e3 to
af7b099Comparekaka11chen
commented
Sep 18, 2024
run buildall |
doris-robot
commented
Sep 18, 2024
TPC-H: Total hot run time: 42132 ms |
doris-robot
commented
Sep 18, 2024
TPC-DS: Total hot run time: 194081 ms |
doris-robot
commented
Sep 18, 2024
TeamCity be ut coverage result: |
doris-robot
commented
Sep 18, 2024
ClickBench: Total hot run time: 32.69 s |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
a1b1e78 to
2087b56Comparekaka11chen
commented
Sep 23, 2024
run buildall |
PR approved by anyone and no changes requested. |
2087b56 to
725afd0Comparekaka11chen
commented
Sep 23, 2024
run buildall |
doris-robot
commented
Sep 23, 2024
TPC-H: Total hot run time: 43020 ms |
doris-robot
commented
Sep 23, 2024
TPC-DS: Total hot run time: 195427 ms |
doris-robot
commented
Sep 23, 2024
ClickBench: Total hot run time: 33.62 s |
doris-robot
commented
Sep 23, 2024
TeamCity be ut coverage result: |
PR approved by at least one committer and no changes requested. |
…che#40641) When a scanner scheduler is stuck in executing a scan task, other scan tasks will starve and have no chance to execute, which will affect other queries. Currently, the scan task hopes to scan as much data as possible to reduce the overhead of scheduling switching. Currently, it hopes to obtain up to 10MB of data in `doris_scanner_row_bytes`. However, if a query scans a table with many rows of data, but the filtering rate is very high, the filter will eventually filter out a lot of data and will never get 10MB of data. It will keep getting and executing expression filtering, which will cause other scan tasks to starve. The current solution is to check `max_run_time_ms` by `MonotonicStopWatch`. After executing for a maximum of 1s, it will yield self's task for other tasks. When the scan task executes some time-consuming tasks, it needs to slice to do it.
…che#40641) When a scanner scheduler is stuck in executing a scan task, other scan tasks will starve and have no chance to execute, which will affect other queries. Currently, the scan task hopes to scan as much data as possible to reduce the overhead of scheduling switching. Currently, it hopes to obtain up to 10MB of data in `doris_scanner_row_bytes`. However, if a query scans a table with many rows of data, but the filtering rate is very high, the filter will eventually filter out a lot of data and will never get 10MB of data. It will keep getting and executing expression filtering, which will cause other scan tasks to starve. The current solution is to check `max_run_time_ms` by `MonotonicStopWatch`. After executing for a maximum of 1s, it will yield self's task for other tasks. When the scan task executes some time-consuming tasks, it needs to slice to do it.
) ## Proposed changes Backport #40641
) ## Proposed changes Backport #40641
…che#40641) ## Proposed changes ### Issue When a scanner scheduler is stuck in executing a scan task, other scan tasks will starve and have no chance to execute, which will affect other queries. Currently, the scan task hopes to scan as much data as possible to reduce the overhead of scheduling switching. Currently, it hopes to obtain up to 10MB of data in `doris_scanner_row_bytes`. However, if a query scans a table with many rows of data, but the filtering rate is very high, the filter will eventually filter out a lot of data and will never get 10MB of data. It will keep getting and executing expression filtering, which will cause other scan tasks to starve. ### Solution The current solution is to check `max_run_time_ms` by `MonotonicStopWatch`. After executing for a maximum of 1s, it will yield self's task for other tasks. When the scan task executes some time-consuming tasks, it needs to slice to do it.
…ate materialization case of parquet reader (#46121) ### What problem does this PR solve? Related PR: #40641 Problem Summary: [Fix](parquet-reader) Fixed the issue of excessive scanning data in late materialization case of parquet reader introduced by #40641 in scenarios with particularly high filtering rates.
…ate materialization case of parquet reader (#46121) ### What problem does this PR solve? Related PR: #40641 Problem Summary: [Fix](parquet-reader) Fixed the issue of excessive scanning data in late materialization case of parquet reader introduced by #40641 in scenarios with particularly high filtering rates.
…ate materialization case of parquet reader (#46121) ### What problem does this PR solve? Related PR: #40641 Problem Summary: [Fix](parquet-reader) Fixed the issue of excessive scanning data in late materialization case of parquet reader introduced by #40641 in scenarios with particularly high filtering rates.
…che#40641) ## Proposed changes ### Issue When a scanner scheduler is stuck in executing a scan task, other scan tasks will starve and have no chance to execute, which will affect other queries. Currently, the scan task hopes to scan as much data as possible to reduce the overhead of scheduling switching. Currently, it hopes to obtain up to 10MB of data in `doris_scanner_row_bytes`. However, if a query scans a table with many rows of data, but the filtering rate is very high, the filter will eventually filter out a lot of data and will never get 10MB of data. It will keep getting and executing expression filtering, which will cause other scan tasks to starve. ### Solution The current solution is to check `max_run_time_ms` by `MonotonicStopWatch`. After executing for a maximum of 1s, it will yield self's task for other tasks. When the scan task executes some time-consuming tasks, it needs to slice to do it.
Proposed changes
Issue
When a scanner scheduler is stuck in executing a scan task, other scan tasks will starve and have no chance to execute, which will affect other queries. Currently, the scan task hopes to scan as much data as possible to reduce the overhead of scheduling switching. Currently, it hopes to obtain up to 10MB of data in
doris_scanner_row_bytes. However, if a query scans a table with many rows of data, but the filtering rate is very high, the filter will eventually filter out a lot of data and will never get 10MB of data. It will keep getting and executing expression filtering, which will cause other scan tasks to starve.Solution
The current solution is to check
max_run_time_msbyMonotonicStopWatch. After executing for a maximum of 1s, it will yield self's task for other tasks. When the scan task executes some time-consuming tasks, it needs to slice to do it.