User quotas in admission control
User quotas in Impala’s admission control set per-user query limits to ensure fair resource distribution and prevent system overload.
Starting with Cloudera Data Warehouse Runtime 2025.0.19.0, user quotas introduce rules to restrict the number of queries a users/groups can run concurrently. These rules apply at both the pool and root levels and can be based on individual usernames, wildcard users, or user groups. Queries are counted against limits starting with admission control acceptance and continuing until they are released.
When a query exceeds the defined quota, it is rejected at submission time.
User quota configuration elements
Element | Description |
---|---|
userQueryLimit | used to define a User or Wildcard Rule |
groupQueryLimit | used to define a Group Rule |
totalCount | used to define the number of queries that can run concurrently. |
user | used to specify a username to define a User Rule, or, by using the wildcard '*', to define a Wildcard Rule. |
group | in a Group rule, used to specify a group name that the rule applies to. |
- User rules override group and wildcard rules.
- Group rules override wildcard rules.
- Pool-level rules are evaluated first; if passed, root-level rules are checked.
- If a user belongs to multiple groups, the least restrictive rule applies.
Limitation
This feature is not supported for virtual warehouses that use workload-aware autoscaling.
Query queued. Latest queuing reason: Waiting for executors to start.
Only DDL queries and queries scheduled only on the coordinator
(either NUM_NODES set to 1 or when small query optimization is
triggered) can currently run.
Once the virtual warehouse resumes, all queued queries will be admitted and executed
simultaneously. The limit defined in the
llama.am.throttling.maximum.queued.reservations
setting in
llama-site.xml
still applies. These limitations are due to a known issue
tracked at IMPALA-13965. There is currently no workaround for these issues.
Query counts are synchronized across the cluster by using the statestore. Because the statestore uses an eventually consistent model, the system may admit more queries than the configured limit when multiple queries start at the same time