Details
-
Task
-
Status: Stalled (View Workflow)
-
Major
-
Resolution: Unresolved
Description
To quote Daniel Black from MDEV-5536:
If something like a max_idle_execution time maybe. There are avenues for integration with RuntimeMaxSec and extending timeout of runtime, and/or purely terminating the listening execution loop if no new connections are happening or queries running.
But please, new issue and state the requirement first.
Documentation will be coming in the next week or so https://mariadb.com/kb/en/systemd/
Use case: Socket activation of MariaDB is useful in several environments, including database farms and development stacks. If you value launching MariaDB lazily, though, you're likely to value putting it back into the "lazy launching" state after a period of idleness.
Put another way, if you're willing to launch MariaDB on the first access after boot, why wait until rebooting (most likely) to put it back into that state? Whether MariaDB is stopped ought not depend on whether the last query or a reboot occurred most recently, especially after days of time.
Implementation: Given that shutting down MariaDB on idleness makes the most sense when there's a way to wake it up again, I agree that using RuntimeMaxSec with socket activation is a sensible implementation path. It seems like the service could leverage EXTEND_TIMEOUT_USEC when it receives a query, consistent with the direction Daniel Black suggested above.
To avoid invoking EXTEND_TIMEOUT_USEC excessively, I would consider only sending it if the last invocation was more than some number of seconds ago (or, perhaps, by proportion of the configured idle shutdown duration). This will barely impact the delay before shutdown but spare systemd an incredible volume of extension requests when the database is active.
Attachments
Issue Links
- relates to
-
MDEV-5536 Support systemd socket activation
- Closed