[Solved] Incerasing server load - Too many "send_file_updates" processes

Hello,

I am running Seafile Pro 7.1.7 under Debian Buster (10.8).
This morning the server went down under a very important charge (42 according to top…).
Seahub and Seafile were not responding, so we decided to restart everything.
Later on this afternoon the problem occured again.
We have a very important CPU load with many pyhton processes ran by seafile user.
If we look at the different processes here is what we have :

   580 ?        Ssl    0:00 /usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal
   894 ?        S      0:01 python3 /seafile/seafile-pro-server-7.1.7/seahub/thirdpart/bin/gunicorn seahub.wsgi:application -c /seafile/conf/gunicorn.conf.py --preload
   901 ?        Sl     0:27 /usr/bin/python3 -m seafevents.main --config-file /seafile/conf/seafevents.conf --logfile /seafile/logs/seafevents.log -P /seafile/pids/seafevents.pid
   935 ?        S      0:00 /bin/sh -c "/usr/bin/python3" "/seafile/seafile-pro-server-7.1.7/pro/python/seafevents/office_converter/convert_server.py" "--outputdir" "/tmp/seafile-office-output" "--workers" "1" "--max_pages" "50" "--host" "127.0.0.1" "--port" "6000"
   936 ?        Sl     0:01 /usr/bin/python3 /seafile/seafile-pro-server-7.1.7/pro/python/seafevents/office_converter/convert_server.py --outputdir /tmp/seafile-office-output --workers 1 --max_pages 50 --host 127.0.0.1 --port 6000
   973 ?        S      0:02 python3 /seafile/seafile-pro-server-7.1.7/seahub/thirdpart/bin/gunicorn seahub.wsgi:application -c /seafile/conf/gunicorn.conf.py --preload
   974 ?        S      0:14 python3 /seafile/seafile-pro-server-7.1.7/seahub/thirdpart/bin/gunicorn seahub.wsgi:application -c /seafile/conf/gunicorn.conf.py --preload
   975 ?        S      0:07 python3 /seafile/seafile-pro-server-7.1.7/seahub/thirdpart/bin/gunicorn seahub.wsgi:application -c /seafile/conf/gunicorn.conf.py --preload
   976 ?        S      0:05 python3 /seafile/seafile-pro-server-7.1.7/seahub/thirdpart/bin/gunicorn seahub.wsgi:application -c /seafile/conf/gunicorn.conf.py --preload
   977 ?        S      0:03 python3 /seafile/seafile-pro-server-7.1.7/seahub/thirdpart/bin/gunicorn seahub.wsgi:application -c /seafile/conf/gunicorn.conf.py --preload
  4035 ?        S      0:00 /bin/sh -c "/usr/bin/python3" "/seafile/seafile-pro-server-7.1.7/seahub/manage.py" "send_file_updates"
  4036 ?        R      8:01 /usr/bin/python3 /seafile/seafile-pro-server-7.1.7/seahub/manage.py send_file_updates
  4124 ?        S      0:00 /bin/sh -c "/usr/bin/python3" "/seafile/seafile-pro-server-7.1.7/seahub/manage.py" "send_file_updates"
  4125 ?        R      7:44 /usr/bin/python3 /seafile/seafile-pro-server-7.1.7/seahub/manage.py send_file_updates
  4188 ?        S      0:00 /bin/sh -c "/usr/bin/python3" "/seafile/seafile-pro-server-7.1.7/seahub/manage.py" "send_file_updates"
  4189 ?        R      7:12 /usr/bin/python3 /seafile/seafile-pro-server-7.1.7/seahub/manage.py send_file_updates
  4251 ?        S      0:00 /bin/sh -c "/usr/bin/python3" "/seafile/seafile-pro-server-7.1.7/seahub/manage.py" "send_file_updates"
  4252 ?        R      6:35 /usr/bin/python3 /seafile/seafile-pro-server-7.1.7/seahub/manage.py send_file_updates
  4269 ?        S      0:00 /bin/sh -c "/usr/bin/python3" "/seafile/seafile-pro-server-7.1.7/seahub/manage.py" "send_file_updates"
  4270 ?        R      6:03 /usr/bin/python3 /seafile/seafile-pro-server-7.1.7/seahub/manage.py send_file_updates

The last two lines keep repeating for a while, load the server and jamming the service.

Could anyone tell me what is going on ?

Thanks !

Hello Seafile Community,

OK we found the problem… We’ve changed the Seahub mail server configuration earlier this week and obviously it was erroneous. We switched back to the old mail configuration, restarted the services and everything went back to normal.
I hope this will help someone else :slight_smile:

Well… the problem has finally not been solved… The server load started to rise again this morning.
I sent a shared linked successfully, so the the SMTP parameters are not wrong…

Hello,
We flushed the UserActivity table within the seahub-db database and it solved the problem.
At least, for now :slight_smile:

1 Like