Cloudron Forum

Hello @techy This might not be the case for you, just a cautious tale that high CPU usage / load can also be caused by something completely different. Recently I had a VPS system that had a ridiculous high load without doing anything special. And it was suddenly, from one day to another. Thanks to excessive monitoring I could see that the IOWAIT was suddenly extremely high. It turned out, the underlaying RAID from the provider had multiple failing disks and that is why my VM was having such trouble with the Disk.

Hello @digago-gh @digago-gh said in Superuser Auth API Response Became Extremely Slow: Superuser logins now take noticeably longer compared to earlier versions. If you can reliably compare across version. This might be an upstream issue. @digago-gh said in Superuser Auth API Response Became Extremely Slow: Was there a recent structural change in how superuser sessions are created or verified? All changes for app updates done by Cloudron is documented in either the changelog when updating the app or here in the forum. https://forum.cloudron.io/topic/11735/pocketbase-package-updates Even further the code commits for versions can be reviews here: https://git.cloudron.io/packages/pocketbase-app/-/commits/main Bases on that, I can not reliably tell you yes or no. @digago-gh said in Superuser Auth API Response Became Extremely Slow: Is this expected behavior (e.g., for added security/logging), or is it an unintended performance regression? Needs to be evaluated, either upstream or here. Can you provide some logs of the app with "old version" fast and "new version" slow? @digago-gh said in Superuser Auth API Response Became Extremely Slow: Are there any known workarounds or config settings we can tweak to mitigate the delay? I don't think so but, you can search in the official documentation for something related to your issue. => https://pocketbase.io/docs/

Hello @i.fritz @i.fritz said in Nextcloud Talk CHAT very slow: Entered text is shown 20s-30s later. Could you go into a little more detail here? A: You write some text, send it and have to wait 20s -> 30s until the message appears in your local chat B: You write some text, send it, the receiver gets the message 20s -> 30s seconds late I could not reliably reproduce this. Also, I don't have access to >100 User Nextcloud for testing more close yto your setup. Maybe a small video of the problem could help to understand it. If you make one, please have the browser console open so the console logs are viewable.

@nebulon Yes, I had a look of Cpu load and it was by msql, but now seems to be ok

@jdaviescoates said in Cloudron services are slow: @nebulon @KhalilZammeli said in Cloudron services are slow: update of the screenshot for our wordpress service, very high CPU usage, how can we investigate these ? Given the above and the fact WordPress uses mysql (and is very often attacked as it's so widely used, and malicious plugins are also quite common) that seem to me to be the obvious first app to investigate. Absolutely! Most of the time a WP plugin is the culprit. A WP plugin that's been acquired through a 'friend' which is not the original developer. Extremely, dangerous these are compromised in 99% of the times.

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

@robi @d19dotca identified the issue at https://forum.cloudron.io/topic/10434/email-event-log-loading-very-slowly-seems-tied-to-overall-email-domain-list-health-checks/9 . When we switch views, pending http requests of the old view are not canceled .

Right, the historic graphs data is not retained since it's all very server specific. And most likely won't even map properly to the new server. I can put a note in the docs.

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

That's what I call an answer Thank you very much. Very helpful and my question is answered.

@Stardenver said in Identify whats causing lags: So the graph showing 200% is 2 cores on 100% each (or something equal like 4 cores on 50% each)? The latter is more probable. If you really want to know, run 'htop' from the command line.

@vladimir-d DBeaver Database Dashboard? Or you thinking longer timeframe and more detail?

@dreamcatch22 with AWS, I have usually found that it's either a) the cpu credits are kicking in. are you aware of https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html ? AFAIK, even lightsail has the same limitation (but not 100% sure). b) some machine have a lot of memory but perform very poorly . For example, see the notes in EC2 R5 xlarge (which has 32GB RAM!) but works very poorly with docker - https://forum.cloudron.io/post/17488 Not sure, if either of those apply to you. What instance are you using ?

@lonk said in Apache, OLS and Nginx-Custom Benchmarks: redis is already apart of Cloudron Yes & no, Yes is part of the cloudron addon, but it can be integrated in different way. You can use it for dynamic cache (as cloudron use in there apps), behind the php, db lvl. You can use it as a Full Page Cache (similar to what Cache Enebler do but in RAM and not in local disc). php lvl You can use it for partial page caching, in this case is at webserver/proxy lvl. Redis is just a "database" in RAM, you can use it to store what you want, Redis is not a cache, but you can use it as it was one.

@d19dotca Can't tell as I haven't run out of RAM yet.. huge machines.. ;-/ Best to try on smaller ones.

@fbartels said in MySQL tuning with my.cnf settings optimisation: @lonk said in MySQL tuning with my.cnf settings optimisation: when do we run / apply it? Mysql tuning is best applied after a few days of database usage. Applications usually have different load patterns. Gotcha, thanks for the tip! ️

The CPU share setting is a percentage relative to each app. So, you should make tinytinyrss slider to be 20%. That way, it will take less CPU compared to other apps (which are set to default to 80%). There's a more detailed explanation here - https://www.batey.info/cgroup-cpu-shares-for-docker.html . When 50%, we set the CPU shares value to be 50% of 1024, when 20%, we set the CPU shares to 20% of 1024 and so on.