You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've deployed an app on AWS and mistakenly configured Q to use the database, which prevented the db from going to sleep and costing us more than anticipated. Having fixed that, it seems that somehow a lone connection to the database is either kept or quickly reconnected upon disconnect, preventing the db from sleeping.
The settings are simple enough (where DB_CONN_MAX_AGE is 60 anyways)
Tasks are executed each couple of hours so I'd expect the connection to cut until the broker figures out is has to execute something, but there's that one connection that keeps on going even if all instances but the q cluster instance are off.
(Here the part with 0 connections was a shutdown)
Any ideas?
The text was updated successfully, but these errors were encountered:
The scheduler works by checking the schedule database every 30 seconds for schedules that fall within the current timespan and then creates a task for them. This to cater for minute schedules and one-off scheduled tasks create through the code.
You can turn off the scheduler to prevent the polling, but that's probably not what you want.
We could add a way of reducing the poll interval, but that would then affect the accuracy of the schedules.
Thinking out loud here: If I had a different database for scheduling, which would be simple, light and cheap, that would kind of fix my always-on problem, right? Does Django Q support accessing another database?
Alternatively, I suppose a solution would be to interact with the POLL config value?
POLL=conf.get("poll", 0.2)
edit: nope
Sets the queue polling interval for database brokers that don’t have a blocking call. Currently only affects the ORM and MongoDB brokers. Defaults to 0.2 (seconds).
We've deployed an app on AWS and mistakenly configured Q to use the database, which prevented the db from going to sleep and costing us more than anticipated. Having fixed that, it seems that somehow a lone connection to the database is either kept or quickly reconnected upon disconnect, preventing the db from sleeping.
The settings are simple enough (where DB_CONN_MAX_AGE is 60 anyways)
Tasks are executed each couple of hours so I'd expect the connection to cut until the broker figures out is has to execute something, but there's that one connection that keeps on going even if all instances but the q cluster instance are off.
(Here the part with 0 connections was a shutdown)
Any ideas?
The text was updated successfully, but these errors were encountered: