Memory footprint considerations

[rcaceiro]

Hello,

I am developing a matter bridge, (non profit project) the device where this will run have some memory restrictions and I noticed that only the server consume 60MB of RAM and when we add more devices it grows very fast 2x with 3, 4 devices.

This topic is something that will be checked later or is something that is already very optimised and it is nothing more todo?

Thank you for this project amazing, anyway.

[Apollon77]

Hi,

what exactly you mean wit "grows very fast"? Does it stabilize at a certain point? Please provide more details and let it maybe also run for a day or such.
Also consider that Node.js runtime alone needs 35-40 MB ...

[rcaceiro]

Yes sorry,
So when I start a node instance and comment the service and endpoint part of it it consumes around 122mb, note that I am in development mode, when I start the server grows to 136mb, when I add an accessory to the server it grows to 158mb, every device that I add to it, consumes a bit of memory.

Yes it is stable, it not seem to have a memory leak, is the cost to add a device to the server, I don't know if it's possible to reduce, just an observation.

I used the humidity temperature example, but bridging devices is more noticable.

[Apollon77]

So yes I agree, and no we did not invested too much time into memory usage optimizations, also given that we are still not featurecomplete.
I also started the sensor example. It used 136 MB RAM for a minute and then went down to 100MB and stayed there also after being commissioned

I then did the onoff bridge with one device. 140MB initially ... then went down to 108MB

• 2 bridged lights ... 140MB, down to 108 MB
• 10 bridged lights ... 143MB ... down to 118-120MB

... was tested on a raspi 4 with nodejs 20 runnning

[lauckhart]

Assuming you're looking at RSS, it's kind of tricky to assess what impact the reported value will have on the system as it will include shared pages and pages the OS can reclaim if necessary (like @Apollon77's example demonstrates).

For reference, I loaded a device on my PC with three endpoints (root, on/off light and window covering). Running an adhoc process.memoryUsage() reports rss of 335MB (which agrees with what ps reports). heapUsed, however is only 48MB. That's probably the more realistic value to keep an eye on. A memory snapshot around the same time reports 12MB for code, 11MB for strings, and ~2MB for everything else.

I loaded another device with two endpoints (root + on/off light). A heap snapshot there reports ~150KB less for code than for the 3 endpoint device but actually about 200KB more for strings. My takeaway from this in the past was that resource consumption for additional endpoints is fairly trivial... Enough so that they can get lost in the noise if you look at heap usage.

What you might do is load up a bridge (or just an endpoint with synthetic devices) with the maximum # of devices you think you must realistically support... Ideally put some load on it too but even a static test is a good start. If the system becomes unresponsive or the heap usage gets higher than you think you can support let us know your requirements and we can look into some optimization strategies for you.

[rcaceiro]

Thank you @Apollon77 and @lauckhart ,

I understand that this wasn't yet a focus for you, ok.
This is only a problem to me because I am trying to run it on a constraint environment were I do not have this flexibility, in theory I have only 100mb of memory (RSS) just on start the process is killed.

This ticket was open to understand if optimization will be a focus to you or not, however I already open a ticket to the platform devs to expand this narrow limits where are more apps having this issue, so I hope they expand a little these limits.

But thank you for you time,

[Apollon77]

In fact yes, sure we plan to also work on memory footprint, but in my eyes this only makes sense when we are a bit more feature complete. So it is on the list, but not "next-ish", but later.

What you could try is - check the examples package ... there we show how it could be "bundled" into an executable ... would be interesting (and yes I did not tried this if it makes any difference and my idea is just dumb!) if this has an effect - in general "when bundling just the needed things" which also could make sure only the needed things are loaded .....

[rcaceiro]

Yes make sense, if was me I would do the same thing.

[lauckhart]

I converted to a discussion...

@rcaceiro 100mb is a reasonable target and you should be able to hit today I think.

You need to tell node if there are memory limits in place. Otherwise it can be pretty lazy about garbage collection. You can do this with node's --max-old-space-size option. matter.js runs ok for me on x64 linux with Node 22 and --max-old-space-size=50. That's only 50mb though and is pushing it... you'd want to test IRL and make sure the number is high enough to avoid OOM.

Also, ideally you would are constrained on unreclaimable memory rather than the somewhat arbitrary total rss size. To remain within the limit you or admins might want to consider running in a cgroup where you can set memory.high. This will cause the OS to reclaim memory so you don't have unnecessary pages hanging out. It can also force swap (for better or worse) if necessary & enabled.

When I run a device in a cgroup limited to 100mb and have max old space set to 50mb, matter.js settles at ~34mb RssAnon and ~50mb RssFile. So total RSS is under your 100mb cap. I'm not an expert but I believe 34mb is the portion we will be able to improve with optimization.

Anyway, thanks for bringing this up, researching was one of our TODOs.

[rcaceiro]

OK, however I don't call the executable, the code is package like an app and the system runs for me, anyway I will try to check out to the platform devs if I can pass any configuration flags to be set on run the app.

Thank you for you assistant very helpful and insightful

[rcaceiro]

I am using the new version 0.11.9 and I see improvements, I don't know if was your focus also, but thank you, nice job guys.