Anyone else have this problem or know a solution?
My instance has almost no usage, and I’m using the version recommended in the docker instructions.
Problem:
I gave tokio-console a buffer way too big
Fix:
Update pict-rs to at least
v0.3.0-rc.7, which doesn’t enable console by defaultfor context: I am the pict-rs developer
seems to have fixed it, thanks!
awesome, ty. I’ll let you know how it works =]
Yep I noticed that as well, though I don’t detect it right away since I have lots of available memory on my server. I just restart the pictrs service but indeed a more long term solution would be great. I haven’t created an issue since I don’t use a supported deployment method so I was not sure which was the culprit.
how long does it take for pict-rs to use up this memory?
Too bad I did not check for how long the service was running before restarting, I’ll check next time.
I think I had to do this twice so I guess at least several weeks but I was up to 7GB then only 65MB after restart. And I had to do it on both my test and production server.
what I noticed personally is that my pict-rs server had eaten 1,200MB of RAM, which is the limit I allowed that container. it was still working and it automatically restarted on crash so I didn’t notice it oops
after I fixed the problem, my pict-rs server has been running at about 29MB for the last 12 hours. Significant improvement I’d say
Could it help to move Pictrs to a 3rd-party host? (like AWS or similar)
Is anyone running Pictrs on a 3rd-party host? Does it help?
No, when a service eats too much resources, the solution is to find the bugs/leaks and crush them, not to move to bigger infra. Unless of course what you’re doing has some inherent complexity (eg. live 3D rendering).
That is true.
I’m asking if anyone uses an external host for pictrs - to ease load on the server and free up space?
