You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My Uptime Kuma DB is 10.73 GB. While I understand this might create slowness, I don't think this is where the issue comes from.
That's where my question comes from: Does the dashboard load the entire history of heartbeat?
With this comes another one. I've often found in the repo issues being mentionned that ~~350 to "500+" (see issue #4094) monitors is where issues arise.
In my case, I have 114 monitors, all of type HTTP so I'm nowhere near the 500+ number. Out of the 114 monitors, about 50 of them are pinging the index page of websites. Could the size of the payload returned by every ping affect performance?
My CPU and RAM usage always are below 40% usage.
π Reproduction steps
Install Uptime Kuma
Use it for a while with a bunch of monitors
Slowness happens after a while when loading the dashboard page
π Expected behavior
My suggestion (if possible at all) is to load the heartbeats of a monitor only when the user clicks on it.
Stop showing the hearbeats on the sidebar, while still showing if the monitor is alive/dead.
Heartbeats would only be shown when clicking on the specific monitor
π Actual Behavior
Often times very slow loading times of ~~ 30 seconds to view the dashboard. While waiting for the page to load, the dashboard appears as if there are no monitors.
π» Uptime-Kuma Version
1.23.11
π» Operating System and Arch
Ubuntu 22.04
π Browser
124.0.6367.60
π₯οΈ Deployment Environment
Runtime: Cloudron/Docker
Database: SQLite
Filesystem used to store the database on: on a VPS's SSD
number of monitors: 114
π Relevant log output
No response
The text was updated successfully, but these errors were encountered:
Your storage might be much better than what normal people are running
=> this is why you can push this much farther than what our "documented" performance limits are.
=> I would recommend you to reduce your retention.
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.
@CommanderStorm
I've splitted my heartbeat table (then 78 million rows) to smaller multiple INSERT sql dumps files in order to reduce the database size. It helped tremendously for the performance issues.
In my case, my insurance policy requires me to preserve pings for 7 years, thus why I cannot reduce the retention in uptime kuma.
π I have found these related issues/pull requests
π‘οΈ Security Policy
Description
My Uptime Kuma DB is 10.73 GB. While I understand this might create slowness, I don't think this is where the issue comes from.
That's where my question comes from: Does the dashboard load the entire history of heartbeat?
With this comes another one. I've often found in the repo issues being mentionned that ~~350 to "500+" (see issue #4094) monitors is where issues arise.
In my case, I have 114 monitors, all of type HTTP so I'm nowhere near the 500+ number. Out of the 114 monitors, about 50 of them are pinging the index page of websites. Could the size of the payload returned by every ping affect performance?
My CPU and RAM usage always are below 40% usage.
π Reproduction steps
π Expected behavior
My suggestion (if possible at all) is to load the heartbeats of a monitor only when the user clicks on it.
π Actual Behavior
Often times very slow loading times of ~~ 30 seconds to view the dashboard. While waiting for the page to load, the dashboard appears as if there are no monitors.
π» Uptime-Kuma Version
1.23.11
π» Operating System and Arch
Ubuntu 22.04
π Browser
124.0.6367.60
π₯οΈ Deployment Environment
π Relevant log output
No response
The text was updated successfully, but these errors were encountered: