mr-varga
(Mr-Varga)
January 24, 2020, 7:05pm
1
Dear all,
I have a Raspberry Pi 3 b+ with hassio running, all works perfectly except the cpu load. Is too high, and sometime NodeRed lost the connection with hassio and automation stop working for some seconds.
I think the problem is InfluxDB, you can see a top comand in the attached video.
Here are the InfluxDB settings:
{
"auth": true,
"reporting": true,
"ssl": true,
"certfile": "fullchain.pem",
"keyfile": "privkey.pem",
"envvars": [
{
"name": "INFLUXDB_MONITOR_STORE_ENABLED",
"value": "false"
}
]
}
I think this is good. How can I reduce the cpu load? Have you any idea??
mr-varga
(Mr-Varga)
January 26, 2020, 2:08am
2
Nobady have this problem?
mr-varga
(Mr-Varga)
February 14, 2020, 1:02am
4
Also the python3 process is very cpu expensive…
Not sure if still relevant, but posting it here should somebody search for it.
Analysis
I also had issues with very high CPU load a hassio install on a Raspberry PI. I found out this was caused by Influx through issuing the following command (using the SSH addon ):
docker stats
This resulted in the following:
It clearly shows influx is the culprit, using most of the CPU and memory resources.
Solution
After a suggestion on the forum and some more googling I found an influx issue suggesting to change influx’s configuration to:
[monitor]
store-enabled = false
In a default hassio + influx install you can find can do this as follows:
Log into the influxdb addon docker image via SSH (using the aforementioned addon):
docker exec -it [container id] /bin/bash
Go to the directory containing the influxdb configuration file in:
cd /etc/influxdb/
Install a file editor (as there seems to be none installed):
apt-get update
apt-get install joe
Edit the configuration file by appending the above configuration to it:
joe influxdb.conf
Save the configuration file by pressing Ctrl KX (if using joe)
Exit the influxdb container
Restart influx:
docker restart [container id]
In my case everything went back to normal: memory dropped by about 20 percentage points and CPU to 1-2% on average.
2 Likes
SteWi
(Stefan)
May 29, 2020, 8:37am
6
Wow, thanks @laurensvp . That totally solved my Influx CPU usage problem!
I’ve tried this but it’s hard to tell if it’s actually having any affect. The change to influxdb.conf doesn’t appear to be permanent.
Is there a way to permanently modify the default influxdb.conf to persist through restarts?
changing the config file inside the container will not be permanent.
You can change the configuration of InfluxDB through environment variables which you can set using HA supervisor.
envvars:
- name: INFLUXDB_MONITOR_STORE_ENABLED
value: 'false'
https://docs.influxdata.com/influxdb/v1.7/administration/config/#monitoring-settings
1 Like
odinb
(Odin)
December 2, 2020, 4:23pm
9
Tried the above change (store-enabled = false) and restarted the container, but it did not change the load on the influxdb container, it is still extremely high!
Any other ideas?
odinb
(Odin)
December 2, 2020, 5:13pm
10
Seem to have found the culprit!
Removed the glances integration, and load fell off a cliff! It is now running at less than 10% of earlier load with very brief spikes up to half of previous load!
Re-added glances, and load stays low!
QbaF
(Qba F)
December 12, 2020, 7:27pm
11
For me changing to 64bit solve the problem.
2 Likes
Necroed an aging thread, but I think for a good reason.
I had the same issue of high influxdb cpu usage, running current hassos with the influxdb addon. I tried
envvars:
- name: INFLUXDB_MONITOR_STORE_ENABLED
value: 'false'
…which did not work for me. Note that I had “restart on reboot” and “watchdog” enabled. What fixed it for me, was simply shutting down the influxdb addon, unselecting watchdog, and rebooting the host. After the reboot, cpu usage is back to normal. Note that I think it was the watchdog setting, as the high cpu use persisted after previous reboots.
Hope this helps someone some day.
Seems I may have lied in my post above… today about 2days later, the high CPU usage returned. A lot of what I have read seems to relate to a 32bit vs 64bit problem, but not sure how to solve that with hassos?
tom_l
November 22, 2021, 11:35pm
14
Create a full blackup. Copy it off the system. Install 64bit HA OS. Restore backup.
1 Like
Unfortunately for me, I use esphome. Is there another way, other than turning off influxdb until esphome is fixed?
opened 06:21PM - 30 Jul 20 UTC
Project: Home Assistant Addon
<!-- Thanks for reporting a bug for this project. READ THIS FIRST:
- Provide … as many details as possible. Simply saying "X gives bug" or "X gives error" is not enough!
- Paste logs, configuration sample and code into the backticks (```).
- Read through the template carefully and fill out all missing details.
- Please also search for similar issues in this issue tracker first and read through the ESPHome FAQ.
DO NOT DELETE ANY TEXT from this template! Otherwise the issue may be closed without a comment.
-->
**Operating environment/Installation (Hass.io/Docker/pip/etc.):**
<!--
Please provide details about your environment below this line. -->
_Hass.io on Odroid N2_
Hass.io Add-on: ESPHome (beta)
Beta version of ESPHome Hass.io add-on.
Add-on version: 1.15.0b3
You are running the latest version of this add-on.
System: Debian GNU/Linux 9 (stretch) (armv7 / odroid-xu)
Home Assistant Core: 0.113.2
Home Assistant Supervisor: 229
**ESP (ESP32/ESP8266, Board/Sonoff):**
<!--
Please provide details about which ESP you're using below.
-->
ESP8266, but irrelevant
**ESPHome version (latest production, beta, dev branch)**
<!--
ESPHome version like v1.14 or 1.15-dev
-->
1.15.0b3 - fails for ESP32 and ESP8266
latest dev - fails for ESP32 and ESP8266
1.14.5 - fails for ESP32, works fine for ESP8266
**Affected component:**
<!--
Please add the link to the documentation at https://esphome.io/index.html of the component in question.
-->
_n/a_
**Description of problem:**
Compilation is giving me `xtensa-lx106-elf-g++: not found`
**Problem-relevant YAML-configuration entries:**
```yaml
esphome:
name: test
platform: ESP8266
board: esp01_1m
```
**Logs (if applicable):**
<!--
Please copy the debug log here. If possible, also connect to the ESP over USB and copy those logs into the backticks.
-->
```
INFO Reading configuration /config/esphome/test.yaml...
INFO Generating C++ source...
INFO Core config or version changed, cleaning build files...
INFO Deleting /data/test/.pioenvs
INFO Deleting /data/test/.piolibdeps
INFO Compiling app...
INFO Running: platformio run -d /config/esphome/test
Processing test (board: esp01_1m; framework: arduino; platform: [email protected] )
--------------------------------------------------------------------------------
PackageManager: Installing toolchain-xtensa @ ~2.40802.191122
Downloading [####################################] 100%
Unpacking [####################################] 100%
toolchain-xtensa @ 2.40802.200502 has been successfully installed!
HARDWARE: ESP8266 80MHz, 80KB RAM, 1MB Flash
PACKAGES:
- framework-arduinoespressif8266 3.20702.0 (2.7.2)
- tool-esptool 1.413.0 (4.13)
- tool-esptoolpy 1.20800.0 (2.8.0)
- toolchain-xtensa 2.40802.200502 (4.8.2)
Dependency Graph
|-- <ESP8266WiFi> 1.0
|-- <ESP8266mDNS> 1.2
| |-- <ESP8266WiFi> 1.0
Compiling /data/test/.pioenvs/test/src/esphome/core/application.cpp.o
sh: 1: xtensa-lx106-elf-g++: not found
Compiling /data/test/.pioenvs/test/src/esphome/core/component.cpp.o
sh: 1: xtensa-lx106-elf-g++: not found
Compiling /data/test/.pioenvs/test/src/esphome/core/controller.cpp.o
sh: 1: xtensa-lx106-elf-g++: not found
Compiling /data/test/.pioenvs/test/src/esphome/core/esphal.cpp.o
sh: 1: xtensa-lx106-elf-g++: not found
Compiling /data/test/.pioenvs/test/src/esphome/core/helpers.cpp.o
sh: 1: xtensa-lx106-elf-g++: not found
*** [/data/test/.pioenvs/test/src/esphome/core/application.cpp.o] Error 127
Compiling /data/test/.pioenvs/test/src/esphome/core/log.cpp.o
*** [/data/test/.pioenvs/test/src/esphome/core/component.cpp.o] Error 127
*** [/data/test/.pioenvs/test/src/esphome/core/controller.cpp.o] Error 127
*** [/data/test/.pioenvs/test/src/esphome/core/esphal.cpp.o] Error 127
*** [/data/test/.pioenvs/test/src/esphome/core/helpers.cpp.o] Error 127
sh: 1: xtensa-lx106-elf-g++: not found
*** [/data/test/.pioenvs/test/src/esphome/core/log.cpp.o] Error 127
========================= [FAILED] Took 24.86 seconds =========================
```
**Additional information and things you've tried:**
* Tried dev branch with [gitpod.io](https://gitpod.io/#https://github.com/esphome/esphome), works fine there
* Searched for the binary within the docker container, exists at
```sh
root@15ef4d2f-esphome-beta:~/.platformio/packages/toolchain-xtensa/bin# ls -la ./xtensa-lx106-elf-g++
-rwxr-xr-x 1 root root 819856 Jul 17 2019 ./xtensa-lx106-elf-g++
```
* Log for ESP32:
```sh
sh: 1: xtensa-esp32-elf-g++: not found
```
tom_l
November 23, 2021, 5:59am
16
You don’t have to use the ESPHome addon.
So would this be as simple as pip3 install esphome
in an ssh session to my pi4 running hassos… or are you implying I need to have HA in a docker with raspbian? I was hoping for a simple fix… ha os has served me well for some time now and not wanting to switch if at all possible.
tom_l
November 23, 2021, 6:27am
18
I’m saying you don’t have to run the ESPHome application on the same server as home assistant.
OK, this may be the route I go, since I have a NAS where I can put influxdb in docker. I already found a tutorial that describes doing this for HA. This is what I’m thinking of trying:
Before proceeding down that rabbit hole, I have to ask… 32bit HAOS+inlfuxdb addon… won’t have the same problem of high cpu use if the db is moved to my NAS?
I am just worried that influxdb may still try to do whatever operation on the db that is making it ill, even if it is on another system.