Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory footprint #1378

Closed
rcaceiro opened this issue Nov 8, 2024 · 6 comments
Closed

Memory footprint #1378

rcaceiro opened this issue Nov 8, 2024 · 6 comments
Labels
question Further information is requested

Comments

@rcaceiro
Copy link

rcaceiro commented Nov 8, 2024

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
Copy link
Collaborator

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 ...

@Apollon77 Apollon77 added the question Further information is requested label Nov 8, 2024
@rcaceiro
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

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 .....

@project-chip project-chip locked and limited conversation to collaborators Nov 11, 2024
@lauckhart lauckhart converted this issue into discussion #1385 Nov 11, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants