Problem is the parts that are using the most CPU are : / is using 793-796 % CPU 14.3 Gb MEMORY cron.service 300+ % CPU 13 GB MEMORY system.slice docker.service box.service user.slice containerd.service Another problem or discrepancies I'm seeing if I dive into containers themselves is that it seems the containers that are using more CPU, the ones that often comes on top, are not tied to any domain/app in particular. if I docker ps a specific container i see on the systemd-cgtop no matter what I try to match them I cannot associate these containers ID to my list of ID-Domains when I type cloudron list it's like our box is running more containers than the number of app we have ? can a container be on the loose and still running and using resources ? It does not make sense I know

@roru2k20 said in Disk usage is not showing: @girish said in Disk usage is not showing: we only scan ext4 disks I think that is the reason for both problem. I use a cifs Share and @necrevistonnezr use a ext2 Partition Format. I try temporarily to unmount my backup drive and look into the view. But only /boot is formatted with ext2?! (and I don’t really know why...)

Just leaving a note for myself, but it's unclear why the issue got fixed after the update. After an app update, the container is recreated and the collectd config is regenerated. Maybe the collectd restart did the trick.

@nebulon Thanks for your reply. After thinking about it, the graph chosen is better to view memory usage (which fluctuate much more than disk). I would then suggest separating both information: keep the current graph for the app usage (the Y axis adapting to the app using the most memory) add a bar for total memory used, modelled on the total disk usage (could be a single colour for memory usage) This would help maximize the amount of information you can visualize in one go and help detect spikes better.

@ice The Cloudron disk graphs is computed only twice a day. So, please check after atleast 12 hours of the disk resize.

@smilebasti The /home/yellowtent/appsdata is the location of apps. This size seems to roughly match the nextcloud size. As for docker, you should not use du tools inside docker's image directories since they are overlays and the du tool is not smart enough to figure out the size correctly. Try docker system df to get a better idea about the actual size docker uses (this is what is reported in the graph as ~5GB). The volumes also link into appsdata so they might be double counted the du tools. To take a wild guess, maybe you were backing up to the file system for some time before you moved to NAS via SMB? If this was the case, then you should remove the old backups manually from /var/backups. You can just safely nuke all the timestamped directories and the snapshot directory inside it.

@nebulon about 15-20 every second. When it stops there is a line box:apphealthmonitor app health: 28 alive / 4 dead. Nothing about accessing any sites though.

@girish That's perfect, thank you so much!

@ruihildt Thanks for reporting. This is fixed in the coming release - https://git.cloudron.io/cloudron/box/-/blob/master/CHANGES#L1930

@ruihildt The issue in your case was different. There were so many apps that the query parameter limit was getting exceeded. This is fixed in next release. @necrevistonnezr this is most likely your issue as well!

Agree, the memory graphs are quite rudimentary at this point. We will rework them to be more useful and correct at some point.

Finally, one important bit: by default ext4 will reserve 5% of the disk for the root user. You can see this like so: root@strawberry:~# tune2fs -l /dev/sda1 | grep Reserved Reserved block count: 1562918 Reserved GDT blocks: 1024 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) 1562918 blocks * 4096 block size = ~6GB. You can reduce the percent to say 2 like this: tune2fs -m 2 /dev/sda1 Unless you have a big disk, I would leave it at 5%.

In the past, I think people have recommended integrating with netdata. I don't have experience with netdata but wanted to throw the idea out there. Other than that, current graphs is rendered using data collected by graphite/carbon.

This is fixed now, will be part of next release.

Interesting, this was simply missed I guess. I have added it now and it will be part of the next release. It will look like this then:

Thanks, investigating this. I suspect the node module is unable to parse the output because of something in the output. I will keep you posted here.

I had to do the same thing before it was implemented to be changed under System -> Services in cloudron. By the way, the documentation is missing for it

@nebulon nevermind. It fixed itself. Weird.