Uptime-Kuma does not respond
athamour1 opened this issue · comments
⚠️ Please verify that this question has NOT been raised before.
- I checked and didn't find similar issue
🛡️ Security Policy
- I agree to have read this project Security Policy
📝 Describe your problem
I have an instance of uptime-kuma added something like 100 monitors, the UI doesn't respond anymore, this is due to the volume of the monitors ?
Or this is normal ?
Also, another one is that the application is running and can send notifications when a monitor is down, the UI doesn't respond only.
📝 Error Message(s) or Log
No response
🐻 Uptime-Kuma Version
1.23.13
💻 Operating System and Arch
Helm Chart from Docker compose
🌐 Browser
I tried it from the latest firefox and from the latest chrome
🖥️ Deployment Environment
- Runtime: ContainerD (K3S)
- Database: SQLite
- Filesystem used to store the database on: Kubernetes localfs (BTRFS)
- number of monitors: 105
After a quick restart of the service, the monitors are back, but this is not very stable, is there any way to improve the stability of the Frontend ?
Please see #3276 which this is a duplicate of or #4500 which tracks the resolution with this tip:
- better performance through external MariaDB, storing heartbeats in an aggregated form, full server-side pagination for important events
=> even though benchmarking is still out, we are confident that this pushes the prominent "limits" (highly hardware-dependent, not a limit imposed by us) ~500 Monitor or ~1.5GB DB-size
A large part of the focus in this release is on performance. We don't know if we are optimising for the right thing, see #4456 for a discussion on this topic.
Tip
If you are affected by the performance limits mentoned in the v2-tracking issue in v1, you need to reduce the amount of data you store.
The core problem is that Uptime Kuma in v1 has to do a table scan of the entire heartbeat table for some operations.
The solution boils down to having a lower amount of data => making Uptime Kuma less worried about reading those gigabytes of data.:
- reduce the retention and execute a manual cleanup under
/settings/monitor-history - Increase the time between checks
- pause or reduce the amount of monitors
- delete the specific history of less essential monitors (to "lower" their retention below the configured maximum)
(closing as a duplicate)