Odroid C4 with Dietpi 8.8.1 memory problem

Creating a bug report/issue

Required Information

  • DietPi version |
G_DIETPI_VERSION_CORE=8
G_DIETPI_VERSION_SUB=8
G_DIETPI_VERSION_RC=1
G_GITBRANCH='master'
G_GITOWNER='MichaIng'
  • Distro version | bullseye
  • Kernel version | Linux Home 4.9.277-arm64 #1 SMP PREEMPT Thu Mar 10 23:51:35 CET 2022 aarch64 GNU/Linux
  • SBC model | Odroid C4/HC4 (aarch64)
  • Power supply used | (12V 5A RAVpower)
  • SD card used | (eMMC 32 GB )

Additional Information (if applicable)

  • Software title | (SmartApplianceEnabler)
  • Was the software title installed freshly or updated/migrated? installed freshly
  • Can this issue be replicated on a fresh installation of DietPi? Yes
    ← If you sent a “dietpi-bugreport”, please paste the ID here → No
  • Bug report ID | echo $G_HW_UUID

Expected behaviour

A stable system running on the available RAM of 3.6G. ioBroker requires about 2-2.5G for most users. SAE needs about 500-600 MB. Accordingly, the memory of the C4 should be sufficient.

Actual behaviour

I use the home automation software ioBroker and the SmartApplianceEnalber (SAE) from Alex Müller (java based) together on a C4 running with DietPi.

Both software show a steadily increasing RAM consumption. Up to the point where the maximum RAM limit of 3.6G is reached. Then DietPi kills the process with the highest consumption. This is SAE in this case. Surely this is a normal DietPi function.

Both forums of the respective software could not help me with the problem. With the SAE the Java version 17 was suspected. I downgraded to the recommended version 11 for the SAE. But it did not bring any improvement. SAE uses a HeapLimit of 256 MB, but probably all the other processes need much more RAM.

What can I do to limit the memory hunger of the two software, or is it perhaps a problem with the kernel, OS, etc.?

Extra details

top - 15:56:01 up  6:47,  1 user,  load average: 1,99, 1,78, 1,69
Tasks: 160 total,   3 running, 157 sleeping,   0 stopped,   0 zombie
%CPU(s):  18,7/4,7    23[||||||||||||||||||||||||                                                                            ]
MiB Spch:   3712,1 total,    896,3 free,   2612,4 used,    203,4 buff/cache
MiB Swap:      0,0 total,      0,0 free,      0,0 used.    926,7 avail Spch

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL
  13744 sae       20   0 4460168 690028  18908 S   4,6  18,2  22:15.40 java
   2366 iobroker  20   0 1093616 267264  35820 R  44,7   7,0 201:35.11 iobroker.js-con
   3138 iobroker  20   0 1044196 192512  36664 S  13,6   5,1  56:51.49 io.javascript.0
   4375 iobroker  20   0  985184 139024  32596 S   3,3   3,7  15:57.76 io.zwave2.0
   2806 iobroker  20   0  994808 129412  36076 S   0,0   3,4   1:33.30 io.admin.0
   4080 iobroker  20   0  680852 115920  31064 R  19,2   3,0  77:02.41 io.sma-em.0
   3853 iobroker  20   0  720480 115084  31068 S   0,0   3,0   4:33.97 io.sonoff.0
   3928 iobroker  20   0  696876 106076  31120 S   1,3   2,8   9:38.42 io.mqtt.0
   4111 iobroker  20   0  948520  97652  31956 S   0,0   2,6   5:50.29 io.web.0
   3676 iobroker  20   0  944368  91804  31732 S   0,0   2,4   4:09.58 io.tahoma.0
   4635 iobroker  20   0  927780  89736  32128 S   1,7   2,4   4:40.70 io.fb-checkpres
   4163 iobroker  20   0  680944  86996  31300 S   2,0   2,3   1:55.58 io.yahka.0
   3989 iobroker  20   0  671984  82636  35904 S   0,3   2,2   0:44.78 io.backitup.0
   4024 iobroker  20   0  674292  81436  31668 S   0,0   2,1   1:34.22 io.deconz.0
   3910 iobroker  20   0  938188  81408  31696 S   0,0   2,1   2:13.96 io.tr-064.0
   3531 iobroker  20   0  656440  78800  31268 S   0,3   2,1   4:14.12 io.modbus.0
   4743 iobroker  20   0  935668  78316  32412 S   0,0   2,1   0:59.60 io.bluelink.0
   3186 iobroker  20   0  671560  77368  32788 S   0,0   2,0   1:02.29 io.sql.0
   4727 iobroker  20   0  649816  77204  35752 S   0,0   2,0   1:09.08 io.logparser.0
   4000 iobroker  20   0  933712  75180  32300 S   0,3   2,0   0:54.43 io.bmw.0
   3222 iobroker  20   0  797976  73204  31852 S   0,0   1,9   0:48.52 io.pushover.0
   3540 iobroker  20   0  657252  73048  31140 S   0,7   1,9   3:35.64 io.modbus.1
   4497 iobroker  20   0  666416  72368  31692 S   0,3   1,9   0:49.75 io.trashschedul
   4754 iobroker  20   0  666648  71792  31404 S   0,3   1,9   1:58.61 io.simple-api.0
   3608 iobroker  20   0  653516  70864  31076 S   0,3   1,9   1:52.61 io.rpi2.0
   3350 iobroker  20   0  732488  70496  31840 S   0,3   1,9   0:46.80 io.pushover.1
   4302 iobroker  20   0  651984  69332  31536 S   0,0   1,8   1:27.25 io.fullybrowser
   4174 iobroker  20   0  648200  69260  31268 S   0,0   1,8   0:43.15 io.discovery.0
   4672 iobroker  20   0  666796  66728  30984 S   0,0   1,8   0:47.98 io.signal-cmb.0
   2143 dietpi    20   0  407188  49700  36152 S   1,3   1,3   4:40.46 deCONZ
      1 root      20   0   99776   9520   7224 S   0,0   0,3   0:06.42 systemd
   2030 root      20   0   20952   8196   7144 S   0,0   0,2   0:01.80 systemd-journal
   2487 mosquit+  20   0   14084   6772   5752 S   0,3   0,2   0:40.44 mosquitto
 103639 root      20   0   10844   5728   3064 S   0,0   0,2   0:00.13 bash
   2263 root      20   0   99336   5432   4132 S   0,0   0,1   0:00.01 dhclient
   2051 root      20   0   19744   4852   3736 S   0,0   0,1   0:00.95 systemd-udevd
  13742 root      20   0   13088   4348   3848 S   0,0   0,1   0:00.00 sudo
   2363 root      20   0   14916   3988      0 S   0,0   0,1   0:02.65 dietpi-dashboar
 108509 root      20   0   11896   3516   2780 R   1,0   0,1   0:00.63 top
   2133 _rpc      20   0    8088   3472   3044 S   0,0   0,1   0:00.09 rpcbind
   2138 root      20   0    8652   3244   2828 S   0,0   0,1   0:34.32 deCONZ-update2.
 103638 root      20   0    4556   2808   2464 S   0,0   0,1   0:00.62 dropbear

While I am a beginner in Linux myself, but I set all my Linux devices for SWAP memory to be same as my RAM. I see your SWAP to be zero. You might try setting SWAP to 4GB (or at least 2GB) meanwhile, while you are troubleshooting the actual reason /culprit for memory leak.

Back in good old days (before 2000), remember following a rule of thumb - " Double the swap size to RAM size" (in Solaris). Not sure if that is still relavent/applicable to any OS at all now.

It’s a typical behaviour of every OS to start killing processes if reaching limits of available memory. Btw, DietPi is not an own OS. It’s more a set of bash scripts on top of a Debian system.

Using SWAP might be an option but this would slow down your environment due to I/O operations.

Better to avoid that :wink:

For java apps it should be possible to limit memory consumption. There are no limitation on DietPi. Should be working as on every other Linux system.

@Joulinar , agree on all counts and good to learn that OS will automatically start killing the processes to remain afloat. For speed / latency concern, maybe the applications are not that sensitive to the slight delay introduced in frequent access to the SWAP on SD card, and SWAP is bot easy to test with. If it works, then it could be an interim solution.

First of all, thanks for the contributions. Of course, as a temporary solution, I could activate the SWAP and assign a certain size. However, this would eventually slow down my system a lot and the write cycles on my SD card would rapidly shorten its life.

I think it’s the Odroid itself, since ioBroker and SAE were developed for the Raspberry Pi. Maybe it has to do with the compilation of the code.
As a non-developer I won’t be able to change that. I solve the memory problem by an automated restart every night. Unfortunately this is not the best solution, but for me probably the only feasible one.

If anyone has another tip I would be very grateful…

This is a valid solution we have done on good all days within IT companies I was working on :joy:

:slight_smile: the simplest solution… Not the smartest but the easiest…