Lots of database writes once an act_runner is registered and running #14252

New Issue

GiteaMirror · 2025-11-02T11:07:35-06:00

GiteaMirror commented

2025-11-02 11:07:35 -06:00

Originally created by @jhe2 on GitHub (Mar 14, 2025).

Description

As soon as there is an act_runner (v0.2.11) running (even if it is idle), there appears to be a constant flow of database updates.
As far as I can tell, this is due to the last_online field in the act_runner table being updated all the time.
By default this happens every two seconds for each act_runner. I would much prefer if there were no database writes while the runners are idle. I couldn't find a way to disable this behavior. It would be nice to have an option to disable this or possibly keep the last_online value in memory only instead of writing it to the database.

Thanks for the great work on Gitea!

Gitea Version

1.23.5

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

2.48.1

Operating System

Alpine Linux (edge)

How are you running Gitea?

I'm using the Gitea package provided by Alpine Linux.

Database

SQLite

Originally created by @jhe2 on GitHub (Mar 14, 2025). ### Description As soon as there is an act_runner (v0.2.11) running (even if it is idle), there appears to be a constant flow of database updates. As far as I can tell, this is due to the `last_online` field in the `act_runner` table being updated all the time. By default this happens every two seconds for each act_runner. I would much prefer if there were no database writes while the runners are idle. I couldn't find a way to disable this behavior. It would be nice to have an option to disable this or possibly keep the `last_online` value in memory only instead of writing it to the database. Thanks for the great work on Gitea! ### Gitea Version 1.23.5 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version 2.48.1 ### Operating System Alpine Linux (edge) ### How are you running Gitea? I'm using the Gitea package provided by Alpine Linux. ### Database SQLite

GiteaMirror added the topic/gitea-actions label 2025-11-02 11:07:35 -06:00

GiteaMirror commented

2025-11-02 11:07:36 -06:00

@philiprenich commented on GitHub (Mar 27, 2025):

Curious about this as well. Realised the hdd was just constantly going and have tracked it down to this file. Would like a quieter system when idle.

@philiprenich commented on GitHub (Mar 27, 2025): Curious about this as well. Realised the hdd was just constantly going and have tracked it down to this file. Would like a quieter system when idle.

GiteaMirror commented

2025-11-02 11:07:36 -06:00

@lunny commented on GitHub (Mar 27, 2025):

This isn’t a bug — it’s the intended behavior. That said, I agree it’s not a great design. The key question is: what’s the actual impact of this behavior?

@lunny commented on GitHub (Mar 27, 2025): This isn’t a bug — it’s the intended behavior. That said, I agree it’s not a great design. The key question is: what’s the actual impact of this behavior?

GiteaMirror commented

2025-11-02 11:07:37 -06:00

@philiprenich commented on GitHub (Mar 28, 2025):

@lunny Thanks for the reply. As their is a call to the Gitea server each time, it makes for very loud logs. This makes it hard to investigate issues looking through those logs. My assumption would there is good log rotation so they aren't slowly eating up storage space? Constant log writing and database editing is going to be a bit wearing on the hardware I would imagine (though probably fairly minor).

I'm fully self-hosted (that is, a server in my living room) so while excess writes and storage isn't a crucial issue, it's a bigger deal for my situation than if I was using a cloud service provider who will swap the hardware for me in a timely (and experienced!) manner.

I'm not sure if a potential solution would be allowing the timing to be customised (feels like kicking the can down the road) or a different design.

I hope that helps! If my assumptions/worries are baseless, feel free to correct them!

@philiprenich commented on GitHub (Mar 28, 2025): @lunny Thanks for the reply. As their is a call to the Gitea server each time, it makes for very loud logs. This makes it hard to investigate issues looking through those logs. My assumption would there is good log rotation so they aren't slowly eating up storage space? Constant log writing and database editing is going to be a bit wearing on the hardware I would imagine (though probably fairly minor). I'm fully self-hosted (that is, a server in my living room) so while excess writes and storage isn't a crucial issue, it's a bigger deal for my situation than if I was using a cloud service provider who will swap the hardware for me in a timely (and experienced!) manner. I'm not sure if a potential solution would be allowing the timing to be customised (feels like kicking the can down the road) or a different design. I hope that helps! If my assumptions/worries are baseless, feel free to correct them!

GiteaMirror commented

2025-11-02 11:07:37 -06:00

@jhe2 commented on GitHub (Mar 28, 2025):

This isn’t a bug — it’s the intended behavior. That said, I agree it’s not a great design.

What's the purpose of those database updates? Is it just for the user to be able to see when the act_runner last talked to Gitea or is that information used for something else as well? As far as I can tell, Gitea doesn't really need this information since the act_runners actively ask for new tasks anyway, but maybe I am missing something here.

Constant log writing and database editing is going to be a bit wearing on the hardware I would imagine

It is and on SSDs it is actually quite a bit more than what one might expect due to write amplification of SSDs and due to the fact that each database write - no matter how small it is - is followed by an fsync call. Of course using fsync makes perfect sense for a database to ensure its consistency, but that also means that the OS can't batch all those small write into fewer larger ones. Neither can the SSD do it.

I also noticed that the SSD in my server runs several degrees hotter with an act_runner active, probably because the SSD can never enter its power saving states due to the constant stream of writes.

Without act_runners active, Gitea appears to write very little to disk, if nothing is going on, which is nice.

@jhe2 commented on GitHub (Mar 28, 2025): > This isn’t a bug — it’s the intended behavior. That said, I agree it’s not a great design. What's the purpose of those database updates? Is it just for the user to be able to see when the act_runner last talked to Gitea or is that information used for something else as well? As far as I can tell, Gitea doesn't really need this information since the act_runners actively ask for new tasks anyway, but maybe I am missing something here. > Constant log writing and database editing is going to be a bit wearing on the hardware I would imagine It is and on SSDs it is actually quite a bit more than what one might expect due to write amplification of SSDs and due to the fact that each database write - no matter how small it is - is followed by an fsync call. Of course using fsync makes perfect sense for a database to ensure its consistency, but that also means that the OS can't batch all those small write into fewer larger ones. Neither can the SSD do it. I also noticed that the SSD in my server runs several degrees hotter with an act_runner active, probably because the SSD can never enter its power saving states due to the constant stream of writes. Without act_runners active, Gitea appears to write very little to disk, if nothing is going on, which is nice.

GiteaMirror commented

2025-11-02 11:07:37 -06:00

@lunny commented on GitHub (Mar 28, 2025):

Yes, just store the last active time. Maybe the state can be stored in memory/redis.

@lunny commented on GitHub (Mar 28, 2025): Yes, just store the last active time. Maybe the state can be stored in memory/redis.

GiteaMirror commented

2025-11-02 11:07:37 -06:00

@ashleysommer commented on GitHub (Aug 23, 2025):

I just came across this same issue. My mini home server that hosts my git forge is on my shelf right next to my desk in my office, and when its 4 hard disks are active its noticeably loud. Yesterday I enabled a runner, and since then my server has been spinning up its disks every 2 seconds to write to the sqlite db. Its very distracting, and I feel like it can't be good for my disks.
Is there a way to disable this "last online" update? or store it in memory and commit to disk on shutdown, or even once every 10 minutes?
For now, I've just shut down my runner. I'll turn it back on only when I need to use it.

@ashleysommer commented on GitHub (Aug 23, 2025): I just came across this same issue. My mini home server that hosts my git forge is on my shelf right next to my desk in my office, and when its 4 hard disks are active its noticeably loud. Yesterday I enabled a runner, and since then my server has been spinning up its disks every 2 seconds to write to the sqlite db. Its very distracting, and I feel like it can't be good for my disks. Is there a way to disable this "last online" update? or store it in memory and commit to disk on shutdown, or even once every 10 minutes? For now, I've just shut down my runner. I'll turn it back on only when I need to use it.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#14252