I've made a stink in the past in various threads about memory leakage and having to reboot my HE frequently. I took the advice of splitting the load between my C-7 and C-8 hubs and that helped a lot. But really the latest memory fixes from @gopher.ny in this release have really been a huge help. This is my current state:
Plus if I plug the latest memory use statistics into the spreadsheet I created (seen in this thread) Spreadsheet to evaluate/predict Hub Memory Leak impact it shows that I will go well over a month - at least - before needing to reboot. Anyway, there's always a lot of negative feedback about memory issues in HE, and I just thought the HE development team deserved some good news for a change. A few months ago I couldn't go a week before a necessary reboot. This is a lot of improvement and I really appreciate it.
But seriously... really appreciate the focus on this area of stability and performance. It can be as important as major features when it comes to a smart home, IMHO. You can have all the features you want, but if it doesn't perform or needs constant attention.... it can be like not having some of the features.... If that makes sense....
I used to administer hundreds of SunOS machines. We measured uptimes in the 100s of days. Pretty sure I had hit over 600 days of uptime on a few of those boxes. Windoze, yeah, not so long before you'd have to give it the three finger salute.
Interesting that the inferior product (Windows) prevailed over the superior product (Unix\SunOS\MacOS). Will that be the same in the Home Automation space I wonder where Hubitat is the Unix equivalent. A reliable workhorse that gets the job done but no pretty interface.
In the industrial space we have some Windows boxes that go (literally) years between reboots (completely standalone machines, so patching isn't as important from a security perspective). Windows CAN run for a very, very long time between reboots.
And I have some Red Hat servers that have to be reboot weekly. So go figure?
I think it all comes down to the quality of drivers and applications in the end. While I'm a Linux fan in general, it is far from bulletproof or fool proof.
And saying one is "superior" of the other is, well subjective at best. If ease of use and hurdle of technical know-how is a factor, Windows beats Linux in every flavor every time (subjective). That's coming from a guy that mostly maintains Linux in his personal life.
Gopher has improved memory management in the 2.3.6 releases, which should help float all boats higher.
Additionally, if you reboot your hub about 10m after a hub FW update you will recover some memory that is used when the hub iterates through all the built-in apps and drivers on first boot after an update. Whether this is useful varies. HE staff has said (and we've seen here in the forum posts) that the impact of memory levels is inconsistent, it's not a fixed "if memory <X, any hub will have issues." So YMMV...
Case in point - I was down to 147,000 recently on my C8 and hovered around there for a few days. The only way I knew was that I had a rule set up to tell me when I went below 150,000. The hub was running fine, pages loaded normally, automations worked fine, etc. I have 93 Zigbee and 60+ Z-Wave and all of my automations run on the C8, so it has a pretty significant load yet was not bogging down at that "low memory" state. I rebooted "just in case" but if I didn't have the rule in place maybe it would have kept chugging along at that level for additional days/weeks?
I was about to say the same thing. I have seen others having problems, so I know it's not "fixed" per se. I'm just saying in my particular case I've gone from surviving 4 days between reboots to being good for over a month (projected.) So, better for me. And that's the issue really. There are literally an infinite number of possible configurations with an infinite set of outcomes. I only wanted to report that for me things are much improved.