mirror of
https://github.com/apache/impala.git
synced 2026-01-10 00:00:16 -05:00
548106f5e1
This gives us some additional coverage for using admission control in a simple but realistic configuration. What are the implications of this change for test stability and flakiness? On one hand were are adding some more unpredictability to tests, because they may be queued for an arbitrary amount of time. On the other, we can prevent queries from contending over memory. Currently we rely on luck to prevent concurrent queries from forcing each other out-of-memory. I think the unpredictability from the queueing is preferable, because we can generally work around these by fixing tests that are sensitive to being queued, whereas contention over memory requires us to use crude workarounds like forcing tests to execute serially. Added observability for the configured queue wait time for each pool. I noticed that I did not have a direct way to observe the effective value when I set configs. This is IMPALA-8905. I had to tweak tests in a few ways: * Tests with large strings needed higher memory limits. * Hardcoded instances of default-pool had to handle root.default as well. * test_query_mem_limit needed to run without a mem_limit. I created a special pool root.no-limits with no memory limits to allow that. Testing: Ran the dockerised build 5-6 times to flush out flaky tests. Change-Id: I7517673f9e348780fcf7cd6ce1f12c9c5a55373a Reviewed-on: http://gerrit.cloudera.org:8080/13942 Reviewed-by: Impala Public Jenkins <impala-public-jenkins@cloudera.com> Tested-by: Impala Public Jenkins <impala-public-jenkins@cloudera.com>
125 lines
3.6 KiB
Plaintext
125 lines
3.6 KiB
Plaintext
====
|
|
---- QUERY
|
|
# Test per-backend limit. The coordinator will get 2 fragments + 1 scanner thread
|
|
# scheduled on it.
|
|
set thread_reservation_limit=2;
|
|
select count(*) from alltypes
|
|
---- CATCH
|
|
row_regex:.*Rejected query from pool .*: thread reservation on backend '.*'
|
|
is greater than the THREAD_RESERVATION_LIMIT query option value: 3 > 2\.
|
|
====
|
|
---- QUERY
|
|
# Test the boundary case where the thread reservation is exactly the required threads.
|
|
set thread_reservation_limit=3;
|
|
select count(*) from alltypes
|
|
---- TYPES
|
|
BIGINT
|
|
---- RESULTS
|
|
7300
|
|
====
|
|
---- QUERY
|
|
# Zero means no limit.
|
|
set thread_reservation_limit=0;
|
|
select count(*) from alltypes
|
|
---- TYPES
|
|
BIGINT
|
|
---- RESULTS
|
|
7300
|
|
====
|
|
---- QUERY
|
|
# -1 means no limit.
|
|
set thread_reservation_limit=-1;
|
|
select count(*) from alltypes
|
|
---- TYPES
|
|
BIGINT
|
|
---- RESULTS
|
|
7300
|
|
====
|
|
---- QUERY
|
|
# MT_DOP is factored into reservation.
|
|
set thread_reservation_limit=3;
|
|
set mt_dop=4;
|
|
select count(*) from alltypes
|
|
---- CATCH
|
|
row_regex:.*Rejected query from pool .*: thread reservation on backend '.*'
|
|
is greater than the THREAD_RESERVATION_LIMIT query option value: 5 > 3\.
|
|
====
|
|
---- QUERY
|
|
# Higher aggregate limit can reject based on sum of total threads. Assume >= 2 impalads
|
|
# with scan ranges plus the coordinator fragment.
|
|
set thread_reservation_aggregate_limit=3;
|
|
select count(*) from alltypes
|
|
---- CATCH
|
|
row_regex:.*Rejected query from pool .*: sum of thread reservations across
|
|
all [0-9]+ backends is greater than the THREAD_RESERVATION_AGGREGATE_LIMIT query option
|
|
value: [0-9]+ > 3\.
|
|
====
|
|
---- QUERY
|
|
# tpch_parquet.nation has only one file, which means only one instance of the scan fragment,
|
|
# which means it only has 3 aggregate threads.
|
|
set thread_reservation_aggregate_limit=3;
|
|
select count(*) from tpch_parquet.nation
|
|
---- TYPES
|
|
BIGINT
|
|
---- RESULTS
|
|
25
|
|
====
|
|
---- QUERY
|
|
# tpch_parquet.orders has two files, which means only more instances of the scan fragment,
|
|
# which means it has more than 3 aggregate threads, assuming at least two impalads.
|
|
set thread_reservation_aggregate_limit=3;
|
|
select count(*) from tpch_parquet.orders
|
|
---- CATCH
|
|
row_regex:.*Rejected query from pool .*: sum of thread reservations across
|
|
all [0-9]+ backends is greater than the THREAD_RESERVATION_AGGREGATE_LIMIT query option
|
|
value: [0-9]+ > 3\.
|
|
====
|
|
---- QUERY
|
|
# Running on a single impalad gets us under the aggregate limit.
|
|
set num_nodes=1;
|
|
set thread_reservation_aggregate_limit=3;
|
|
select count(*) from alltypes
|
|
---- TYPES
|
|
BIGINT
|
|
---- RESULTS
|
|
7300
|
|
====
|
|
---- QUERY
|
|
# 0 means no limit.
|
|
set thread_reservation_aggregate_limit=0;
|
|
select count(*) from alltypes
|
|
---- TYPES
|
|
BIGINT
|
|
---- RESULTS
|
|
7300
|
|
====
|
|
---- QUERY
|
|
# -1 means no limit.
|
|
set thread_reservation_aggregate_limit=-1;
|
|
select count(*) from alltypes
|
|
---- TYPES
|
|
BIGINT
|
|
---- RESULTS
|
|
7300
|
|
====
|
|
---- QUERY
|
|
# Default value should prevent crazy queries from running.
|
|
# The below query should have > 3000 required threads per backend.
|
|
set mt_dop=3;
|
|
with
|
|
c1 as (select count(*) from functional.alltypes),
|
|
c2 as (select * from c1 union select * from c1),
|
|
c4 as (select * from c2 union select * from c2),
|
|
c8 as (select * from c4 union select * from c4),
|
|
c16 as (select * from c8 union select * from c8),
|
|
c32 as (select * from c16 union select * from c16),
|
|
c64 as (select * from c32 union select * from c32),
|
|
c128 as (select * from c64 union select * from c64),
|
|
c256 as (select * from c128 union select * from c128),
|
|
c512 as (select * from c256 union select * from c256)
|
|
select * from c512 union select * from c512;
|
|
---- CATCH
|
|
row_regex:.*Rejected query from pool .*: thread reservation on backend '.*'
|
|
is greater than the THREAD_RESERVATION_LIMIT query option value: [0-9]* > 3000\.
|
|
====
|