[bug]: During adapter update routine (upload) very high RAM consumption #2538
Comments
|
bei mir lässt sich der adapter mit 6GB (proxmox VM) nichtmal installieren. erst nach erhöhen auf 10GB läuft die installation durch. |
|
Is the host part of a multihost system? I am currently unable to reproduce, but only tried with a redis db until now. @sjfm-design you also use |
|
@foxriver76 : I had the issue with a single host system (see liked issue) |
|
@foxriver76 I have this issue on my master-slave system and on my single-host system. Both are using jsonl. |
|
Please retest with 5.0.17 |
|
@foxriver76 From my point of view no difference with jsc 5.0.17. RAM was fully consumed and SWAP was used.
|
|
I have also noticed this 'memory hunger' when installing another adapter. Current system nodejs 18.18.2, Admin 6.12.8, JS-Controller 5.0.17 on proxmox lxc. For installation I have to increase to at least 6GB, for runtime about 2GB is enough |
|
@foxriver76 Its very frustrating when updating (other) adapters and the RAM usage causes a lot of trouble ! My system uses normally 3,5Gb Ram but needs up to 12GB Ram when e.g. updating other adapters especially in my case when zigbee or infludb is updated. It happens by the way also when new datapoints needed to written in the database influx. |
|
Currently we have no idea why this happens and it seems to only affect a few installations. We had a few looks into the code and we found nothing, so we would need a installation where we can reproduce this issue. |
|
Whatever you mean with "a few" installations :-) |
|
Is it also Proxmox for you? This is maybe the only thing which is common between the cases where it occurs.
If someone with this issue could provide a backup (preferably without sensible information) + details on which adapter update it occurs on his installation, we could try to reproduce it. If I am able to reproduce it than I am most likely able to identify the issue, without this is close to impossible.
I don't really understand, could you clarify maybe by an example |
Yes it is (VM). Soon or later i will switch to a LXC Container
How can i delete sensitive information out of a backup ? Its just a file for me ?
See here the link to the forum and the discussion - it is still oopen if it is a problem to admin adapter or influx HERE |
But this is about displaying history data in admin The issue here is about adapter updates.. I don't really get the correlation currently
Yes, the But is it happening at updates for you or when accessing history data? When accessing history data and the influx is running on the same host, it could also come from influx, which is not really related to this topic here. Also recently we had a problem but it was with CPU usage and it was due to the device-watcher adapter just in case it is installed and running at your installation, this would maybe be worth a look. |
Sorry was the wrong LINK - here the new one
Thats really not OOTB. i will check when i have more time for this.
device watcher is installed but not running. That should not be the issue i think |
|
has to be likely somwhere in here @Apollon77 could reproduce it with ioBroker.iot and ioBroker.devices |
* optimize the upload procedure (#2589) - closes #2538 * fixed problem that cb is never called on mh enable/disable (#2557) * fixed problem that cb is never called on mh enable/disable * fix type * added enhanced adapter license info to schema and types (#2591) * added license info * fix update license script * format * deprecate common.license and introduce common.licenseInformation * rm local schema from controller iopack * bring back license for adapter tests * WIP placeholder added * prevent issue when values with stateNs.null exist in the database (#2580) * prevent issue when values with stateNs.null exist in the database - closes #2579 * rm log * rm anoither log * allow path aliases in adapter package * rm types from validator again * move tsc-alias to postbuild * use lerna to build project again as npm workspaces does not use the correct build script when building dependency packages - and using normal workspace flag works but is ineffective and can lead to errors due to still open npm/rfcs#548 * update jsonl * ts back to v4, accidentaly chosen by resolving merge conflict * build local * clean install to try to solve install module not found * another pack-lock update * fix linter
|
@foxriver76 I just updated my system to js-controller 5.0.19 and installed and updated the adapters which I had problems in the past. With the new js-controller I have currently no RAM issue :-) |
|
@foxriver76 |
No existing issues.
Description
During some adapter update routine (upload phase) a very high RAM consumption is detected on the system which causes that the system crashes because it was out of memory.
On my system I saw this issue during the update of the following adapters fullcalender, web, vis2, echart
On my system it is necessary to spend >= 8 GByte of RAM to minimize the problem during adapter update.
From my point of view it is not a normal behavior that an adapter update routine uses this much RAM.
Discussion in forum: https://forum.iobroker.net/topic/68462/erledigt-echarts-installiationsprobleme/8
Reference to issues where this problem was detected as well: ioBroker/ioBroker.vis#801, ioBroker/ioBroker.fullcalendar#73
Reproduction instruction
System status befor adapter update
Update echart Adapter to version 1.7.1
update log of echart adapter
iob diag
The text was updated successfully, but these errors were encountered: