[feature] persist recurring task timestamps in the database

[mirabilos]

Is your feature request related to a problem ?

The ability to manually set the schedule for one recurring task (media cleanup) was recently added.

However, it seems that, after (re‑)starting GtS, the task is always scheduled for the very next occurrence of the hour/minute given, even if it ran much less than media-cleanup-every (e.g. 72h) ago.

Describe the solution you'd like.

For those tasks, persist the time they last ran, so intermediate restarts of GtS won’t schedule them more often, but a start after having missed one will.

Describe alternatives you've considered.

Not restart GtS daily. (I’m doing so now, the daily restart was more of an attempt to get performance back under control on the old VM but I’ve moved to a new one, and it seems I underestimated the background jobs running on the old one.)

Additional context.

No response

[tsmethurst]

Why do you need to restart daily? I don't really understand. What's the performance gain here?

[mirabilos]

tobi dixit:

Why do you need to restart daily? I don't really understand. What's the performance gain here?

I used to, before moving to the new VM. I don’t think I need now. What I think happened is that some cronjob on the system from the other thing it runs swapped GtS’ cache memory, so access to it was slow; the restart also made it open new PostgreSQL connections which probably were less paged-out as well. It’s a thing I noticed, though, and media cleanup is a long task, so if it was just done before, say, a reboot for a new kernel, and is then done again, it’d be wasteful. bye, //mirabilos

[tsmethurst]

What I think happened is that some cronjob on the system from the other thing it runs swapped GtS’ cache memory, so access to it was slow

Ah okay, that's annoying!

Tracking task progress in the database is something we're considering for another feature (pausing/resuming/retrying message deliveries). This could be something we could fold into that work if time allows.

[mirabilos]

tobi dixit:

> What I think happened is that some cronjob on the system from the > other thing it runs swapped GtS’ cache memory, so access to it was > slow Ah okay, that's annoying!

Right. I severely underestimated what else was running on that VM, so (while I’m running GtS on a VM with 2 vCPU and 4 GiB RAM now) I think that it’s still possible to do so on the 1 vCPU, 1 GiB RAM setup, even with PostgreSQL.

Tracking task progress in the database is something we're considering for another feature (pausing/resuming/retrying message deliveries). This could be something we could fold into that work if time allows.

Ooh, that would be a good feature, could even enable pausing before an upgrade, then resume once the upgrade looks good, or something. Yeah, I thought GtS would have more than one thing where keeping track of it across restarts would be useful and combining that work making sense. bye, //mirabilos