RPI3 running out of memory

[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.

[ember1205]

@bhepler

I think you’re missing the point.

If you have two modules, X and Y, and you disable one and the problem persists? What’s your diagnosis?

How long do you allow the system to run with one module disabled and no fault before you are able to actually, definitively, able to declare that the problem is the sole result of that module?

Even if you can declare the issue gone, how do you know that it wasn’t an issue related to the combination of modules?

Without explicit logging and debug information to actually see a stack trace of the fault, there is no way to declare “anything” by disabling a module.

[lavolp3]

@ember1205 taking a step back from modules, are you sure MM is the problem?

Have you had it run “idle” so with desktop open only for some time?
Is there a way to monitor ram usage and to monitor which app eventually fills the memory?

Which version of electron do you use?
Which Raspberry Pi? I assume 3b?
Which Raspbian version?

uname -a

node version?

node -v

npm version?

npm -v

Have you tried running in serveronly and keeping it open on another laptop? If that works, I would assume the modules themselves are not the problem…

[sdetweil]

@lavolp3 he’s been fighting this for some time now… we’ve both experienced the same problems…
but mine not recently…

I run the same modules and also another one of mine that does additional images, and my systems run on and on… without problems… Pi4 (buster) , jetson Nano(ubuntu) , Pi 3(stretch) , odroid (ubuntu).

we have increased swap space
turned on and off disable cache in electron
he has tried current 3.1.13, and 6.0.12 (as I recall)

I am running electron 3.1.13 on all

[johntech]

@Vizulize

What size SD card do you have?

Have you ran

sudo raspi-config

selected the expand memory the second screen?

I had that problem when first starting MM. No problems any more with 32 GB of space.

[Vizulize]

@johntech Huh? This is referring to RAM memory, not hard drive space. I was writing to explain how you can extend the swap by using filesystem space to prevent the system crashing from running out of RAM.

Sorry if there was any confusion - I actually manage a Raspberry Pi operating system, so am very familiar with the tools and techniques available.

[johntech]

@Vizulize Sorry noob here just learning!

[Vizulize]

@johntech no worries! “Memory” is often confused in this context. Hope you learned something 😁

[reweleini]

This post is deleted!