overload of Raspi System blocked
Willifred69 opened this issue · 7 comments
Platform
Raspi 3B
Node.js Version
16.14.0
MagicMirror Version
2.18.0
Module Version
Description
Hi,
I used the module for some days. But recordniced, that after few time the system gets blocked. or freezed. After stopping the Rain-Map It works fine again.
Looks like there is a kind increaced use of CPU use over time.
Well sorry, can tell more about.
Expected behavior
No response
Current behavior
currently not using the modul.
Possible solution
No response
Steps to reproduce
MM is running.
Modle is working fine
It take ~12h till system freez
There is running also deconz and homebridge on the same raspi.
Log
No response
config.js
{
module: "MMM-RAIN-MAP",
position: "middle_center",
config: {
animationSpeedMs: 500,
colorScheme: 2,
colorizeTime: true,
defaultZoomLevel: 8,
displayTime: true,
displayTimeline: true,
displayClockSymbol: true,
displayOnlyOnRain: false,
extraDelayLastFrameMs: 1000,
extraDelayCurrentFrameMs: 3000,
markers: [
{ lat: 50.xxx, lng: 8.xxxx7, color: "red" },
// { lat: 50.xxx, lng: 8.xxxx9, color: "green" },
],
mapPositions: [
{ lat: 50.xxxx9, lng: 8.xxxx7, zoom: 12, loops: 2 },
{ lat: 50.xxxx9, lng: 8.xxxx7, zoom: 9, loops: 1 },
{ lat: 50.xxxx9, lng: 8.xxxx7, zoom: 6, loops: 1 },
{ lat: 50.xxxxx9, lng: 8.xxxx7, zoom: 5, loops: 1 },
// { lat: 50.xxxxx9, lng: 8.xxxx7, zoom: 2, loops: 1 },
],
mapUrl: "https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png",
mapHeight: "400px", // must be a pixel value (no percent)
mapWidth: "400px", // must be a pixel value (no percent)
maxHistoryFrames: -1,
maxForecastFrames: -1,
substitudeModules: [],
updateIntervalInSeconds: 300,
}
},Additional info
No response
Hi @Willifred69,
thank you for your feedback.
I can confirm that the module requires very high memory and GPU requirements for rendering.
Frankly speaking, I don't know how to reduce them further. The only way I see is to reduce the number of frames (maxHistoryFrames, maxForecastFrames) and reduce the maps dimensions (mapHeight, mapWidth).
What I can say for sure is that there is no memory ramp-up over the runtime (even after several months). It is more likely in your case that the resources of your Raspberry are close to the limit using MMM-RAIN-MAP and the ramp up of another application will finally push the system to the limit.
You are not the only user who has reported problems when using with the Raspi 3. Obviously it is too weak for this module.
It runs on a Raspi 4 without problems for me and many other users.
I will probably add a note in the Readme that this module is only recommended with a Raspi 4.
I'm sorry that I don't have a more satisfying answer for you, but besides my ideas above, the only solution that I see is a hardware upgrade.
Of course I am open for all good ideas and suggestions to further reduce the resource consumption of this module.
Hi, @jalibu ,
well maybe you are correct Raspi 3B with all other things running there is to weak. Since I stop this MM modul for now about 5 days Raspi is running without any trouble.
Maybe I will upgrade the raspi to an Model 4 some time.
Thy anyway for your answer.
Hello,
some troubles since 2 days with a lot a raining in my map :) but i can't see correctly the map behind..i m working with rasp 4 and no pb since 1 year with this module..
@chassain I can see this on my Mirror today for the first time, too. But I can not reproduce it on my local dev machine.... that's weird... I will try to debug this once I find the time.
but i can't see correctly the map behind..
Same thing started happening for me sometime last week. I can't remember the exact day. I use three zooms (10, 7, 5) and randomly one will show all or some of the map, but the other two will not show anything. Radar coverage doesn't seem to matter, nor does rebooting.
To resolve the issue of my 3b+ freezing after 40-46 hours, I set it to reboot once a night (2am). I don't think the freezing issue was related to this module as I tested with the default MM modules and it still happened. I even got a Flirc case thinking temp was an issue (was 130f+ now never over 115f).
This error only occurs with Electron on my side. The Openstreetmap requests fail with HTTP Status 418 :-D
https://help.openstreetmap.org/questions/83828/tile-layer-418-error
Obviously, Openstreetmap.org tileservers block requests when the user agent contains Electron.
A quickfix is to use another tileserver. One that still works is the German fork:
https://a.tile.openstreetmap.de/${z}/${x}/${y}.png
add that to the module config:
{
mapUrl: "https://a.tile.openstreetmap.de/${z}/${x}/${y}.png"
}