@Rocky Is it possible to set a CPU limit when running a large ALTER operation?

Currently, StarRocks does not support limiting the CPU usage of

ALTER TABLE

(Schema Change or Rollup) operations through Resource Groups (Workload Groups). Resource Groups primarily govern queries (

SELECT

) and data ingestion (

INSERT

,

Broker Load

). However, you can effectively control and limit the CPU and memory resources consumed by large

ALTER

operations using Backend (BE) configuration parameters. 1. Limit CPU usage via Worker Threads The CPU consumption of an

ALTER

operation on each BE node is determined by the number of concurrent worker threads processing the data conversion. You can lower the CPU footprint by reducing these thread counts: *

alter_tablet_worker_count

: This is the primary parameter. It defines the number of concurrent tablet conversion tasks on each BE node. * Default:

3

* Action: Set this to

1

to minimize CPU impact. This will cause the

ALTER

operation to take longer but will significantly reduce the CPU load on your cluster. *

update_schema_worker_count

: Introduced in v3.2.3, this limits the maximum number of worker threads for schema update tasks in the BE's dynamic thread pool. * Default:

3

2. Limit Memory usage To prevent a large

ALTER

operation from consuming too much memory and potentially causing OOM (Out Of Memory) issues: *

memory_limitation_per_thread_for_schema_change

: Sets the maximum memory size allowed for each schema change task. * Default:

2

(GB) How to modify these limits at runtime Starting from StarRocks v2.4, many BE configurations are mutable and can be changed dynamically without restarting the BE nodes. You can modify them via SQL:

sql
-- Limit the schema change workers to 1 on all BE nodes to save CPU
UPDATE information_schema.be_configs 
SET VALUE = "1" 
WHERE NAME = "alter_tablet_worker_count";

Alternatively, you can use

curl

on each BE node:

bash
curl -X POST http://<be_ip>:<be_http_port>/api/update_config?alter_tablet_worker_count=1

Summary Recommendation If you are worried about a large

ALTER

operation impacting your production cluster's performance: 1. Lower the parallelism: Reduce

alter_tablet_worker_count

to

1

. 2. Monitor the progress: Use

SHOW ALTER TABLE COLUMN;

to track the status. 3. Schedule during off-peak: Since these are background asynchronous tasks, they will continue to run as long as the BE is up. Reducing the worker count is the best way to ensure they remain "background" tasks with minimal impact. References • faq/resource_isolation_faq.md • administration/management/BE_configuration.md • administration/management/monitoring/metrics.md