Managing Resources
Greenplum Database provides features to help you prioritize and allocate resources to queries according to business requirements and to prevent queries from starting when resources are unavailable.
You can use resource management features to limit the number of concurrent queries, the amount of memory used to execute a query, and the relative amount of CPU devoted to processing a query. Greenplum Database provides two schemes to manage resources - Resource Queues and Resource Groups.
Important: Significant Greenplum Database performance degradation has been observed when enabling resource group-based workload management on RedHat 6.x, CentOS 6.x, and SuSE 11 systems. This issue is caused by a Linux cgroup kernel bug. This kernel bug has been fixed in CentOS 7.x and Red Hat 7.x systems, and on SuSE 12 SP2/SP3 systems with kernel version 4.4.73-5.1 or newer.
If you use RedHat 6 and the performance with resource groups is acceptable for your use case, upgrade your kernel to version 2.6.32-696 or higher to benefit from other fixes to the cgroups implementation.
SuSE 11 does not have a kernel version that resolves this issue; resource groups are still considered to be a Beta feature on this platform. Resource groups are not supported on SuSE 11 for production use.
Either the resource queue or the resource group management scheme can be active in Greenplum Database; both schemes cannot be active at the same time.
Resource queues are enabled by default when you install your Greenplum Database cluster. While you can create and assign resource groups when resource queues are active, you must explicitly enable resource groups to start using that management scheme.
The following table summarizes some of the differences between Resource Queues and Resource Groups.
| Metric | Resource Queues | Resource Groups |
|---|---|---|
| Concurrency | Managed at the query level | Managed at the transaction level |
| CPU | Specify query priority | Specify percentage of CPU resources; uses Linux Control Groups |
| Memory | Managed at the queue and operator level; users can over-subscribe | Managed at the transaction level, with enhanced allocation and tracking; users cannot over-subscribe |
| Memory Isolation | None | Memory is isolated between resource groups and between transactions within the same resource group |
| Users | Limits are applied only to non-admin users | Limits are applied to SUPERUSER and non-admin users alike |
| Queueing | Queue only when no slot available | Queue when no slot is available or not enough available memory |
| Query Failure | Query may fail immediately if not enough memory | Query may fail after reaching transaction fixed memory limit when no shared resource group memory exists and the transaction requests more memory |
| Limit Bypass | Limits are not enforced for SUPERUSER roles and certain operators and functions |
Limits are not enforced on SET, RESET, and SHOW commands |
| External Components | None | Manage PL/Container CPU and memory resources |
Parent topic: Managing Performance
