Closed hawkeye-bot closed 1 year ago
What if you just create a couple requests and then you wait a few seconds and then take a look if there is any garbage?
I dug into this a bit more, and I suspect it's actually the garbage collection that is not reacting as I expect. I ran it for a longer period, and the memory does slowly creep up, but not as fast my bug report suggests. I'm ok if you close it, I can't say for certain it's something wrong in either unicorn or urllib3 actually :/
I understand you very well, i had also my problems with garbage collection in the past :D
Version of this library.
unicorn_fy: 0.12.2 unicorn_binance_local_depth_cache: 0.7.3 unicorn_binance_rest_api: 1.5.0 unicorn_binance_trailing_stop_loss: not found unicorn_binance_websocket_api: 1.41.0
Solution to Issue cannot be found in the documentation or other Issues and also occurs in the latest version of this library.
Hardware?
Local server/workstation
Operating System?
macOS
Python version?
Python3.10
Installed packages
Logging output
Used endpoint?
concerns all
Issue
I've been having issues with the memory usage in my application, and I've been trying to hunt this down. After quite some searching I've been able to pin it to REST-calls taking place (not sure if it's actually a problem of the underlying requests library). I've constructed a very simple example that shows the memory building up. I can live with the fact that the garbage collector maybe does it's work lazy and it takes some time for the memory usage to stabilise, but adding 7MB in a minute or two with doing nothing but a dumb request and not even storing the result myself is a real problem I think.
Here is the simple piece of code that will show a (small, but continuous) buildup of memory over time:
`import logging import os
import psutil import time from unicorn_binance_rest_api import BinanceRestApiManager
if name == 'main': rest_manager = BinanceRestApiManager()
`
I have to admit I'm not a deeply experienced python developer, so perhaps I'm overlooking something very simple, but it's not the memory usage pattern I'd expect from this sample code.