Read the statement by Michael Teeuw here.
MM is eating all memory and crash!
-
@juergschwarz said in MM is eating all memory and crash!:
Yes i read it. All of this suggestions i already checked out.
Very good. You had the benefit of other people’s time and hard work. Imagine if you had to think of all those tests for yourself.
If you tell me to test standard installation whitout any additional modules - what the hell do all this people building such modules when i only can use standard modules?
Logically, that would be a starting point, to see if the issue arises before the addition of other modules. If the problem arises afterward, then you can attribute the cause to something that you added. If not, then the cause lies in the OS version, the MM version, or with the Pi itself, or the way it was prepared.
Dont misunderstand me. But i manage two root servers with kvm - lvm and aprox. 30 official domains and nearly 200 email accounts. Longest uptime was 772 days.
I could not be less impressed.
Nobody can tell me a application with black background and some “only text foreground apps” should not be able to run more than 2 hours or not?
Nobody is telling you anything. I thought you wanted help so I started where anyone would start, at the beginning. Instead of some small measure of gratitude, you started spewing your impotent anger at me.
I only have one more question for you.
With the impressive resume you have, why didn’t you just figure it out and fix it yourself? :-)
-
Nobody can tell me a application with black background and some “only text foreground apps” should not be able to run more than 2 hours or not?
You are in the minority … I have 3 running, without issues… 1 of them has been running a solid year without any issues what-so-ever.
With that being said being rude to someone trying to help you is not really a way to get help…
-
$ uptime 21:34:37 up 37 days, 58 min, 3 users, load average: 0.08, 0.13, 0.09$ cat /etc/issue Raspbian GNU/Linux 8 \n \l$ uname -a Linux raspberrypi 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l GNU/Linux$ free -m total used free shared buffers cached Mem: 923 878 44 149 64 487 -/+ buffers/cache: 326 596 Swap: 99 99 0$ df -k Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 5863924 4248140 1294864 77% / devtmpfs 468148 0 468148 0% /dev tmpfs 472756 147656 325100 32% /dev/shm tmpfs 472756 12364 460392 3% /run tmpfs 5120 4 5116 1% /run/lock tmpfs 472756 0 472756 0% /sys/fs/cgroup /dev/mmcblk0p6 66528 21418 45110 33% /boot tmpfs 94552 0 94552 0% /run/user/1000 tmpfs 94552 0 94552 0% /run/user/1001 /dev/mmcblk0p5 30701 463 27945 2% /media/elowe/SETTINGS$ npm ls | grep -i magicmirror magicmirror@2.1.3$ npm ls | grep electron ├─┬ electron@1.7.5 │ ├─┬ electron-download@3.3.0 │ ├─┬ electron-chromedriver@1.6.0 │ │ ├── electron-download@3.3.0 deduped │ │ │ └── electron-to-chromium@1.3.24Modules:
- clock
- currentweather
- weatherforecast
- MMM-MyScoreboard
- MMM-EnphaseEnvoy
- MMM-CalenderExt
- MMM-AirNow
- MMM-AutelisPentair
- MMM-Globe
- MMM-Remote-Control
- MMM-PIR-Sensor
-
Oh, and MM specifically is up for 20days:
pm2 show mm Describing process with id 0 - name mm │ status │ online │ │ name │ mm │ │ restarts │ 6 │ │ uptime │ 20D -
Uninstall PiHole. If you search this forum for PiHole you will find two other threads with similar memory issues, both related to PiHole. After removing it the issue was gone.
-
@all Ok sorry. Now my realy newest installation on Raspi 3 stretch wiht realy original config.js and no additional modules or other changes:
pi@raspi32:~/MagicMirror $ npm ls | grep electron ├─┬ electron@1.7.9 │ ├─┬ electron-download@3.3.0 │ ├─┬ electron-chromedriver@1.6.0 │ │ ├── electron-download@3.3.0 deduped │ │ │ └── electron-to-chromium@1.3.27PageSize:4KB RAM-Memory Swap-space High-Memory Low-Memory │ │ Total in MB 927.3 100.0 - not in use - not in use │ │ Free in MB 424.9 100.0 │ │ Free Percent 45.8% 100.0% │ │ Linux Kernel Internal Memory (MB) │ │ Cached= 254.6 Active= 259.0 │ │ Buffers= 36.2 Swapcached= 0.0 Inactive = 203.0 │ │ Dirty = 0.1 Writeback = 0.0 Mapped = 147.6 │ │ Slab = 25.3 Commit_AS = 1412.1 PageTables= 4.6 │ │ Top Processes Procs=161-mode=3-1=Base 3=Perf 4=Size 5=I/O[RootOnly] u=Args────────────────────────────────│ │ PID %CPU Size Res Res Res Res Shared Faults Command │ │ Used KB Set Text Data Lib KB Min Maj │ │ 922 354.8 297m 98m52660 131m 0 56268 249 0 electron │ │ 928 5.4 295m69924 52660 143m 0 48540 111 0 electron │ │ 865 4.4 454m85120 52660 297m 0 58716 0 0 electron │ │ 896 2.0 6156 3828 156 3572 0 1572 0 0 nmon │ │ 521 1.5 134m43540 1896 62820 0 21740 0 0 XorgNow i will check it out with jessie :-(
-
This post is deleted! -
@yawns Thanks. But last “overnight” test with only original config.js also crashed with stretch. So now a new test with jessie looks much better. Including pi-hole. It runs since 22 mins and 47% free ram. :-)
-
@juergschwarz
Thanks for your feedback, good to know. So one more reason against Stretch -
