-
Notifications
You must be signed in to change notification settings - Fork 246
[Feature] It's time to discard the resource queue #1721
Description
It's time to discard the resource queue
According to the evolution trend of GPDB, the following changes are suggested for CBDB resource management:
1. Abandoned resource queue function.
Resource queues were an early resource management approach implemented by GPDB. Because cgroup was not yet mature at that time, GPDB fully implemented the CPU resource control function on its own.
Later, the resource group management function was added, with the aim of replacing the resource queue. From the current perspective, resource groups can already cover all the functions of resource queues.
The GPDB community has repeatedly expressed plans for deprecating resource queue, and judging from the code evolution trend, it is also moving in this direction.
2. A new resource management method of type "none" has been added and set as the default value.
GPDB has added a "none" type of resource management, which adopts PostgreSQL's native resource management approach, utilizing neither resource queue nor resource group.
Setting "none" as the default resource management method reduces access to global locks. Currently, CBDB defaults to the resource queue method, where each query acquires the ResQueueLock global lock at least twice. Under high concurrency, the cost associated with global locks increases sharply.
See greenplum-db/gpdb-archive@82851a0
中文:
是时候废弃资源队列了
按照GPDB的演进趋势,建议CBDB资源管理做以下变更:
1. 废弃资源队列功能
资源队列是GPDB早期实现的资源管理方式。因为当时cgroup尚不成熟,所以GPDB完全是自行实现了CPU资源控制功能。
之后增加了资源组管理功能,目的是替代资源队列。从目前来看,资源组已经可以覆盖资源队列的全部功能。
GPDB社区曾经多次表达了废弃资源队列的计划,从代码演进趋势来看也是朝着这个方向。
2. 新增none类型的资源管理方式,并作为默认值。
GPDB新增了一种none类型的资源管理方式,即:采用PgSQL原有的资源管理方式,既不使用资源队列也不使用资源组。
默认使用none类型的资源管理方式,减少全局锁访问。CBDB目前默认为资源队列方式,该方式每个查询至少Lock 2次ResQueueLock全局锁。
在高并发情况下,全局锁的代价会陡增。
参阅:greenplum-db/gpdb-archive@82851a0
Use case/motivation
No response
Related issues
No response
Are you willing to submit a PR?
- Yes I am willing to submit a PR!
All reactions
-
👍 2
It's so hard to decide. This code has been with us for so many years. But generally, I agree that resource queues don't work. Once, by mistake, we turned them on in one of the production clusters, and then we spent a long time to find out why performance dropped so much. It is better to remove them. Outdated functionality only confuses users.
Replies: 2 comments
It's so hard to decide. This code has been with us for so many years. But generally, I agree that resource queues don't work. Once, by mistake, we turned them on in one of the production clusters, and then we spent a long time to find out why performance dropped so much. It is better to remove them. Outdated functionality only confuses users.
All reactions
Really like the direction — both points align with where GPDB has been heading, and the ResQueueLock argument for flipping the default to none is compelling on its own. The referenced commit (82851a0) gives a clean blueprint. 👍
A few clarifying questions before this turns into a PR, mostly to scope it cleanly:
1. "Discard" — full removal, or default-off + deprecate? The title says discard, but GPDB's landed approach was closer to "default none, keep the queue implementation around." Very different in effort: full removal means dropping pg_resqueue, the CREATE/ALTER/DROP RESOURCE QUEUE DDL, queue-aware executor paths, and an upgrade story. I'd lean toward default-off + deprecate for at least one release — which did you have in mind?
2. Upgrade semantics. For clusters today with gp_resource_manager = 'queue' or populated pg_resqueue — does the default flip apply only to fresh initdb, or also pg_upgrade? Safest: existing explicit config keeps working, default change is fresh-cluster only.
3. Migration guide. Most resource-queue fields map cleanly to resource groups, but cost-based admission (MAX_COST / MIN_COST / COST_OVERCOMMIT) has no 1:1 equivalent — worth calling out what we recommend users do with those. 🙏