Comments (38)
More than 2 days without the OOK
from uptime-kuma-api.
Looks very good. Thank you very much for testing.
Because of the breaking changes (changed return values of the methods get_heartbeats
, get_important_heartbeats
, avg_ping
, uptime
, get_heartbeat
and cert_info
) I have to release a new major version.
I need a few days to check if there are any other useful breaking changes that should be included in this version.
from uptime-kuma-api.
@Y0ngg4n @zimbres
I think I have fixed the issue (bugfix/memory-leak). Some events were added to a list after they were received, without ever limiting the size of the list. I now handle the events in the same way as uptime kuma does (example).
It would be very helpful if you could test this.
But note that I have changed the return values of the methods get_heartbeats
, get_important_heartbeats
, avg_ping
, uptime
, get_heartbeat
and cert_info
.
Uninstall the python module:
pip uninstall -y uptime-kuma-api
And install it again from the bugfix branch:
pip install git+https://github.com/lucasheld/uptime-kuma-api.git@bugfix/memory-leak
from uptime-kuma-api.
Hi, just started.
Lets watch. I let you know.
from uptime-kuma-api.
@zimbres thats way too much.
from uptime-kuma-api.
That would be great!
from uptime-kuma-api.
@lucasheld Give me some time to investigate which monitor is causing this problems.
from uptime-kuma-api.
@zimbres thats a good workaround for now! thank you for that!
from uptime-kuma-api.
The monitors were ping and http as described by @zimbres. But yes, I will test all this, also in combination with notifications and other elements.
from uptime-kuma-api.
@lucasheld wow 🥳 great! Thank you for your work! I will check it the next days if it fixed the issue and will give you a feedback. 😊
from uptime-kuma-api.
Im not able to test now, since my app relies on "active": true and this version is returning "active": 1, my app broken.
Thank you for reporting this. It is not supposed to be like this. I will fix it soon.
from uptime-kuma-api.
So far, running smoothly
from uptime-kuma-api.
It's included in release 1.0.1
from uptime-kuma-api.
from uptime-kuma-api.
Checking mine, 850M in use.
from uptime-kuma-api.
Unfortunately I can not reproduce the problem. I have created a fresh Uptime Kuma 1.20.1 instance and added multiple monitors. Then I modified the monitors multiple times to fill the important heartbeats list. I used the latest uptime-kuma-api version (0.10.0).
docker run -it --rm -p 3001:3001 louislam/uptime-kuma:1.20.1
import threading
import time
from uptime_kuma_api import UptimeKumaApi
api = UptimeKumaApi("http://127.0.0.1:3001")
print("Connected")
api.login("admin", "secret123")
print("Login")
def update():
api.get_important_heartbeats()
def uptime_kuma_polling():
while True:
update()
time.sleep(10)
if __name__ == '__main__':
uptime_kuma_thread = threading.Thread(target=uptime_kuma_polling)
uptime_kuma_thread.start()
Can you please test with a fresh Uptime Kuma instance and provide a list of steps or include those steps in the python script on how to set up Uptime Kuma to reproduce the problem?
from uptime-kuma-api.
Maybe it's related to louislam/uptime-kuma#2820.
I have tested this with Ping monitors. Do you use a MongoDB monitor? Then you can try to repeat your test with Uptime Kuma version 1.20.2.
Edit:
Okay, that doesn't make sense. The memory leak we are talking about exists in uptime-kuma-api and not in uptime Kuma.
from uptime-kuma-api.
@lucasheld so could you reproduce the issue? i was using 0.10.0 too
from uptime-kuma-api.
No, unfortunately not. Here is the current plot after even longer time.
from uptime-kuma-api.
@lucasheld Ok thats weird. Because in every app i used uptime-kuma-api i have this rising memory.
from uptime-kuma-api.
@lucasheld maybe it is a specific type of monitor i am using causing this?
from uptime-kuma-api.
But you always used the same uptime Kuma instance right? Maybe it depends on the configuration. So we need a minimal reproducible example, including the configuration (monitors, notifications, status pages, ...).
from uptime-kuma-api.
@lucasheld yes it was always the same instance. I can create a new one like you with the docker container to find out what is causing this
from uptime-kuma-api.
@lucasheld So after my testing i have found out, that adding a monitor to uptime kuma results in usually taking up 0,1 MiB more in the API application.
Something weird was that it seems like if i pause or resume monitors the RAM usage increases by a constant value of 0,1 - 0,2 MiB? Idk
I had it that sometimes the memory gone up quite a while and then stopped again. I could not say that one specific monitor is causing problems. It seemed sometimes like only having this issue if i enabled ntfy notifications. But maybe it was just a correlation.
TCP Hosts did not increased memory usage at all (only when disabling them again i got 0,1 MIB more)
Generally Memory just always was going up. Even if i deleted monitors.
After i had enabled 23 Monitors with Notifications i had the constant rising again. So i think it is constantly rising, but just so slow that we can not see it and it gets faster the more monitors you add. Currently i have only achieved it to create the rising if i enable ntfy notifications.
I don´t know how exactly you have done the implementation, but maybe there is something piling up?
Some cache? maybe close the socket more often? I really don´t know. I have attached you the memgraph where i was enabling, adding, deleting, pausing monitors all time. i don´t think it will be helpfull to you because you don´t exactly know where i did what when, but you can see the memory is rising even if i delete all monitors.
Edit: It seems like adding monitors to status pages also increases by 0,6 MiB. (depends on how many monitors you add). And it seems like it is causing to make the memory usage in general grow faster.
sorry that i did not found out what monitor is causing this problems, but it is really hard to track what is causing this issues.
from uptime-kuma-api.
I have 28 monitors um UK. Mostly Ping and one or two Http.
From this API I'm calling only get_monitors each minute or so.
Since I'm running on Kubernetes, I set a memory limit for the Pod, so, its killed for OOM from time to time.
from uptime-kuma-api.
@lucasheld did the infornation i provided help you?
from uptime-kuma-api.
Sorry for the late feedback. Based on your information, I tried to reproduce the problem a few days ago by creating over 200 monitors with ansible-uptime-kuma. This has slightly increased the memory consumption, within an expected range, because the information about over 200 monitors is now also in memory. So I ran the system for a day with calling get_monitors every 5 seconds, but the memory consumption never increased. Then I edited and deleted some monitors, but the memory consumption didn't show any noticeable behavior there either.
Currently I don't have time to deal with this in more detail. At the end of the month I will take a closer look and run the system for a longer time.
from uptime-kuma-api.
@lucasheld maybe try different types of monitors too. So tcp and keyword monitors for example.
from uptime-kuma-api.
@lucasheld wow partying_face great! Thank you for your work! I will check it the next days if it fixed the issue and will give you a feedback. blush
Did you test this yet by chance?
from uptime-kuma-api.
@lucasheld wow partying_face great! Thank you for your work! I will check it the next days if it fixed the issue and will give you a feedback. blush
Did you test this yet by chance?
No sorry did not had time. Maybe @zimbres can you test it?
from uptime-kuma-api.
Im not able to test now, since my app relies on "active": true and this version is returning "active": 1, my app broken.
from uptime-kuma-api.
@zimbres The bug is fixed in the branch. It would be great if you could test the changes.
from uptime-kuma-api.
Maybe you can make a branch for that version, and a PR from it, so we can review it, and maybe add other features to it, one by one.
from uptime-kuma-api.
It's included in release 1.0.1
Is there an easy way to tell the current installed version (docker)? I'm experiencing a major memory leak (in 3 weeks 6.6Gb of RAM) and wondering if somehow my docker file with image: medaziz11/uptimekuma_restapi pulled an old version.
from uptime-kuma-api.
@tigunia-martin What you can do is go inside the docker contianer and find the file(s) that were updated and see if those commits are included in the files in your contianer.
docker exec -it container-name sh
Then when you are in navigate to the files and use cat to display the outputs
from uptime-kuma-api.
Thanks @flikites
Looks like I have version 1.2.1. I'll open a new issue.
from uptime-kuma-api.
@tigunia-martin
MedAziz11/Uptime-Kuma-Web-API version 1.2.1 uses uptime-kuma-api version 0.13.0. This version is affected by the memory leak.
from uptime-kuma-api.
@lucasheld I apologize profusely. I was following issues, linked PRs, and discussions and somehow moved from the web-api repo to the api repo without realizing.
Of course, I will bring this back to the correct github issues so that we can hopefully get the web api wrapper updated to use the newer API
Again, sorry, and thank you.
from uptime-kuma-api.
Related Issues (20)
- New type 'group' is not a valid MonitorType HOT 3
- Missing sanitisation of `accepted_statuscodes` HOT 1
- Interval modification does not take effect HOT 2
- Bug: api do not return correct timeout error TimeoutError -> Timeout HOT 1
- Proxy: Rate Limiting / Timeout HOT 9
- need to modify the value of interval and retryInterval to make it lower than 20 HOT 2
- support uptime kuma v1.23.0 HOT 3
- Support for Quick Stats
- Retrieve monitor status inside get_monitors()
- Inconsistant Status calls using get_monitor_status HOT 1
- Missing return element in `api.delete_status_page` HOT 1
- set pathName or parent HOT 1
- Default info event does not fetch version under uptime-kuma with version 1.23.1 HOT 1
- save_status_page() failing because of unexpected keyword. HOT 3
- Bug: `api.add_tag()` takes 1 positional HOT 1
- Timeout on get_monitors()
- get_monitor_status for all monitors HOT 2
- error "list indices must be integers or slices, not str"
- ssl_verify argument not used in get_status_page()
- Is it possible to use a Proxy?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from uptime-kuma-api.