Details
-
New Feature
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
*Overview:
*In today's cloud-native deployments, MariaDB Server must adapt to dynamic resource changes without downtime. Currently, the thread pool is configured based on available CPUs only at startup, so if CPUs are added or removed, the server doesn't automatically adjust, potentially limiting performance.
*Current State:
*
Static CPU-Based Settings: Thread pool settings are fixed at startup and do not respond to changes.Dynamic Environments: In Kubernetes-managed deployments, CPU resources can be scaled up or down on the fly.Auto-Scaling Considerations: Adjustments must support both scaling up (adding CPUs) and scaling down (removing CPUs) without affecting active connections.
*Proposed Feature:
*Introduce a mechanism that:
- Monitors CPU Resources: Uses OS-level notifications or periodic checks to detect changes in available CPUs/vCPUs.
Auto-Scales Thread Pool Parameters:
- Scaling Up: When additional CPUs are detected, the thread pool's maximum thread count and related settings are increased to fully utilize the new resources.
- Scaling Down: When CPUs are removed, the system gracefully reduces the thread pool size, ensuring active threads complete their work before termination.
- Ensures Stability: Adjusts parameters dynamically without requiring a server restart, preserving existing connections and workload continuity.
*Benefits:
*
Optimized Performance: Dynamically adjusts to fully leverage available resources, reducing latency and improving throughput.
Enhanced Flexibility: Adapts in real time to auto-scaling events in cloud environments.
Seamless Scaling: Supports both upward and downward scaling, ensuring efficient resource utilization without disruption.
Attachments
Activity
What about thread_handling? That thing allows you to use pool-of-threads, this is how you switch it on. It not a thread_pool_whatever parameter, it is a parameter than allows thread pool in the first place. If there is a need to emulate thread-per-connection with threadpool (why), I'm sure it can be done relatively trivially , with a parameter that would disable yielding "yield" after a query . But we already have a way where threadpool and thread-per-connection coexist (the scheduler on extra-port would be thread-per-connection, if extra-port is enabled)
You do know that thread_pool_size and the most other parameters are dynamic parameter, does not require server restart, "preserving existing connections and workload continuity"?
Also, the actual thread count always dynamic, depends on the load, ranges from thread_pool_min_threads to thread_pool_max_threads (which are also dynamic), and restricting thread_pool_max_threads is not usually required.
"Static CPU-Based Settings: Thread pool settings are fixed at startup and do not respond to changes." This is wrong. I can't think of even a single thread-pool related setting that would be static (except "thread-pool-mode" on Windows, that switches implementation from unix-alike to Windows native). Except the setting, the whole nature of this threadpool is dynamic, adding and taking away threads as workload changes.
There is no detection of CPU count, builtin, but anything that can detect it can issue "set global thread_pool_size=<new_count>" to modify the setting (which is allegedly fixed at startup
)