starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Interface much too slow (even unreachable) #576

New issue

Closed

opened 2026-02-28 01:51:02 -05:00 by deekerman · 8 comments

deekerman commented

2026-02-28 01:51:02 -05:00

Owner

Originally created by @tbringuier on GitHub (Nov 21, 2021).

Hi,
I've sync my uptime-kuma to my local computer to get some debugs info, about my other reports for very slow web interface.
Now i cannot access it at all...

First, i remove from the downloaded folder every bak files, here is my left files :

I've set a data retention to 1 day but the db seems really big,

Also i was suprised of tons of error i had in error.logs

Then i started docker-compose up without detached to see logs,
i've 240 tests to do, every 30seconds.

First it checks withoutn any latency,
but then nothing. Huge wait, after i get logon

When i login, the logs seems to stop, idk if the checks continues in the background.
Also, when i refresh 5 times the web interface i get same errors as in my errors logs.

The cpu usage with 4 cores is at 100% every 20seconds.
With or without me to load the web interface.

I've migrated to different hosts, SSD, HDD, 4Ghz etc and nothing changes.

If you need more infos to debug, i can send you.

Originally created by @tbringuier on GitHub (Nov 21, 2021). Hi, I've sync my uptime-kuma to my local computer to get some debugs info, about my other reports for very slow web interface. Now i cannot access it at all... First, i remove from the downloaded folder every bak files, here is my left files : ![image](https://user-images.githubusercontent.com/39345534/142757675-46e7e5cc-fe16-43ec-9bfe-7cd9f360ada4.png) I've set a data retention to 1 day but the db seems really big, ![image](https://user-images.githubusercontent.com/39345534/142757692-9478f54d-8521-4766-a357-fff9284a139c.png) Also i was suprised of tons of error i had in error.logs ![image](https://user-images.githubusercontent.com/39345534/142757712-6401b501-4fb6-42c5-a179-51cb8d5265e3.png) ![image](https://user-images.githubusercontent.com/39345534/142757716-4c9e994a-df89-4198-8d5f-a1ad65d3d42f.png) Then i started docker-compose up without detached to see logs, i've 240 tests to do, every 30seconds. First it checks withoutn any latency, but then nothing. Huge wait, after i get logon ![image](https://user-images.githubusercontent.com/39345534/142757805-506c6b55-fd41-4e40-8a1a-2740ce387f90.png) When i login, the logs seems to stop, idk if the checks continues in the background. Also, when i refresh 5 times the web interface i get same errors as in my errors logs. The cpu usage with 4 cores is at 100% every 20seconds. With or without me to load the web interface. ![image](https://user-images.githubusercontent.com/39345534/142757880-7e80e29f-7667-4787-9dec-3ee1544c6f0b.png) ![image](https://user-images.githubusercontent.com/39345534/142757886-e54cb93e-a635-46dd-9752-2bf186a3974f.png) ![image](https://user-images.githubusercontent.com/39345534/142757894-e3ff9107-2da8-4a1d-828d-8091789d618a.png) I've migrated to different hosts, SSD, HDD, 4Ghz etc and nothing changes. If you need more infos to debug, i can send you.

deekerman

2026-02-28 01:51:02 -05:00

closed this issue
added the
Stale
label

deekerman commented

2026-02-28 01:51:08 -05:00

Author

Owner

@tbringuier commented on GitHub (Nov 21, 2021):

Maybe using sqlite for those installations is bad, but i didn't see any options to switch database type

@tbringuier commented on GitHub (Nov 21, 2021): Maybe using sqlite for those installations is bad, but i didn't see any options to switch database type

deekerman commented

2026-02-28 01:51:08 -05:00

Author

Owner

@tbringuier commented on GitHub (Nov 21, 2021):

Also, i cannot clean install because i can't even get the export.json

@tbringuier commented on GitHub (Nov 21, 2021): Also, i cannot clean install because i can't even get the export.json

deekerman commented

2026-02-28 01:51:08 -05:00

Author

Owner

@chakflying commented on GitHub (Nov 21, 2021):

Most people have problem with the database if they run it on network storage, which is not supported by SQLite. Also, if you delete the kuma.db-wal file, according to this it may corrupt the database.

Regarding the large database size, 1.10 introduced the database "VACUUM" button, which is required to actually reclaim disk space from old database files, so this is normal.

@chakflying commented on GitHub (Nov 21, 2021): Most people have problem with the database if they run it on network storage, which is not supported by SQLite. Also, if you delete the `kuma.db-wal` file, according to [this](https://stackoverflow.com/questions/20969996/is-it-safe-to-delete-sqlites-wal-file) it may corrupt the database. Regarding the large database size, `1.10` introduced the database "VACUUM" button, which is required to actually reclaim disk space from old database files, so this is normal.

deekerman commented

2026-02-28 01:51:08 -05:00

Author

Owner

@tbringuier commented on GitHub (Nov 22, 2021):

I'm not running it over network storage, my instance in production hasn't any removed files.
And the vaccum button saved me 6gigabytes over 30

@tbringuier commented on GitHub (Nov 22, 2021): I'm not running it over network storage, my instance in production hasn't any removed files. And the vaccum button saved me 6gigabytes over 30

deekerman commented

2026-02-28 01:51:08 -05:00

Author

Owner

@jananathbanuka commented on GitHub (Jun 13, 2022):

I have the same problem, and I am using AWS ebs volumes and I have data only consuming around 500 MB. And I have around 3.5 GB left but still having the same issue as @MichelBaie

@jananathbanuka commented on GitHub (Jun 13, 2022): I have the same problem, and I am using `AWS` ebs volumes and I have data only consuming around 500 MB. And I have around 3.5 GB left but still having the same issue as @MichelBaie

deekerman commented

2026-02-28 01:51:08 -05:00

Author

Owner

@kcleong commented on GitHub (Aug 12, 2022):

Same problem here, using docker-compose on a Linode VPS. This is the stack trace I am seeing: https://gist.github.com/kcleong/10a25ef3e898a9dd3a22e242f8694a93 when I run docker-compose up.

The strange thing is this error dissapears after stopping the container, and running the up command again. The Uptime Kuma still shows and empty dashboard (0 up / down). In my setup there are around 200 sites which are being monitored.

@kcleong commented on GitHub (Aug 12, 2022): Same problem here, using docker-compose on a Linode VPS. This is the stack trace I am seeing: https://gist.github.com/kcleong/10a25ef3e898a9dd3a22e242f8694a93 when I run `docker-compose up`. The strange thing is this error dissapears after stopping the container, and running the up command again. The Uptime Kuma still shows and empty dashboard (0 up / down). In my setup there are around 200 sites which are being monitored.

deekerman commented

2026-02-28 01:51:08 -05:00

Author

Owner

@github-actions[bot] commented on GitHub (Nov 10, 2022):

We are clearing up our old issues and your ticket has been open for 3 months with no activity. Remove stale label or comment or this will be closed in 2 days.

@github-actions[bot] commented on GitHub (Nov 10, 2022): We are clearing up our old issues and your ticket has been open for 3 months with no activity. Remove stale label or comment or this will be closed in 2 days.

deekerman commented

2026-02-28 01:51:08 -05:00

Author

Owner

@github-actions[bot] commented on GitHub (Nov 12, 2022):

This issue was closed because it has been stalled for 2 days with no activity.

@github-actions[bot] commented on GitHub (Nov 12, 2022): This issue was closed because it has been stalled for 2 days with no activity.

deekerman referenced this issue

2026-02-28 03:03:17 -05:00

Pinned telegram message showing the overall status #2677