High cpu utilization since update 1.25.1
-
@humptydumpty said in High cpu utilization since update 1.25.1:
Shoutout to stumpylog (paperless maintainer) for the fix. Using the file manager, browse to /app/data/data and delete celerybeat-schedule.db.db and restart the
serverapp. CPU usage went down for me. Hopefully, it stays that way.So it was not a Cloudron issue in the end?
@necrevistonnezr we still don’t know the root cause of the file corruption. It could happen again anytime. Upstream closed the discussion and moved on. It looks like only Cloudron users are affected on existing installs and not on a fresh app. App update snafu?
Btw, upstream said the +500mb ram on idle is normal. I don’t get why it should be that high.
-
@nebulon I uploaded the corrupted db file upstream as requested.. edit: just realized I can copy the github link https://github.com/user-attachments/files/16591433/celerybeat-schedule.db.zip
I'll keep the cloned app for the time being. Please let me know if you need more info.
-
N necrevistonnezr referenced this topic on
-
CPU is high again on Paperless-ngx 2.11.6. Deleting the celery file and restarting still works as a temp fix. I did turn off the server today and updated the BIOS. Idk if that has anything to do with it.
-
N nebulon referenced this topic on
-
N nebulon referenced this topic on
-
-
It's going nuts again after it updated to 1.27 then 1.28 today.
edit: This time I had to delete the celery file and restart the app twice for the fix to work.
-
N nebulon referenced this topic on
-
Just an FYI, it's still recurring on v.1.3.2.
-
Same issue for me. I ran cloudron as a VM on unraid and on proxmox, on 2 different hosts and with and without a CIFS mount as consume folder. The issue recurred in every constellation.
-
@flwd said in High cpu utilization since update 1.25.1:
The issue recurred in every constellation
What does this mean?
@joseph installation typo would be my guess
-
@flwd said in High cpu utilization since update 1.25.1:
The issue recurred in every constellation
What does this mean?
-
@joseph it occured in every installation variant i tried, independant of the CIFS mount and config.
-
@flwd thanks for the clarification. I think the original issue atleast was narrowed down to celery database going corrupt and it's not related to volume type. Have you tried deleting that database pointed out earlier in the thread?