# Successive deployments increase CPU load

**URL:** <https://discourse.nodered.org/t/successive-deployments-increase-cpu-load/9202>\
**Category:** General\
**Created:** [19 March 2019 20:11 UTC](https://discourse.nodered.org/t/successive-deployments-increase-cpu-load/9202 "2019-03-19T20:11:32Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![guardiande](https://avatars.discourse-cdn.com/v4/letter/g/e0b2c6/32.png) [@guardiande](https://discourse.nodered.org/u/guardiande)\
**Post date:** [19 March 2019 20:11 UTC](https://discourse.nodered.org/t/successive-deployments-increase-cpu-load/9202/1 "2019-03-19T20:11:32Z")

</div>

I noticed that repetitive deployments increase the CPU load. I noticed it first on 0.19.5 but it still holds for 0.20.2. Stopping and starting Node Red reduces the load to a normal level.

![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/2X/3/39331deee8fd412b7352a5b4a141462d6a8c7cd5.png)

I did several (like 20 to 30) deployments during 2000 and 2300.

I'm running NR on a Raspberry Pi 3 running Raspian, Node v10.15.0.

Is this a known behaviour?

---

<div class="post-metadata">

**Author:** ![knolleary](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/knolleary/32/3_2.png) [@knolleary](https://discourse.nodered.org/u/knolleary)\
**Post date:** [20 March 2019 00:56 UTC](https://discourse.nodered.org/t/successive-deployments-increase-cpu-load/9202/2 "2019-03-20T00:56:26Z")

</div>

> [@guardiande](#):
>
> Is this a known behaviour?

Hi @guardiande. No, this isn't a known behaviour.

I can't say we explicitly check this sort of thing in our tests, but we haven't had any similar reports.

It could well be a node you are using failing to free up some resource or stop some processing when the deploy is done.

Tracking down that node would require some detective work. What nodes are you using in your flows?

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [20 March 2019 07:16 UTC](https://discourse.nodered.org/t/successive-deployments-increase-cpu-load/9202/3 "2019-03-20T07:16:29Z")

</div>

You also need to check some other metrics on your Pi. Such as SWAP use. Because the Pi's typically use SD cards for storage, paging things from memory to swap and back has a significant overhead.

Without understanding a lot more about what is running on the Pi, how active things are and so on, it is hard to make a judgement.

This is from my Pi3:

 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/2X/2/2b772909eb7dec6e70ef50e37917ddaeaa6e8ee3.png)

And this from my much busier Pi2:

 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/2X/b/b34df5b0443a26e4928c5e3e7dd505f29421dabf.png)

As you can see, under relatively busy conditions, the loads are so variable it would be hard to pick out a trend like yours.

What I can see though is that your average CPU load is quite high. I think my Pi2 is quite busy but average overall is relatively low still.

---

<div class="post-metadata">

**Author:** ![guardiande](https://avatars.discourse-cdn.com/v4/letter/g/e0b2c6/32.png) [@guardiande](https://discourse.nodered.org/u/guardiande)\
**Post date:** [20 March 2019 08:33 UTC](https://discourse.nodered.org/t/successive-deployments-increase-cpu-load/9202/4 "2019-03-20T08:33:23Z")

</div>

Here's the full list of installed nodes:

```auto
Nodes Types State
node-red-contrib-alexa-local/alexa-local alexa-local enabled
node-red-contrib-better-sonos/better-sonos-config better-sonos-config enabled
node-red-contrib-better-sonos/better-sonos-control better-sonos-control enabled
node-red-contrib-better-sonos/better-sonos-get-queue better-sonos-get-queue enabled
node-red-contrib-better-sonos/better-sonos-queue better-sonos-queue enabled
node-red-contrib-better-sonos/better-sonos-status better-sonos-status enabled
node-red-contrib-bigtimer/bigtimer bigtimer enabled
node-red-contrib-cast/cast-to-client cast-to-client enabled
node-red-contrib-contextbrowser/contextbrowser contextbrowser enabled
                                                            contextbrowser-sidebar
node-red-contrib-eztimer/eztimer eztimer enabled
node-red-contrib-flow-combine/Flow-Combine Combine Start enabled
                                                            Combine End
node-red-contrib-fritz/fritzbox fritzbox-config enabled
                                                            fritzbox-in
                                                            fritzbox-calllist
                                                            fritzbox-phonebook
node-red-contrib-fritz/fritzbox-callmonitor fritzbox-callmonitor enabled
node-red-contrib-fritz/fritzbox-contact fritzbox-contact enabled
node-red-contrib-huemagic/hue-bridge hue-bridge enabled
node-red-contrib-huemagic/hue-bridge-node hue-bridge-node enabled
node-red-contrib-huemagic/hue-brightness hue-brightness enabled
node-red-contrib-huemagic/hue-group hue-group enabled
node-red-contrib-huemagic/hue-light hue-light enabled
node-red-contrib-huemagic/hue-motion hue-motion enabled
node-red-contrib-huemagic/hue-scene hue-scene enabled
node-red-contrib-huemagic/hue-switch hue-switch enabled
node-red-contrib-huemagic/hue-tap hue-tap enabled
node-red-contrib-huemagic/hue-temperature hue-temperature enabled
node-red-contrib-influxdb/influxdb influxdb enabled
                                                            influxdb out
                                                            influxdb batch
                                                            influxdb in
node-red-contrib-lgtv/lgtv-app lgtv-app enabled
node-red-contrib-lgtv/lgtv-browser lgtv-browser enabled
node-red-contrib-lgtv/lgtv-button lgtv-button enabled
node-red-contrib-lgtv/lgtv-channel lgtv-channel enabled
node-red-contrib-lgtv/lgtv-config lgtv-config enabled
node-red-contrib-lgtv/lgtv-control lgtv-control enabled
node-red-contrib-lgtv/lgtv-mouse lgtv-mouse enabled
node-red-contrib-lgtv/lgtv-mute lgtv-mute enabled
node-red-contrib-lgtv/lgtv-request lgtv-request enabled
node-red-contrib-lgtv/lgtv-toast lgtv-toast enabled
node-red-contrib-lgtv/lgtv-volume lgtv-volume enabled
node-red-contrib-lgtv/lgtv-youtube lgtv-youtube enabled
node-red-contrib-light-scheduler/light-scheduler light-scheduler enabled
node-red-contrib-light-scheduler/light-scheduler-settings light-scheduler-settings enabled
node-red-contrib-moment/humanizer humanizer enabled
node-red-contrib-moment/moment moment enabled
node-red-contrib-openhab2/openhab2 openhab2-controller enabled
                                                            openhab2-in
                                                            openhab2-get
                                                            openhab2-monitor
                                                            openhab2-out
                                                            openhab2-events
node-red-contrib-persist/persist persist-store enabled
                                                            persist in
                                                            persist out
node-red-contrib-pushover/pushover pushover-keys enabled
                                                            pushover api
                                                            glances
node-red-contrib-schedex/schedex schedex enabled
node-red-contrib-simple-gate/gate gate enabled
node-red-contrib-stoptimer/stoptimer stoptimer enabled
node-red-contrib-string/string string enabled
node-red-contrib-sun-position/moon-position moon-position enabled
node-red-contrib-sun-position/position-config position-config enabled
node-red-contrib-sun-position/sun-position sun-position enabled
node-red-contrib-sun-position/time-comp time-comp enabled
node-red-contrib-sun-position/time-inject time-inject enabled
node-red-contrib-sun-position/time-span time-span enabled
node-red-contrib-sun-position/within-time-switch within-time-switch enabled
node-red-contrib-time-range-switch/time-range-switch time-range-switch enabled
node-red-contrib-timerswitch/timerswitch timerswitch enabled
node-red-contrib-traffic/traffic traffic enabled
node-red-contrib-uibuilder/uibuilder uibuilder enabled
node-red-contrib-wait-paths/wait-paths wait-paths enabled
node-red-dashboard/ui_audio ui_audio enabled
node-red-dashboard/ui_base ui_base enabled
node-red-dashboard/ui_button ui_button enabled
node-red-dashboard/ui_chart ui_chart enabled
node-red-dashboard/ui_colour_picker ui_colour_picker enabled
node-red-dashboard/ui_date_picker ui_date_picker enabled
node-red-dashboard/ui_dropdown ui_dropdown enabled
node-red-dashboard/ui_form ui_form enabled
node-red-dashboard/ui_gauge ui_gauge enabled
node-red-dashboard/ui_group ui_group enabled
node-red-dashboard/ui_link ui_link enabled
node-red-dashboard/ui_numeric ui_numeric enabled
node-red-dashboard/ui_slider ui_slider enabled
node-red-dashboard/ui_spacer ui_spacer enabled
node-red-dashboard/ui_switch ui_switch enabled
node-red-dashboard/ui_tab ui_tab enabled
node-red-dashboard/ui_template ui_template enabled
node-red-dashboard/ui_text ui_text enabled
node-red-dashboard/ui_text_input ui_text_input enabled
node-red-dashboard/ui_toast ui_toast enabled
node-red-dashboard/ui_ui_control ui_ui_control enabled
node-red-node-email/email e-mail enabled
                                                            e-mail in
node-red-node-feedparser/feedparse feedparse enabled
node-red-node-rbe/rbe rbe enabled
node-red-node-sentiment/sentiment sentiment enabled
node-red-node-tail/tail tail enabled
node-red-node-timeswitch/timeswitch timeswitch enabled
node-red-node-twitter/twitter twitter-credentials enabled
                                                            twitter in
                                                            twitter out
node-red/batch batch enabled
node-red/catch catch enabled
node-red/change change enabled
node-red/comment comment enabled
node-red/CSV csv enabled
node-red/debug debug enabled
node-red/delay delay enabled
node-red/exec exec enabled
node-red/file file enabled
                                                            file in
node-red/function function enabled
node-red/HTML html enabled
node-red/httpin http in enabled
                                                            http response
node-red/httpproxy http proxy enabled
node-red/httprequest http request enabled
node-red/inject inject enabled
node-red/JSON json enabled
node-red/link link in enabled
                                                            link out
node-red/mqtt mqtt in enabled
                                                            mqtt out
                                                            mqtt-broker
node-red/range range enabled
node-red/rpi-gpio rpi-gpio in enabled
                                                            rpi-gpio out
                                                            rpi-mouse
                                                            rpi-keyboard
node-red/sort sort enabled
node-red/split split enabled
                                                            join
node-red/status status enabled
node-red/switch switch enabled
node-red/tcpin tcp in enabled
                                                            tcp out
                                                            tcp request
node-red/template template enabled
node-red/tls tls-config enabled
node-red/trigger trigger enabled
node-red/udp udp in enabled
                                                            udp out
node-red/unknown unknown enabled
node-red/watch watch enabled
node-red/websocket websocket in enabled
                                                            websocket out
                                                            websocket-listener
                                                            websocket-client
node-red/XML xml enabled
node-red/YAML yaml enabled

```

I quite extensively use the alexa-local and openhab2 functionality.

Are there any good hints on how to analyze the node.js activity in terms of event loop and synchronous activity, e.g. what is it doing. Something like a sampling or stacktrace of the running process?

---

<div class="post-metadata">

**Author:** ![guardiande](https://avatars.discourse-cdn.com/v4/letter/g/e0b2c6/32.png) [@guardiande](https://discourse.nodered.org/u/guardiande)\
**Post date:** [20 March 2019 08:36 UTC](https://discourse.nodered.org/t/successive-deployments-increase-cpu-load/9202/5 "2019-03-20T08:36:33Z")

</div>

Oh, sorry. The graph is misleading: The CPU load on the machine is comfortably below 20%, I'm just filling up with the idle percentage (the space between the orange and the green line).

The effect (user load increases with each deployment - the orange line) is 100% reproducible and is not caused by other workloads on the machine.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [20 March 2019 08:37 UTC](https://discourse.nodered.org/t/successive-deployments-increase-cpu-load/9202/6 "2019-03-20T08:37:05Z")

</div>

If you run something like 'top' you will see which processors are consuming the processor, which may be helpful.

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [20 March 2019 08:57 UTC](https://discourse.nodered.org/t/successive-deployments-increase-cpu-load/9202/7 "2019-03-20T08:57:39Z")

</div>

As knolleary suggested, it is most likely that one node or other isn't freeing up it's resources correctly when we re-deploy (i.e. not shutting down old ports, links, listeners, etc correctly). However, given the extensive list you have provided - finding the one (or several) - is going to be hard. The brute force approach is to remove them one at a time, and re-measure - but that will no doubt break your flow as well.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [20 March 2019 09:01 UTC](https://discourse.nodered.org/t/successive-deployments-increase-cpu-load/9202/8 "2019-03-20T09:01:33Z")

</div>

Would I be right in thinking that it is likely that if @guardiande was doing partial deploys rather than full deploys and still sees the issue, then that would indicate that it is likely to be to do with nodes being re-deployed?

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [20 March 2019 09:02 UTC](https://discourse.nodered.org/t/successive-deployments-increase-cpu-load/9202/9 "2019-03-20T09:02:34Z")

</div>

Well clearly moment and uibuilder can't be a problem 😉

---

<div class="post-metadata">

**Author:** ![krambriw](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/krambriw/32/5429_2.png) [@krambriw](https://discourse.nodered.org/u/krambriw)\
**Post date:** [20 March 2019 09:05 UTC](https://discourse.nodered.org/t/successive-deployments-increase-cpu-load/9202/10 "2019-03-20T09:05:21Z")

</div>

I think that could be a clever way, just move a node a bit in the editor, make a partial deploy, check. Repat for all nodes one by one, hopefully the blaming one is found

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [20 March 2019 09:06 UTC](https://discourse.nodered.org/t/successive-deployments-increase-cpu-load/9202/11 "2019-03-20T09:06:18Z")

</div>

> [@Colin](#):
>
> If you run something like 'top' you will see which processors are consuming the processor, which may be helpful.

I generally recommend glances which is a Python-based tool. Although it takes a fair bit of processor itself, it is great for a quick peek into what's happening.

If you need longer-term monitoring, you could do worse than use a combination of InfluxDB, Telegraf (from the same people, which can monitor lots of different things and logs the outputs to all sorts of places including InfluxDB) and Grafana to give you the charts and dashboard - that's what produced the charts I showed.

---

<div class="post-metadata">

**Author:** ![guardiande](https://avatars.discourse-cdn.com/v4/letter/g/e0b2c6/32.png) [@guardiande](https://discourse.nodered.org/u/guardiande)\
**Post date:** [20 March 2019 09:25 UTC](https://discourse.nodered.org/t/successive-deployments-increase-cpu-load/9202/12 "2019-03-20T09:25:16Z")

</div>

> [@Colin](#):
>
> If you run something like 'top' you will see which processors are consuming the processor, which may be helpful.

It is out of question that it is Node Red causing the increasing CPU load.

---

<div class="post-metadata">

**Author:** ![guardiande](https://avatars.discourse-cdn.com/v4/letter/g/e0b2c6/32.png) [@guardiande](https://discourse.nodered.org/u/guardiande)\
**Post date:** [20 March 2019 09:27 UTC](https://discourse.nodered.org/t/successive-deployments-increase-cpu-load/9202/13 "2019-03-20T09:27:49Z")

</div>

> [@TotallyInformation](#):
>
> I generally recommend glances which is a Python-based tool. Although it takes a fair bit of processor itself, it is great for a quick peek into what's happening.

Although I only took a quick look at glances I come to the conclusion that this is at much to high abstraction level (like top) to debug the issue.

I need something like jstack for Java applications, not sure if there's such a thing for node.js apps.

---

<div class="post-metadata">

**Author:** ![guardiande](https://avatars.discourse-cdn.com/v4/letter/g/e0b2c6/32.png) [@guardiande](https://discourse.nodered.org/u/guardiande)\
**Post date:** [20 March 2019 09:29 UTC](https://discourse.nodered.org/t/successive-deployments-increase-cpu-load/9202/14 "2019-03-20T09:29:22Z")

</div>

> [@Colin](#):
>
> Would I be right in thinking that it is likely that if @guardiande was doing partial deploys rather than full deploys and still sees the issue, then that would indicate that it is likely to be to do with nodes being re-deployed?

Good idea, will check that out.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [20 March 2019 09:31 UTC](https://discourse.nodered.org/t/successive-deployments-increase-cpu-load/9202/15 "2019-03-20T09:31:54Z")

</div>

You should check that it is the node-red process, rather than something associated with node-red. It is not inconceivable that it is influx for example as it is could be affected by the re-deploys. Or perhaps one of the added nodes uses a server of some sort that is being re-invoked so you end up with multiple copies of it.

---

<div class="post-metadata">

**Author:** ![guardiande](https://avatars.discourse-cdn.com/v4/letter/g/e0b2c6/32.png) [@guardiande](https://discourse.nodered.org/u/guardiande)\
**Post date:** [20 March 2019 10:05 UTC](https://discourse.nodered.org/t/successive-deployments-increase-cpu-load/9202/16 "2019-03-20T10:05:49Z")

</div>

> [@Colin](#):
>
> You should check that it is the node-red process

This is what I meant. It is definitely the NR process.

---

<div class="post-metadata">

**Author:** ![zenofmud](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/zenofmud/32/316_2.png) [@zenofmud](https://discourse.nodered.org/u/zenofmud)\
**Post date:** [20 March 2019 11:20 UTC](https://discourse.nodered.org/t/successive-deployments-increase-cpu-load/9202/17 "2019-03-20T11:20:40Z")

</div>

What are you using to measure and produce the graph?

---

<div class="post-metadata">

**Author:** ![guardiande](https://avatars.discourse-cdn.com/v4/letter/g/e0b2c6/32.png) [@guardiande](https://discourse.nodered.org/u/guardiande)\
**Post date:** [20 March 2019 12:55 UTC](https://discourse.nodered.org/t/successive-deployments-increase-cpu-load/9202/18 "2019-03-20T12:55:07Z")

</div>

This is a concert of collectd on the Pi for collecting the system statistics, Influxdb for storing the time-series data and Grafana for visualizing it.

---

<div class="post-metadata">

**Author:** ![guardiande](https://avatars.discourse-cdn.com/v4/letter/g/e0b2c6/32.png) [@guardiande](https://discourse.nodered.org/u/guardiande)\
**Post date:** [20 March 2019 12:57 UTC](https://discourse.nodered.org/t/successive-deployments-increase-cpu-load/9202/19 "2019-03-20T12:57:23Z")

</div>

Meanwhile I did some tests: Restarting the flows repeatedly as possible with NR 0.20 expectedly causes the load to increase. I then deployed only changes flows and did that with every single flow that I have repeatedly several times. This causes no load increase.

I suspect the configuration nodes to cause the increase.

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [20 March 2019 13:00 UTC](https://discourse.nodered.org/t/successive-deployments-increase-cpu-load/9202/20 "2019-03-20T13:00:27Z")

</div>

> [@guardiande](#):
>
> Although I only took a quick look at glances I come to the conclusion that this is at much to high abstraction level (like top) to debug the issue.
> 
> I need something like jstack for Java applications, not sure if there's such a thing for node.js apps.

Indeed.

To go further, you can use the `--inspect` flag and use a Chromium based browser - I'm using Vivaldi or use the debug features of VScode - documented on my blog and elsewhere.

[Next page](https://discourse.nodered.org/t/successive-deployments-increase-cpu-load/9202.md?page=2)