DEV Community

Michael
Michael

Posted on • Originally published at gbase.cn

Verifying That a GBase 8a Resource Plan Is Active and Enforcing Limits

#gbase #database #数据库 #monitoring

After activating a resource plan on a virtual cluster, a few quick checks will confirm it's working as expected and restricting CPU, memory, and concurrency for the target users in a gbase database.

1. Confirm the Plan Is Active 

SELECT * FROM gbase.resource_config;
Enter fullscreen mode Exit fullscreen mode

The activated_plan column for the target VC should show the plan name you just activated (e.g., plan_day).

2. Check User – Consumer Group Mapping 

SELECT * FROM gbase.consumer_group_user;
Enter fullscreen mode Exit fullscreen mode

The target user (e.g., UserLoad) must belong to the expected consumer group (e.g., group_load).

3. Check Group – Resource Pool Binding 

SELECT * FROM gbase.resource_plan_directive WHERE plan_name = 'plan_day';
Enter fullscreen mode Exit fullscreen mode

You should see a directive that maps the consumer group to the correct resource pool (e.g., low_pool).

4. Monitor Real‑Time Pool Usage (Core Validation) 

SHOW RESOURCE POOL USAGE ON COORDINATORS 
WHERE resource_pool_name = 'low_pool' AND vc_name = 'vc1';
Enter fullscreen mode Exit fullscreen mode

Key metrics:

  • cpu_usage_percent – should not exceed the pool’s defined percentage (e.g., 20%).
  • mem_usage_mb – must stay below max_memory.
  • active_task – must not exceed max_activetask.

5. Verify That Tasks Land in the Right Pool 

SELECT * FROM information_schema.processlist 
WHERE resource_pool_name = 'low_pool' AND vc = 'vc1';
Enter fullscreen mode Exit fullscreen mode

When the target user runs a query, the RESOURCE_POOL_NAME column should show low_pool.

6. Look for Enforcement Events 

SHOW RESOURCE POOL EVENTS WHERE resource_pool_name = 'low_pool' AND vc_name='vc1';
Enter fullscreen mode Exit fullscreen mode

If resources are oversubscribed, you'll see WAITING or REJECTED events — clear evidence the plan is enforcing limits.

7. Proactive Testing

  • Concurrency limit test: Set max_activetask=2 and launch 3 queries simultaneously. Use SHOW RESOURCE POOL USAGE to confirm active_task never exceeds 2, and the extra task stays in a waiting state.
  • CPU weight test: Run heavy queries from two users assigned to different pools (e.g., 20% vs. 80%) and watch the CPU usage ratio approach the defined weights.

Verification Checklist

Dimension Command / Method Expected Outcome
Plan activation SELECT * FROM gbase.resource_config activated_plan shows the correct plan
User‑group mapping SELECT * FROM gbase.consumer_group_user User belongs to the intended group
Group‑pool binding SELECT * FROM gbase.resource_plan_directive Directive links group to target pool
Pool usage SHOW RESOURCE POOL USAGE ... CPU/memory/task counts within limits
Task routing SELECT * FROM processlist ... Task’s RESOURCE_POOL_NAME is correct
Enforcement events SHOW RESOURCE POOL EVENTS ... Waiting/rejected events appear when limits are hit

Once all checks pass, you can be confident that the resource plan is fully active and enforcing the desired fine‑grained control in your gbase database.

Top comments (0)