# High host OS CPU after some pushes on random boxes

**URL:** <https://forums.balena.io/t/high-host-os-cpu-after-some-pushes-on-random-boxes/59478>\
**Category:** balenaOS\
**Created:** [January 26, 2020, 9:54pm UTC](https://forums.balena.io/t/high-host-os-cpu-after-some-pushes-on-random-boxes/59478 "2020-01-26T21:54:54Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![jezzab](https://avatars.discourse-cdn.com/v4/letter/j/5f8ce5/32.png) [@jezzab](https://forums.balena.io/u/jezzab)\
**Post date:** [January 26, 2020, 9:54pm UTC](https://forums.balena.io/t/high-host-os-cpu-after-some-pushes-on-random-boxes/59478/1 "2020-01-26T21:54:54Z")

</div>

Im currently testing some Raspberry Pis (3 x RPi3 and 1xRPi4) as we want to move everything over to Balena.

Everything is fine except for a strange issue where if I push a code/Docker file update (even a small one to a single service) the CPU/Load will become very high. It will move from circa 10% to 50% usage.

 ![Capture](https://global.discourse-cdn.com/balena/original/2X/1/1c83c156bca21ae69a23c07dd89edc15f702e71b.png)  
_The picture shows the base CPU before the push. The increase it after the push and the sudden drop is rebooting the board_

I have stopped all of the containers and then restarted them but the base idle CPU is still higher than before the push.

I have also done in the host OS:  
`systemctl stop resin-supervisor`  
`balena stop $(balena ps -aq)`  
`systemctl stop balena`  
`systemctl start balena`  
`systemctl start resin-supervisor`

And it is the same.  
If I actually reboot the device its immediately fixed

This doesnt happen on every box when pushes are done and it wont happen at all sometimes but it is doing it quite regularly, every couple of pushes

All the boxes are running the same code  
The Balena Host OS is untouched

Any help would be appreciated as this could be a deal breaker for us  
Jeremy

---

<div class="post-metadata">

**Author:** ![zubairlk](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/zubairlk/32/954_2.png) [@zubairlk](https://forums.balena.io/u/zubairlk)\
**Post date:** [January 27, 2020, 11:23am UTC](https://forums.balena.io/t/high-host-os-cpu-after-some-pushes-on-random-boxes/59478/3 "2020-01-27T11:23:48Z")

</div>

Hi @jezzab,

Welcome to the forum!

This is quite strange.  
Its understandable that there is some cpu spike when the supervisor starts pulling in the new image, stops container, starts the new application.

But then the cpu load should go back to a nominal baseline (if the application didn’t add new load).

Bizarre. What is using the cpu? Is it obvious via the `top` utility?

We can have a look via support as well.  
If you do a simple change, and then you have 1-2 devices that manifest the bug. And 1-2 devices that don’t, you can grant support access to the whole application and we can have a look.

Ideally, we’d like a nice and small Dockerfile for a repeatable test case?  
Also, I’d like to know which OS version/image are you using? the latest 64 bit ones?

Regards  
ZubairLK

---

<div class="post-metadata">

**Author:** ![jezzab](https://avatars.discourse-cdn.com/v4/letter/j/5f8ce5/32.png) [@jezzab](https://forums.balena.io/u/jezzab)\
**Post date:** [January 28, 2020, 5:41pm UTC](https://forums.balena.io/t/high-host-os-cpu-after-some-pushes-on-random-boxes/59478/5 "2020-01-28T17:41:37Z")

</div>

`top` shows `/sbin/init` when it happens, is _much_ higher on the boxes with issues and the top of the list.

RPi3s are running balenaOS 2.46.1+rev1  
RPi4 is running balenaOS 2.46.1+rev3

---

<div class="post-metadata">

**Author:** ![Ereski](https://avatars.discourse-cdn.com/v4/letter/e/958977/32.png) [@Ereski](https://forums.balena.io/u/Ereski)\
**Post date:** [January 28, 2020, 5:50pm UTC](https://forums.balena.io/t/high-host-os-cpu-after-some-pushes-on-random-boxes/59478/6 "2020-01-28T17:50:09Z")

</div>

Hi. That is indeed weird. If you enable support access and send us the UUID of a device exhibiting this behavior we can take a look. I believe `/sbin/init` is a symlink to `systemd`, so it’s hard to pin the exact cause without at least looking at the logs.

---

<div class="post-metadata">

**Author:** ![jezzab](https://avatars.discourse-cdn.com/v4/letter/j/5f8ce5/32.png) [@jezzab](https://forums.balena.io/u/jezzab)\
**Post date:** [January 28, 2020, 11:07pm UTC](https://forums.balena.io/t/high-host-os-cpu-after-some-pushes-on-random-boxes/59478/8 "2020-01-28T23:07:17Z")

</div>

Support access has been enabled and the UUID is `2d38c1256d85a0340c4dc62acfbb9305`

The above box is exhibiting the behaviour (2 are and 2 are not since the last push). The only way to be able to get it out of it is to perform a full reboot

Thanks  
Jeremy

---

<div class="post-metadata">

**Author:** ![dfunckt](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/dfunckt/32/56_2.png) [@dfunckt](https://forums.balena.io/u/dfunckt)\
**Post date:** [January 29, 2020, 11:59am UTC](https://forums.balena.io/t/high-host-os-cpu-after-some-pushes-on-random-boxes/59478/14 "2020-01-29T11:59:58Z")

</div>

Do you happen to have deltas enabled?

---

<div class="post-metadata">

**Author:** ![jezzab](https://avatars.discourse-cdn.com/v4/letter/j/5f8ce5/32.png) [@jezzab](https://forums.balena.io/u/jezzab)\
**Post date:** [January 29, 2020, 3:34pm UTC](https://forums.balena.io/t/high-host-os-cpu-after-some-pushes-on-random-boxes/59478/16 "2020-01-29T15:34:22Z")

</div>

No we don’t but should we? After reading about it, it looks very useful.

---

<div class="post-metadata">

**Author:** ![garethtdavies](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/garethtdavies/32/2669_2.png) [@garethtdavies](https://forums.balena.io/u/garethtdavies)\
**Post date:** [January 29, 2020, 5:00pm UTC](https://forums.balena.io/t/high-host-os-cpu-after-some-pushes-on-random-boxes/59478/17 "2020-01-29T17:00:56Z")

</div>

Hi, you could enable delta updates as it is indeed an awesome feature and recommended for production deployments (and will be enabled by default for all new apps soon). I’m unsure from the message above if delta updates were being suggested as a fix or a potential source of the problem but either way if you enable them and see if the problem persists it would eliminate them as a variable.
