RPI3 running out of memory

[gschmall]

I have a rpi3 running the latest MM2 and after about a day or so it runs out of memory and vaporlocks. Has anyone else had this problem? What was your solution to keep it up?

[lavolp3]

@gschmall
Most probably a 3rd party module is responsible.
I would try disabling the most recent one (or more than one) and try to find out which is responsible.
There have been more cases of this in the past.
You should find them here in the forum.

[ember1205]

I have a few standard modules installed and ONE 3rd party module. Mine locks up -all the time- and I can not figure out why. The 3rd party module is one that the author runs in his own environment with a setup just like mine and never has an issue.

I’ve been chasing the issue with zero progress for weeks and weeks.

[bhepler]

I have a schedule set up that reboots my pi on a regular basis. You could easily do the same and bounce it at 2 AM or whatever.

[ember1205]

@bhepler

Once-a-day reboots don’t generally help much with random lock-ups. I wrote a script that checks the error log for “out of memory”. If the string is found, it shuts down the mirror, flushes the logs, starts the mirror back up, and sends me a push notification so I know of the error. I run the script via cron every five minutes and get anywhere from 2 to 20 events per day with no rhyme or reason to it.

Also, my mirror shuts down each day at 11PM and boots up at 7AM. So, it’s only running for 16 out of 24 hours every day.

[bhepler]

@ember1205 Hrm. In that case, I would try disabling a module for 24 hours and see if your notifications change frequency. Narrow the problem down. If none of the modules are the culprit, let us know and we’ll try to come up with other ideas.

[ember1205]

@bhepler

That would seem a reasonable approach, but all you can definitively determine is that a specific module is not the sole culprit if the error persists.

• Disable module, error doesn’t return in 24 hours. This does not definitively prove anything as it might be a still-enabled module that causes the fault but only because some other module or setting is creating the condition where the fault occurs.

• Disable module, error returns. This does not definitively prove anything except that the disabled module is not the sole reason for the fault. It could be creating “some” of the faults or be related to the fault occurring.

In other words, this is essentially the situation of it being impossible to prove a negative.

I use ImagesPhotos and have issues with my RPi3 faulting. I also use the default CurrentWeather, WeatherForecast, and GoogleCalendar modules.

[A Former User]

Maybe there be a chance of your RAM(or related system whatever) might be defective or inferior, unfortunately.

[bhepler]

@ember1205 - It’s still useful information, even if it is the combination of two modules. Remove one module and the problem dissipates. In the end, it doesn’t really matter if it is one module or a combination of two modules that causes the memory error. It gives you a path forward without errors.

[Vizulize]

Worth considering increasing your swap file size while you try to determine the cause. That will start using file system space as memory.

Change CONF_SWAPSIZE=100 to #CONF_SWAPSIZE=100in /etc/dphys-swapfile and reboot.

Then you can check on the swap size used, and see if it’s a memory leak that just keeps on growing, or something else.