Cloudron Forum

Thx, I´ve look into that, it looks like the same!

Hi @girish that's understandable, profiling is beyond what Cloudron is meant to do. However it would be useful if the charts would be more accurate.

Imagine this usecase: You have an install with 10 apps. Suddenly there's a lot of incoming traffic on one of these apps, slowing the entire machine down. If this happens, at least you'd want to be able to quickly identify the app which should be stopped.

Anyways, it's understandable that this doesn't get much priority given the amazing popularity on this thread 🤣

@shifty thanks for the update! Glad it got solved.

Understood. I am in UK but use Hetzner in DE, and don't have any performance issues.

Looks good and prevents issues like looking wrong in a short sight. Thanks!

@girish Yes

@jpodner I had the same issue. Solved it by following the instruction on this page to extend my LVM space.

https://packetpushers.net/ubuntu-extend-your-default-lvm-space/

Btw, I applied the changes of the system.js according to the changelog to solve this problem in my environment until the update is available. So at least for myself this Post could be set to "solved".

@d19dotca to be honest, I think can be quite debatable, for example say three apps shape a rough sine curve across the time period, there would not be an easy visual winner. But what is also important here, currently we use what the graph library gives us and reworking this for little value is currently not worth while 🙂

@girish said in Cloudron 7.3.2: "Analyze Disk" doesn't do anything:

The code is not handling CIFS/SSHFS volumes correctly.

was not, is now?

@d19dotca ext4 is the filesystem type in this case from your root / partition and ext4 has a feature of reserved blocks for the root user. Other disks may or may not be ext4 like for volumes or backup.

Over the past few days, I've been getting alerts that apps are running out of memory that typically have had no issues after the past few days. The System Info / System Memory isn't showing any spikes in RAM usage. I'm still trying to run this down but having some trouble doing so and need to keep digging.

@robi Good point ... I think it's this way because one way to expand boxdata/appdata/platformdata is using symlinks. Then there's volumes , backups. So, it was easier to filter out by known filesystems.

@mehdi said in Disk IO Tracker:

just trying to periodically write stuff and checking the performance, as suggested, would not be great IMO, as it would 1/ be influenced by what's already running on the system 2/ wear out SSDs for little benefit

Agreed, there are better ways, the example was more for the output or datapoints.

Aspects of BPF tools make this light on resources, but there's a whole stack of tools down the line, including 'iolatency'.

I had the same question, thanks for the help

@girish said in Count of allocated memory:

We can improve our graphs section.

You can say that again! 😛

I find the memory usage graph to be pretty useless. A table with the values would be much more useful.

The full stack trace is:

16/07/2021 17:58:24 :: [console] Error writing to collectd.localhost.df-sdc1.df_complex-used: Unable to read header (/var/lib/graphite/whisper/collectd/localhost/df-sdc1/df_complex-used.wsp) 16/07/2021 17:58:24 :: [console] Unhandled Error Traceback (most recent call last): File "/usr/lib/python3/dist-packages/twisted/python/threadpool.py", line 266, in <lambda> inContext.theWork = lambda: context.call(ctx, func, *args, **kw) File "/usr/lib/python3/dist-packages/twisted/python/context.py", line 122, in callWithContext return self.currentContext().callWithContext(ctx, func, *args, **kw) File "/usr/lib/python3/dist-packages/twisted/python/context.py", line 85, in callWithContext return func(*args,**kw) File "/usr/lib/python3/dist-packages/carbon/writer.py", line 189, in writeForever writeCachedDataPoints() --- <exception caught here> --- File "/usr/lib/python3/dist-packages/carbon/writer.py", line 165, in writeCachedDataPoints state.database.write(metric, datapoints) File "/usr/lib/python3/dist-packages/carbon/database.py", line 124, in write whisper.update_many(path, datapoints) File "/usr/lib/python3/dist-packages/whisper.py", line 740, in update_many return file_update_many(fh, points, now) File "/usr/lib/python3/dist-packages/whisper.py", line 747, in file_update_many header = __readHeader(fh) File "/usr/lib/python3/dist-packages/whisper.py", line 294, in __readHeader raise CorruptWhisperFile("Unable to read header", fh.name) whisper.CorruptWhisperFile: Unable to read header (/var/lib/graphite/whisper/collectd/localhost/df-sdc1/df_complex-free.wsp)

The last line gives a hint that the graphite file is corrupt. So, I removed all the whisper files in /home/yellowtent/platformdata/graphite/whisper/collectd/localhost/df-sdc1 and graphs seems to work after that.

@atridad Maybe a good idea to check the health of the hard disk ? Also, since we hit the systemd issue on the same server.

@nebulon Yep, thank you, confirmed it reset itself.
Took >24 hours for recalculation but it is sorted 👍