My Hubitat C-8 (f/w 2.5.0.159) repeatedly develops low-memory warnings, sometimes accompanied by slow or missed automations. It currently has 159 devices and 139 apps.
I used ChatGPT to analyze App Stats, Device Stats, and five-minute memory readings collected across two reboot cycles. The App and Device Stats did not identify an obvious runaway app, driver, pending-event backlog, or unusually large device state.
During the first cycle, Free OS memory fell to approximately 20 MB after 23 days. A normal reboot restored the settled Free OS memory to approximately 200 MB.
During the next cycle, Free OS memory declined much faster:
Approximately 42 MB free after less than seven days
Lowest recorded reading of approximately 28 MB
Most recent 24-hour median of approximately 59 MB
At the same uptime during the previous cycle, Free OS memory was approximately 82 MB. CPU/load also increased as memory declined, while Direct Java remained around 8 MB and did not account for most of the memory loss.
The overall finding is a repeatable Free OS memory decline that temporarily clears after rebooting. The second cycle declined faster than the first, but the available statistics have not identified the responsible app, driver, integration, or platform process.
I retained the complete memory-history exports and App and Device Stats screenshots, if needed. I would appreciate any feedback and guidance from Hubitat support and community members.
I hate to be the one to say it but maybe there’s a reason Hubitat added memory to their Pro Hub?
As features are added, and although you’re not on ‘the latest’, it’s probably consuming more memory than a year ago and that tiny bit more is enough that the number of connected devices and apps you have has hit a limit. Someone else with the same number but a different mix, might be OK still.
If there’s time to run some experiments, you can always take a backup and then delete half your Apps. Yea, it’s not going to be a fully functional hub, but you can watch the memory consumption over a short time frame and compare.
You can reboot, and then watch memory for 2 hours, for example. Then after deleting a bunch of apps, freeing memory, what’s the ‘slope’ of memory after a reboot?
Obviously at any moment, you can restore the backup and have all your apps back.
It’s not a great test, because longer would be better, but it might tell you to ignore this response and find another culprit.
Is one of your apps Hubitat Diagnostics? I find it extra useful - especially the performance tab which can look at load and other valuable stats that might help pinpoint…
I have a C8-Pro, more than double your numbers. What I learned a long time ago was to offload the heavy hitters. For example, I’m heavily in to Unifi, but Unifi on my hub is light weight. Better memory management and CPU running on a secondary device. I did this with all of the apps/integations that were memory or CPU hogs.
Do I ever get a warning? I haven’t had one in a long time. Doesn’t mean one won’t pop up, nor that it’s anything to worry about necessarily if it does.
Is my setup straight forward? Oh hell no. Distributed, logical, low latency, reliable - yes.
And as @csteele said, your mix of devices, apps, etc., make a huge difference.
How much you make the hub do with some of the apps will also greatly influence performance. This includes the built in apps (see previous mention of Unifi, lol).
You don't mention what types of devices, nor what your automations consist of.
At times I have found Maker API, and other cloud based integrations can be heavy hitters. You also might have a spammy device, certain thermostats have been issues in the past as well as power reporting devices.
I know you said you had AI take a look, but maybe posting a few screenshots here would help others to understand what your hub is doing.
Since I am also running a C8 with even more devices and apps, I take offense at the off-hand recommendations to go to a C8Pro.
Until about 6 weeks ago my hub was experiencing similar sluggishness. It was always over 20% CPU losd and the CPU temperature was always over 130F. While my free memory never got to level that @yashvind is experiencing, it was low enough to make the hub sluggish due to memory and cleanup issues.
At first I started looking at the sheer number of events. For all 9 of our motorized shades, I had 4 levels of rules from sun position, to sun angles on each window, to calculated shade height and finally moving the shades. I eliminated a multitude of events by treating level 2-4 rules as subroutines.
At the same time John Land posted his Device Logging and Rule Logging apps. That started my quest to reduce logging. That was probably the most effective thing to do.
Also, reducing the update frequency for devices that are only used for information is a good thing.
Now my free memory typically stays above 80MB instead of frequently going below 60MB. This seems to have settled down the periodoc memory cleanup routine.
Now my hub runs below 120F and 20% CPU Load.
In my experience, run away devices or rules are rare. Asking the hub to do too much is a very easy thing to do. What I was putting on the hub slowly grew over time.
Throwing more hardware at a problem isn't always the best solution.r
I agree, number of apps and devices is pretty meaningless. I mean, I have 452 devices and 72 apps on my C8. My custom apps contain all my automations, and some individual apps are pretty busy. Many of my devices are just virtual child devices to my automation apps.
I know I have simply outgrown the C8, and everything is stable if I am not actively doing anything with the UI. It doesn't take much for me to get a hub load elevated warning, though it goes away pretty quickly once I stop poking things. I do get memory low warnings occasionally, but they also clear themselves, usually. If they don't clear I reboot now. I ran for weeks with a memory warning a few months ago since everything was still working well, but then all the backups taken during that time were corrupted once the hub crashed, so I had to use a really old backup and then redo things, which was quite the pain. In the middle of that episode I ordered a C8 Pro.
Summer projects and adventures have taken up my weekends, so that C8 Pro is still sitting on my desk. Every weekend is migration weekend, until it isn't again. I'm going to get there eventually. Meanwhile, the C8 is trucking along pretty well for the most part, and taking the load. I am curious what type of improvements I will see with the Pro when I get there. Going camping for two weeks starting this weekend, so next target day for migration is the 2nd weekend of August. Maybe.
This appears to be a relatively recent issue. My devices, integrations, and automations have been stable for a long time, with no significant additions or changes before the memory warnings started.
I have approximately 160 devices and 50–60 rules/automations, many of which are disabled or paused and nothing crazy logic. I keep logging to a minimum unless it is temporarily needed for a specific device or rule.
Before rebooting, I reviewed the App and Device Stats. Apps used 1.7% of total uptime, device drivers used 0.9%, there were no pending events, and nothing stood out as a clear runaway app or device.
So it looks like this thread started mainly about low memory and radios being sluggish. Memory consumption doesn't show up in those tables the same way. That is more about cpu usage. I dont think we have great ways to look at memory usage. It is generally limited to state size.
Allot of things can effect memory and certain activities can cause high consumption. Unfortunately high memory consumtions is simply about the combination of your usage. The Jave VM will naturally clean up memory based of various usage and time values. If it isn't you probably just outgrew the hub. Though I agree with one of the posts of above that throughing hardware at it is less then optimal when it comes to memory usage there really isn't much of a better option.
C-8 running 2.5.0.159. I’m having memory leak issues as well. I had memory leak issues previously that were resolved in a prior release. I used to have a rule that rebooted when it went below 150KB as that’s when I would perceive issues. I’ve paused it to see how it goes and I’m going to let it go. The lowest point is around 119KB. The peak so far today is about 174KB and is sitting at roughly 137KB right now. I cannot say definitively that it started for me with the latest release but it is back.
A few things. Here are my graphs for memory consumption. The top graph is usage. The green is a C8Pro, the yellow is a C8, and the blue is a C7. Only the C8 Pro is my prod hub so it has all of my stuff running on it including Govee Devices with 44 total devices of which 24 are LAN API devices. I see you are running my Govee Integration V2 software. I will admit as you add devices it can become more and more impactful. It also depends on how the devices work as well. How many Govee devices do you have. How many are LAN API Enabled.
Just for Giggles I took my C8 Dev hub and installed everything that was available from my Govee Integration. It initially dropped from around 350 to 150 then recovered to 190. I let it run for a bit to see if what it would maintained and it start to hover around 160. Now you can see that on that graph it has dropped low previously, but that was based on activity like active development, or other changes. Prior to loading all of the Govee devices it was stable around 320-330 with max peaks around 350. It been in that relm since last night when we had a power outage last night. I performed a restart to see where the memory would settle after a clean reboot. it settled in around 215-220. The reboot helped a little but still clearly adding the devices is using about 100mb of ram. So take that as you will. Keep in mind my use case is extreme because of the quantity of devices.
The bottom graph is interesting. The bottom one is about JVM. The blue line in that graph is the JVM Heap size for the C7 and C8 while the Green line below it is related to the C8 Pro. It is interesting that the C8 Pro isn’t holding all of the JVM Heap size from the beginning. The red is the C8 JVM Free heap while the Red is the C7 free Heap. The C8 Pro is orange and is consistently lower then the others. I wonder if there is a reason for that.
There are 2 things that increase memory usage on a permanent basis:
Chatty devices, because all new readings are new database entries, the old ones have to be deleted. My Govee outlets don't seem chattier than my other outlets.
High log settings for devices and apps. Recommend John Land's Device Logging and Rule Logging apps to review your settings. They are available in Package Manager.
Also, just looking at rules saves a new copy every time you click on Done
I think that is oversimplifying how memory gets consumed and ignores how memory is cleaned up by Garbage collection.
Database writes though impactful because data is leaving memory doesn’t cause memory to increase per se. In a JVM memory is consumed by running code, objects, variables, ect. Some of it gets cleaned up by Garbage collection once it is no longer used, and expires out based on a few criteria. Some stuff won’t leave memory though. Especially if continually used.
Please don't slam my input because it wasn't as complete as you wanted....
Since I am not a Java person, I can't speak to those items you mentioned.
My comments were based on my decades of database experience.
I apologize if you feel like i slammed your response. Many of us have different experiences. I was just trying to elaborate on it from mine. There are certainly memory consumption aspects related to DB usage.
