Entrypoint config over-allocates memory about docker-unifi-rpi

[0r0misElda]

I'll have some time, tonight, to tinker with this again. Been away, fishing, conferences etc. I'll report back after testing it out a few days. Usually doesn't take it more than 2-3 days to go OOM, if I let it sit.

[ryansch]

Agreed. I'll give this a whirl.

[0r0misElda]

Does the Garbage Collection for UniFi work sufficiently well enough to handle the 500M of Memory?

[ryansch]

That's exactly what I was wondering. I'm not sure if we've been hitting swap or not.

[0r0misElda]

I also neglected to mention my current workaround for this issue... apologies.

Here's my docker run command:
sudo docker run -d --net='host' --restart=always -e TZ='America/Chicago' -e JAVA_OPTIONS='-Xmx500m' -v ~/unifi:/var/lib/unifi --name unifi ryansch/unifi-rpi:5.10.20-arm64v8

My current hardware, OS, and kernel config doesn't allow me to specify container memory --memory="500m" or swap --memory-swap="2g" in the docker run command. So, this was the next best way to do it without a direct edit of the Dockerfile.

[halindrome]

FWIW having the high heap limit doesn't seem to cause a problem on my various RPi.

[0r0misElda]

FWIW having the high heap limit doesn't seem to cause a problem on my various RPi.

@halindrome, What OS and version are you running?

[ryansch]

I also haven't had a problem which is the biggest reason I've never made this change.

[0r0misElda]

UniFi Controller is still going OOM, even with the new settings specified. I'm having trouble understanding why others are not experiencing similar issues. So, it begs the question: What am I doing differently than everyone else not experiencing this issue? Is it OS? Must I abandon Ubuntu? Appreciate any feedback.

[halindrome]

I am actually hitting high memory on the stock compose configuration now (finally). So yes, this 1024 limit is a problem for me too. It just took a while for the memory utilization to get up there.

[ryansch]

Ok I'll take a crack at this.

[ryansch]

@0r0misElda @halindrome Please have a look at #43

You can pull ryansch/unifi-rpi:5.10.24.test to test these changes.

[ryansch]

I'm finding that I can't start the container with only 512M of heap space for the JVM.

[ryansch]

Oops: I built tini for amd64 for all platforms.

[ryansch]

Fixed.

[ryansch]

I think it's working with 512MB heap space. Please test and report back.

[0r0misElda]

Been running for 70 hours now, without going OOM and crashing my Pi. I'll continue to monitor the situation and report back. I'd be curious to know if anyone else has tried this build.

EDIT: Forgot to include a screenshot for inquiring minds.

[ryansch]

@0r0misElda That's excellent! Did you set JAVA_OPTS or did you leave it at the default?

[0r0misElda]

@ryansch So, I spoke too soon. Sometime between my update yesterday, and just now, the Pi went OOM and I can't ssh into it, nor is it showing as available from the cloud.

I didn't make any modifications for the start of the container. So, to be clear, no -e JAVA_OPTIONS='-Xmx500m' was used.

So, this seems to play like previous attempts. Anytime after the 48-72 hour mark, it can go OOM.

[ryansch]

I've merged #43 to make it easier to find good values for Xmx.

[ryansch]

@0r0misElda Do you have anything else running on that box?

[0r0misElda]

@ryansch No, nothing else running on the box besides Docker and the UC container. I have the parts for my RPi 4 w/ 4GB RAM here now. I'm hoping to have it put together and in service soon. I think I'm just going to abandon the RPi3 for a UC. I appreciate the effort put forth trying to get past this issue.

[ryansch]

We've been running with the 512MB default for about a year. I'm going to go ahead and close this.

[halindrome]

FWIW m,y approach was to restart the docker container once a day. That solved it on smaller memory machines. I am using a 4GB pi for most installations now, so it doesn't run into this problem.

…

On Fri, Jul 17, 2020 at 4:17 PM Ryan Schlesinger ***@***.***> wrote: We've been running with the 512MB default for about a year. I'm going to go ahead and close this. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#41 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD7D4HHYH4J6262EZ6VJNLR4C5W7ANCNFSM4HCBIXHA> .

-- Shane McCarron [email protected]