(Testing) a virgin Linux HS3 v. 531 on a vm I just created (Ubuntu 19.04)

[Guest]

good news !

[Guest]

The next step , I think would be to test it like that to be sure it is stable., like for 6 hours. And then re-enable bllan and see if memory goes up again. It will go up because it takes memory to activate a plugin.. but if it keeps going up then you'll know it's blllan that makes the memory leak. ( indirectly because of mono i think?)

[Guest]

According to my calculations,

The ''leak'' is 8 mb per 12 hours. So i infer that it would be 16 mb per 24 hours . That is manageable, I am sure the leak is not resolved from mono side, though ( the one that was there on mono -V 5.x.x.x: let's not forget that i completely removed jowihue and mcsmqtt on my present setup and replaced them by other means * I still use mqtt and deconz)
( the leak from 6.0.0.313 have been corrected ).

[AllHailJ]

Here is the results of the test. 48MB in 17 hours so about 2.5 MB per hour.


The ending screenshot



Both HSConsole, WeatherXML, Zwave, look to be the major problems. Alot better than it was on 6.0.0.319 or .313.

[Guest]

way better on version 5.18.1.3 but clearly something is wrong with my system.

I think if you press maj + h with htop open. You,ll get a better view

[Guest]

Here is the results of the test. 48MB in 17 hours so about 2.5 MB per hour.


The ending screenshot



Both HSConsole, WeatherXML, Zwave, look to be the major problems. Alot better than it was on 6.0.0.319 or .313.

Awww you were talking about your total memory usage. Here I was only checking hs3 memory process , since it was the only one that was leaking.

This night for wtv reason , the hs3 process got a 25 mb drop after 26 hours uptime. And the others plugin got a drop in memory usage too . And little after that I opened the webgui accidentally again (starting to wonder if this contribute to the leak since the memory was stable yesterday and now it goes up.. will have a better view tomorrow I guess).

anyway, your hs3 process seem stable now. That’s good news .

[Guest]

I truly encourage anyone that is having a leak on Linux to send an email to HS support . I just did it. I do not find it normal for us to have to test this like that .

I just sent them an email, saying that they should check more closely the memory usage on Linux.

[Guest]

I rebooted the pc by accident by typing ''reboot'' to the wrong ssh session..lol.


I think it'll be ok for me. Things seems to be ''better''( at least on my patched setup without the two plugin i mentioned) so I do not think i'll test again in a near future. Returned to mono -pre-compiled binary stable package 6.0.0.319.

[Pete]

BTW this morning noticed a "new" mono update which is again update 319. Last one was dated August 6, 2019.

mono -V
Mono JIT compiler version 6.0.0.319 (tarball Tue Aug 6 16:30:29 UTC 2019)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com


Today same version update but different date.

mono -V
Mono JIT compiler version 6.0.0.319 (tarball Fri Aug 9 16:23:57 UTC 2019)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com

[Guest]

I can confirm . Mono 3.0.0.319 has a leak . Can someone follow this topic on github? I won't have time . We are moving to another place in the next days ( sooner than i thought).

And i'll have to turn off the automation like in the next hours ( need to label everything etc).

Github issue

Yesterday when i saw the memory consumption I recompiled mono and did a backup (clone of my ssd) from this. I waited one day ( almost) to be sure 6.7 was ok. What is funny is that it is actually faster ( amd 2700x) to compile vs to update mono via APT and wait for llvm

This time I do not have a graph i turned it off yesterday.

[AllHailJ]

I can confirm . Mono 3.0.0.319 has a leak . Can someone follow this topic on github? I won't have time . We are moving to another place in the next days ( sooner than i thought).

And i'll have to turn off the automation like in the next hours ( need to label everything etc).

Github issue

Yesterday when i saw the memory consumption I recompiled mono and did a backup (clone of my ssd) from this. I waited one day ( almost) to be sure 6.7 was ok. What is funny is that it is actually faster ( amd 2700x) to compile vs to update mono via APT and wait for llvm

This time I do not have a graph i turned it off yesterday.

I am following - hope the move goes well.

[bsobel]

I truly encourage anyone that is having a leak on Linux to send an email to HS support . I just did it. I do not find it normal for us to have to test this like that .

I just sent them an email, saying that they should check more closely the memory usage on Linux.

Matt this has driven me crazy my entire time on HS. I reported it many times, all I got was ‘we really test under Windows’. I’m extremely happy your tackling this (understanding you shouldn’t have to)...

[happnatious1]

I think if you press maj + h with htop open. You,ll get a better view

Much better, thanks!
mono 5.20.1.34

[Guest]

how is the 6.0.0 Stable (6.0.0.327) ?

[Guest]

my setup is 95 % functional. I have maybe 45 less events.. since some logic were not applicable at our new place.


anyways, with my setup , always on 6.7 ( compiled no so long ago ) my memory is barely leaking 10 mb per day (did run the setup for 6 days)


Mono JIT compiler version 6.7.0 (master/9d1eec6bf88 Sat 24 Aug 2019 07:09:49 PM EDT)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS: __thread
SIGSEGV: altstack
Notifications: epoll
Architecture: amd64
Disabled: none
Misc: softdebug
Interpreter: yes
LLVM: supported, not enabled.
Suspend: hybrid
GC: sgen (concurrent by default)