Cloudron Forum

Stubborn dog-with-a-bone that I am, I did more research, and hopefully this can put to bed my diversion of the thread (sorry), and maybe help others with a similar use case / workflow objective to mine : Forgejo (official Cloudron AppStore) provides standard git source code functionality AND it has a built-in container registry functionality so no need to consider changes to the official docker registry app for public pulls forgejo supports private and public repos (which git.cloudron.io does not) forgejo supports public image pulls (like hub.docker.com) but also multiple private containers (hub.docker.com only allows 1) I can uninstall docker registry app and gitea/gitlab apps, multiple used for segregating cloudron community work from closed app dev, using Forgejo organization instead. So the answer for my bandwidth-limited brain of 1 app for (almost) everything seems to be Forgejo (available today, no dev work). However, @girish made valuable comment that hosting container images is a disk/network usage risk. Even for a small dev footprint like mine, this could be critical (let alone Cloudron scale). I need to think & test out, but maybe Forgejo actions can automate container push to hub.docker.com, and do automated cleanup in the instance. So from dev point of view it's a single answer (Forgejo) with CI/CD offloading disk/network risks to hub.docker.com (or whatever).

Not knowing what your scripts do, it's difficult. If they do many things, can you slow them down and serialize them or chunk them into smaller pieces that need less memory to run?

Here is a more complete analysis of the disk I/O across all 3 servers. 1. Cloudron Disk I/O graph (server 1, last 6 hours) [image: 1773182644022-scherm-afbeelding-2026-03-10-om-23.40.17-resized.png] The graph shows a constant write baseline of ~2.5 MB/s, 24/7. The spike around 20:00 is the scheduled daily backup — completely normal. The total write of 646 GB over 2 days (~323 GB/day) is almost entirely this constant baseline, not user traffic or backups. 2. iotop breakdown (server 1, 1 minute measurement) Docker MySQL (messageb): 48.62 MB/min (~0.81 MB/s) Host MySQL: 23.26 MB/min (~0.39 MB/s) go-carbon: 9.34 MB/min (~0.16 MB/s) jbd2 (fs journal): 8.44 MB/min (~0.14 MB/s) systemd-journald: 4.37 MB/min (~0.07 MB/s) containerd: 2.02 MB/min (~0.03 MB/s) dockerd: 1.13 MB/min (~0.02 MB/s) Total: ~97 MB/min (~1.6 MB/s average) Note: the average of ~1.6 MB/s is consistent with the graph baseline of ~2.5 MB/s when accounting for peaks and the fact that iotop measures a 1-minute window. 3. InnoDB write activity since last MySQL restart (all 3 servers) Server 1 (uptime 59 min) Server 2 (uptime ~40h) Server 3 (uptime ~40h) Data written 2.13 GB 55.3 GB 63.5 GB Effective write rate ~0.58 MB/s ~0.38 MB/s ~0.43 MB/s Rows inserted/s 6.5 8.8 8.6 Rows updated/s 7.0 4.5 4.0 Log writes/s 28.7 23.6 18.0 All three servers show a consistent insert rate of ~6-9 rows/second in the Docker MySQL, matching exactly 1 new Matomo session every 10 seconds (= health check interval). Conclusion The Docker MySQL (~0.4-0.8 MB/s) is the largest single contributor, driven primarily by Matomo session inserts. The total observed disk I/O of 2-4 MB/s is the sum of multiple processes, with the constant Matomo session accumulation as the most significant and most easily fixable component.

Thanks for the clarification. You are right that the tasks table itself is not the primary cause. Here is the buffer pool analysis from the host MySQL: BUFFER POOL AND MEMORY Buffer pool size: 8192 pages Free buffers: 1030 Database pages: 7123 Modified db pages: 0 Pages written: 1,918,869 Write rate: 9.76 writes/s young-making rate: 63 / 1000 And the box database table sizes: eventlog 79.58 MB 16,275 rows tasks 29.55 MB 17,719 rows backups 19.47 MB 762 rows The host MySQL writes/s (9.76) are indeed modest. The main disk I/O culprit is the Docker MySQL (messageb user) which writes significantly more — and that is where the Matomo sessions live. So I agree the tasks table is not directly causing the disk I/O. The real issue remains the Matomo health checker session accumulation as discussed in the main topic.

@nebulon said: Do you have any custom configs on that app? Like maybe increased session lifetime or so? We are no experts on roundcube internals to know what may or may not work here, especially since we cannot reproduce it. So any extra info helps. my apologies, I was on the road and answered too quickly after checking via filemanager on my phone ... the wrong Roundcube instance ... On this server I have 5 Roundcube apps (because aliases are not in the app package available) and 3 of them have this issue and indeed all three they do have in common in the custom config: $config['session_lifetime'] = 600; Once upon a time in 2022 it was suggested/advised here https://forum.cloudron.io/post/46033 and so I used that ever since. I deleted the line, restarted the apps, waited a few minutes and the session increase is now 'normal'. I also restarted MySQL server and it used 2.6 GB of the assigned 8GB and after restarting it starts at 416MB. This part 3 of the discovered possible issues for high disk I/O is solved. Let's continue with the possible Matomo issue in https://forum.cloudron.io/topic/14639/cloudron-v9-huge-disk-i-o-is-this-normal-safe-needed/

@archos interesting it knows how to access the old doc to make a new copy. Nice find!

@James @brutalbirdie @Joseph Much appreciated team.

You already got it, but often proxyAuth is the simplest.

@joseph

Given that you got a 400 status code error, did penpot server logs reveal anything about this?

@girish Great

@dsp76 I think if this happens sporadically it is a bug in the remote service provider. Have you asked their support already if this issue is known?

I cannot really reproduce this on 9.1, but there was no specific fix implemented recently.