Uptime-Kuma does not respond

athamour1 commented 4 months ago

⚠️ Please verify that this question has NOT been raised before.

[X] I checked and didn't find similar issue

🛡️ Security Policy

[X] 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

athamour1 commented 4 months ago

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 ?

CommanderStorm commented 4 months ago

Please see https://github.com/louislam/uptime-kuma/issues/3276 which this is a duplicate of or https://github.com/louislam/uptime-kuma/issues/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)

CommanderStorm commented 4 months ago

(closing as a duplicate)

louislam / uptime-kuma