CPU spike every 5 minutes by send_file_updates

bagey · July 6, 2024, 9:21am

Hi guys,

I have Seafile running in a docker container, on Unraid, and it has been running very smoothly for the past couple of months. However, a couple of weeks ago I noticed that the CPU has started to spike very 5 minutes, precisely. After a bit of investigation, and looking at the running processes, the culprit seems to be the send_file_updates script, as can be seen in the screenshot below.

Checking the logs also confirms that it is running precisely every 5 minutes, as is evident in the file_updates_sender.log.

[2024-07-05 20:39:55.854150] Start sending file updates emails...
[2024-07-05 20:39:55.855415] Finish sending file updates emails.

[2024-07-05 20:44:56.981069] Start sending file updates emails...
[2024-07-05 20:44:56.982195] Finish sending file updates emails.

[2024-07-05 20:49:58.108328] Start sending file updates emails...
[2024-07-05 20:49:58.109705] Finish sending file updates emails.

[2024-07-05 20:54:59.230314] Start sending file updates emails...
[2024-07-05 20:54:59.231392] Finish sending file updates emails.

[2024-07-05 21:00:00.356757] Start sending file updates emails...
[2024-07-05 21:00:00.357850] Finish sending file updates emails.

The earliest entry in these logs are from a couple of weeks ago, which also confirms that this only recently started happening.

Checking the seafevents.log after stopping and starting the container, now also has an entry for starting the service at an interval of 300 seconds, i.e. 5 minutes.

[2024-07-05 20:34:54,885] [INFO] Start file updates sender, interval = 300 sec

I had not made any changes to the server prior to this occurring, and was left running perfectly fine for a couple of months. Any idea as to why this suddenly has started happening, and is there a way to disable it?

Things I’ve tried

Upgraded from CE to PE
Disabled all forms of e-mail notifications
Enabled notification server
Clearing the UserActivity table as was suggested in another post (can’t seem to insert links)

Another user seems to have a similar issue, but was never able to fix it, and no solution was proposed (again, can’t seem to insert links to the post).

So I’m hoping with a bit more documentation, that we will be able to get to the bottom of this.

Thanks guys.

daniel.pan · July 6, 2024, 9:48am

This issue should have already been fixed. What version do you use now?

bagey · July 6, 2024, 9:57am

Hi Daniel,

I appreciate the quick response!

My mistake, I should have included that. The Community Edition was running version 11.0.8, and Professional Edition is running 11.0.9. Which version was this fixed in?

bagey · July 8, 2024, 9:42pm

@daniel.pan

You mentioned that this should already have been fixed, in which version?

Do you have any idea why this might still be happening, and if there is a way to disable it?

daniel.pan · July 9, 2024, 2:25am

Updated: this problem has not been fixed yet.

This is caused by some users have many file modification records to be sent.

A way to fix the issue temporary is to clean the activities table and only keep recent 30 days.

bagey · July 9, 2024, 10:44am

I’ve tried clearing the Activity table, as well as the UserActivity table, and even completely disabling history, but the send_file_updates are still being triggered.

I queried the Activity and UserActivity tables, after I cleared them, to make sure that they are indeed now empty.

MariaDB [seahub_db]> SELECT * FROM Activity;
Empty set (0.000 sec)

MariaDB [seahub_db]> SELECT * FROM UserActivity;
Empty set (0.000 sec)

Is there something I’m missing cache wise, that causes the script to still being called?

Edit: I have also stopped and started the containers after doing all this.

daniel.pan · July 9, 2024, 12:41pm

I have rechecked your logs. It shows that the file_updates_sender takes less than 1 second. So it is not the file_updates_sender take up the CPU.

I suggest you check which process make the CPU spike again.

bagey · July 9, 2024, 8:30pm

Hmmm, well the CPU spike I am experiencing does not last more than a second, so I still think that send_file_updates is very likely the culprit.

I did go back and monitor the CPU usage, just in case. And every 5 minutes, at the top of the list, is the send_file_updates. Which also corresponds exactly with every log entry in file_updates_sender.log. No other process seems to be even close in CPU usage.

If I stop the Seafile containers, then the CPU stops spiking every 5 minutes.

Earlier you seemed to think that this was already fixed. Is this then not a bug that you are currently working on?

andre.luettig · January 28, 2025, 8:47pm

Hi!

I think I found a solution which works for my use case, although I don’t know about the implications of it. I’m also a community edition user, and was also experiencing those spikes, with the same process being responsible. I use seafile server version 12.0.7.

I went ahead into the container, and changed the file in /opt/seafile/seafile-server-latest/pro/python/seafevents/tasks, so the line with FileUpdatesSenderTimer(self._interval, self._logfile).start() is commented out (as # FileUpdatesSenderTimer(self._interval, self._logfile).start()). I’m not sure if there is a good reason something from the pro version is enabled, and as I stated I’m not sure what further implications of this can be, but without the FileUpdateSender the cpu spikes are gone.

These changes of course will also go whenever the seafile image is updated to a newer version if the recommended docker setup is used.

Maybe there is also a less hacky way, by changing a configuration, or maybe this can help in fixing the bug, but I haven’t found anything myself yet.