Monatsrückblick Januar/Februar 2026 ist online!

[Christobal0815]

Nach einem Hardware Update und Umzug auf besagte Hardware läuft das System wieder.
Leider hat sich die Performance nicht wesentlich verbessert. Ich bin der Meinung, dass das System damals wesentlich flotter war. Schade ... :(

``
======================= SUMMARY =======================
                     v.2023-04-16


Operatingsystem:        Ubuntu 22.04.2 LTS
Kernel:                 5.15.0-76-generic
Installation:           kvm
Timezone:               Etc/UTC (UTC, +0000)
User-ID:                1000
X-Server:               false
Boot Target:            graphical.target

Pending OS-Updates:     0
Pending iob updates:    0

Nodejs-Installation:    /usr/bin/nodejs         v18.16.1
                        /usr/bin/node           v18.16.1
                        /usr/bin/npm            9.5.1
                        /usr/bin/npx            9.5.1

Recommended versions are nodejs 18.x.y and npm 9.x.y
Your nodejs installation is correct

MEMORY:
               total        used        free      shared  buff/cache   available
Mem:            5.8G        990M        3.9G        1.0M        934M        4.5G
Swap:             0B          0B          0B
Total:          5.8G        990M        3.9G

Active iob-Instances:   14
Active repo(s): stable

ioBroker Core:          js-controller           4.0.24
                        admin                   6.3.5

ioBroker Status:        iobroker is running on this host.


Objects type: jsonl
States  type: jsonl

Status admin and web instance:
+ system.adapter.admin.0                  : admin                 : ioBroker                                 -  enabled, port: 8081, bind: 0.0.0.0, run as: admin
+ system.adapter.web.0                    : web                   : ioBroker                                 -  enabled, port: 8082, bind: 0.0.0.0, run as: admin

Objects:                7488
States:                 6064

Size of iob-Database:

8.2M    /opt/iobroker/iobroker-data/objects.jsonl
2.1M    /opt/iobroker/iobroker-data/states.jsonl



=================== END OF SUMMARY ====================

chris@ioBroker:~$ ======================= SUMMARY =======================
v.2023-04-16

Operatingsystem: Ubuntu 22.04.2 LTS
Kernel: 5.15.0-76-generic
Installation: kvm
Timezone: Etc/UTC (UTC, +0000)
User-ID: 1000
X-Server: false
Boot Target: graphical.target

Pending OS-Updates: 0
Pending iob updates: 0

Nodejs-Installation: /usr/bin/nodejs v18.16.1
/usr/bin/node v18.16.1
/usr/bin/npm 9.5.1
/usr/bin/npx 9.5.1

Recommended versions are nodejs 18.x.y and npm 9.x.y
Your nodejs installation is correct

MEMORY:
total used free shared buff/cache available
Mem: 5.8G 990M 3.9G 1.0M 934M 4.5G
Swap: 0B 0B 0B
Total: 5.8G 990M 3.9G

Active iob-Instances: 14
Active repo(s): stable

ioBroker Core: js-controller 4.0.24
admin 6.3.5

ioBroker Status: iobroker is running on this host.

Objects type: jsonl
States type: jsonl

Status admin and web instance:

• system.adapter.admin.0 : admin : ioBroker - enabled, port: 8081, bind: 0.0.0.0, run as: admin
• system.adapter.web.0 : web : ioBroker - enabled, port: 8082, bind: 0.0.0.0, run as: admin

Objects: 7488
States: 6064

Size of iob-Database:

8.2M /opt/iobroker/iobroker-data/objects.jsonl
2.1M /opt/iobroker/iobroker-data/states.jsonl

=================== END OF SUMMARY ====================

[crunchip]

@christobal0815 sagte in VIS nach einigen Monaten recht träge:

Leider hat sich die Performance nicht wesentlich verbessert. Ich bin der Meinung, dass das System damals wesentlich flotter war. Schade

Definiere es etwas genauer, was war flotter?

[Christobal0815]

@crunchip
Ich mache es einmal am Beispiel eines Bildes deutlich.

Früher konnte ich auf ein Rollo-Symbol drücken und die Jalousie fuhr nach ca. 2 oder 3 Sekunde nach ob bzw. nach unten.
Jetzt dauert es Handgestoppte 9 Sekunden bis nach Druck auf das Symbol etwas passiert. Das hat sich leider mit der neuen VM nicht verbessert.

Prüfe ich im KNX-Monitor wann die Befehle auf den KNX-BUS kommen sehe ich, dass das Ansprechen der entsprechenden GA die besagten 9 Sekunden dauert. Sobald es auf dem KNX-BUS ist fährt die Jalousie direkt. Ich habe das früher nie im Detail analysiert. Jetzt ist es aber wirklich störend, weil man nach dem Absetzen der Befehle ewig warten muss.

Noch ein Phänomen: Fahre ich die selbe Jalousie über "Objekte" in ioBroker und nicht über VIS dauert das Hochfahren nach Klick auf set value 3 Sekunden, Verändere ich das Objekt wieder dauert es bis er darauf reagiert 7 Sekunden. Für mich macht das alles keinen Sinn.

Würde es helfen, wenn ich history-DB und das loggen gewisser datenpunkte deaktivieren würde und eine Slave-VM aufziehe, die solche Aktivitäten durchführt? Hauptsache meine Frau ist zufrieden ;)

[Christobal0815]

Bin leider kein Experte auf dem Gebiet.

Sind evtl. irgendwelche Services auffällig?

top - 07:12:24 up  7:28,  1 user,  load average: 0,06, 0,06, 0,02
Tasks: 118 total,   1 running, 117 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1,5 us,  0,3 sy,  0,0 ni, 98,0 id,  0,0 wa,  0,0 hi,  0,2 si,  0,0 st
MiB Mem :   5779,9 total,   3387,7 free,   1237,9 used,   1154,4 buff/cache
MiB Swap:      0,0 total,      0,0 free,      0,0 used.   4275,1 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   3979 iobroker  20   0 1149560 282348  43976 S   2,3   4,8  11:19.24 iobroker.js-con
   4159 iobroker  20   0  688388  80856  38736 S   1,0   1,4   0:18.80 io.doorbird.1
   4039 iobroker  20   0  832440 167532  43612 S   0,7   2,8   1:29.53 io.javascript.0
     14 root      20   0       0      0      0 I   0,3   0,0   0:05.97 rcu_sched
    416 root      20   0       0      0      0 I   0,3   0,0   0:04.59 kworker/0:4-mm_percpu_wq
   4099 iobroker  20   0  955992  90664  38720 S   0,3   1,5   1:47.48 io.tr-064.0
   4204 iobroker  20   0  683228  76548  39056 S   0,3   1,3   0:16.55 io.trashschedul
      1 root      20   0  102148  12940   8136 S   0,0   0,2   0:04.96 systemd
      2 root      20   0       0      0      0 S   0,0   0,0   0:00.00 kthreadd
      3 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 rcu_gp
      4 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 rcu_par_gp
      5 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 slub_flushwq
      6 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 netns
      8 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 kworker/0:0H-events_highpri
     10 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 mm_percpu_wq
     11 root      20   0       0      0      0 S   0,0   0,0   0:00.00 rcu_tasks_rude_
     12 root      20   0       0      0      0 S   0,0   0,0   0:00.00 rcu_tasks_trace
     13 root      20   0       0      0      0 S   0,0   0,0   0:00.68 ksoftirqd/0
     15 root      rt   0       0      0      0 S   0,0   0,0   0:00.32 migration/0
     16 root     -51   0       0      0      0 S   0,0   0,0   0:00.00 idle_inject/0
     18 root      20   0       0      0      0 S   0,0   0,0   0:00.00 cpuhp/0
     19 root      20   0       0      0      0 S   0,0   0,0   0:00.00 cpuhp/1
     20 root     -51   0       0      0      0 S   0,0   0,0   0:00.00 idle_inject/1
     21 root      rt   0       0      0      0 S   0,0   0,0   0:00.61 migration/1
     22 root      20   0       0      0      0 S   0,0   0,0   0:00.35 ksoftirqd/1
     24 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 kworker/1:0H-events_highpri
     25 root      20   0       0      0      0 S   0,0   0,0   0:00.00 kdevtmpfs
     26 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 inet_frag_wq
     27 root      20   0       0      0      0 S   0,0   0,0   0:00.00 kauditd
     28 root      20   0       0      0      0 S   0,0   0,0   0:00.02 khungtaskd
     29 root      20   0       0      0      0 S   0,0   0,0   0:00.00 oom_reaper
     30 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 writeback
     31 root      20   0       0      0      0 S   0,0   0,0   0:01.94 kcompactd0
     32 root      25   5       0      0      0 S   0,0   0,0   0:00.00 ksmd
     33 root      39  19       0      0      0 S   0,0   0,0   0:00.00 khugepaged
     80 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 kintegrityd
     81 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 kblockd
     82 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 blkcg_punt_bio
     83 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 tpm_dev_wq
     84 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 ata_sff
     85 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 md
     86 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 edac-poller
     87 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 devfreq_wq
     88 root     -51   0       0      0      0 S   0,0   0,0   0:00.00 watchdogd
     90 root       0 -20       0      0      0 I   0,0   0,0   0:00.25 kworker/0:1H-kblockd
     91 root      20   0       0      0      0 S   0,0   0,0   0:00.00 kswapd0
     92 root      20   0       0      0      0 S   0,0   0,0   0:00.00 ecryptfs-kthrea
     94 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 kthrotld
     95 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 acpi_thermal_pm
     97 root      20   0       0      0      0 S   0,0   0,0   0:00.00 scsi_eh_0
     98 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 scsi_tmf_0
     99 root      20   0       0      0      0 S   0,0   0,0   0:00.00 scsi_eh_1
    100 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 scsi_tmf_1
    102 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 vfio-irqfd-clea
    103 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 mld
    104 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 ipv6_addrconf

[Homoran]

@christobal0815 mal ehrlich?

wie kommst du da auf vis als Verursacher?
für mich dieht das nach einem KNX Problem aus.
zumindest der größte Anteil der "Verzögerung"

ob KNX selbst oder der Adapter kann ich nicht beurteilen.

[crunchip]

@christobal0815 sagte in VIS nach einigen Monaten recht träge:

Fahre ich die selbe Jalousie über "Objekte" in ioBroker und nicht über VIS dauert das Hochfahren nach Klick auf set value 3

Also liegt dein Problem doch eher am Frontend und nicht direkt an iobroker
Welche web Einstellung nutzt du?

Edit

Falsch gelesen, auch das zurückstellen dauert dann so lange, dann liegt der Fehler womöglich wo anders

[Christobal0815]

@homoran said in VIS nach einigen Monaten recht träge:

@christobal0815 mal ehrlich?

wie kommst du da auf vis als Verursacher?
für mich dieht das nach einem KNX Problem aus.
zumindest der größte Anteil der "Verzögerung"

ob KNX selbst oder der Adapter kann ich nicht beurteilen.

KNX selbst würde ich ausschließen, da die Verarbeitung sehr schnell funktioniert sobald ich die Adressen auf dem Gruppenmonitor sende. Okay, dann würde ich mich einmal auf den KNX-Adapter in iobroker konzentrieren. Danke!

[Homoran]

@christobal0815 sagte in VIS nach einigen Monaten recht träge:

Verändere ich das Objekt wieder dauert es bis er darauf reagiert 7 Sekunden.

@christobal0815 sagte in VIS nach einigen Monaten recht träge:

fuhr nach ca. 2 oder 3 Sekunde nach ob bzw. nach unten.
Jetzt dauert es Handgestoppte 9 Sekunden

[Christobal0815]

@crunchip said in VIS nach einigen Monaten recht träge:

@christobal0815 sagte in VIS nach einigen Monaten recht träge:

Fahre ich die selbe Jalousie über "Objekte" in ioBroker und nicht über VIS dauert das Hochfahren nach Klick auf set value 3

Also liegt dein Problem doch eher am Frontend und nicht direkt an iobroker
Welche web Einstellung nutzt du?

Ich hatte oben 2 Screenshot von der Web-Instanz gepostet. Falls ich noch weitere Sachen posten soll, dann gerne bescheid geben

[Christobal0815]

@homoran said in VIS nach einigen Monaten recht träge:

@christobal0815 sagte in VIS nach einigen Monaten recht träge:

Verändere ich das Objekt wieder dauert es bis er darauf reagiert 7 Sekunden.

@christobal0815 sagte in VIS nach einigen Monaten recht träge:

fuhr nach ca. 2 oder 3 Sekunde nach ob bzw. nach unten.
Jetzt dauert es Handgestoppte 9 Sekunden

Es ist für mich nicht reproduzierbar. Gerade eben brauchte der Rollo nach klick in VIS zum hochfahren 8 Sekunden, beim Klick runter fahren hat er in 3 Sekunden reagiert. Ich kann es nicht wirklich nachvollziehen was da schlief läuft

[crunchip]

@christobal0815 dann probier es mal anstatt integriert im web Adapter, mit ws

Ws muss als Adapter installiert sein.

Bei manchen hat es geholfen und vis lief dann wieder etwas flotter

[Christobal0815]

@crunchip said in VIS nach einigen Monaten recht träge:

manchen hat es geholfen und vis lief dann wieder etwas flott

@crunchip said in VIS nach einigen Monaten recht träge:

@christobal0815 dann probier es mal anstatt integriert im web Adapter, mit ws

Ws muss als Adapter installiert sein.

Bei manchen hat es geholfen und vis lief dann wieder etwas flotter

Danke - d.h. ich stelle im WEB-Adapter von integrated auf none.
WS = WebSocket?

Edit: Selbst entdeckt. Nach der Installation von WS taucht die Auswahl auch in web auf... Ich teste und werde berichten.

[Thomas Braun]

@christobal0815

Und ich würde dem System wieder Swap geben.
Und die Zeitzone würde ich auch setzen.

[Homoran]

@christobal0815 sagte in VIS nach einigen Monaten recht träge:

Gerade eben brauchte der Rollo nach klick in VIS zum hochfahren 8 Sekunden, beim Klick runter fahren hat er in 3 Sekunden reagiert

aber die nahezu gleichen Zeiten hattest du auch in den Objekten.
das habe ich eben zitiert.

Da ist für mich die vis außen vor!

[Christobal0815]

@thomas-braun said in VIS nach einigen Monaten recht träge:

@christobal0815

Und ich würde dem System wieder Swap geben.
Und die Zeitzone würde ich auch setzen.

@thomas-braun said in VIS nach einigen Monaten recht träge:

@christobal0815

Und ich würde dem System wieder Swap geben.
Und die Zeitzone würde ich auch setzen.

Ich stehe mit Linux auf dem Kriegsfuß. Habe die Zeitzone eingestellt, dann eine neue 16 GB HDD zu meiner VM hinzugefügt und mit ext4 formatiert (/dev/sdb1)

Current default time zone: 'Europe/Berlin'
Local time is now:      Sat Jul  8 14:02:27 CEST 2023.
Universal Time is now:  Sat Jul  8 12:02:27 UTC 2023.

chris@ioBroker:~$ df -h
Filesystem                         Size  Used Avail Use% Mounted on
tmpfs                              578M  1,1M  577M   1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv  6,1G  4,7G  1,1G  81% /
tmpfs                              2,9G     0  2,9G   0% /dev/shm
tmpfs                              5,0M     0  5,0M   0% /run/lock
/dev/sda2                          1,7G  130M  1,5G   9% /boot
tmpfs                              578M  4,0K  578M   1% /run/user/1000
chris@ioBroker:~$ ls /dev/sd*
/dev/sda  /dev/sda1  /dev/sda2  /dev/sda3  /dev/sdb  /dev/sdb1
chris@ioBroker:~$

Könnte mir jemand einen Tipp geben, wie ich swap auf die Platte legen kann?

[crunchip]

@christobal0815 https://wiki.ubuntuusers.de/Swap/

[Christobal0815]

@homoran said in VIS nach einigen Monaten recht träge:

@christobal0815 sagte in VIS nach einigen Monaten recht träge:

Gerade eben brauchte der Rollo nach klick in VIS zum hochfahren 8 Sekunden, beim Klick runter fahren hat er in 3 Sekunden reagiert

aber die nahezu gleichen Zeiten hattest du auch in den Objekten.
das habe ich eben zitiert.

Da ist für mich die vis außen vor!

@homoran said in VIS nach einigen Monaten recht träge:

@christobal0815 sagte in VIS nach einigen Monaten recht träge:

Gerade eben brauchte der Rollo nach klick in VIS zum hochfahren 8 Sekunden, beim Klick runter fahren hat er in 3 Sekunden reagiert

aber die nahezu gleichen Zeiten hattest du auch in den Objekten.
das habe ich eben zitiert.

Da ist für mich die vis außen vor!

Du hattest Recht!
Nach einer Suche nach bekannten Performance-Problemen mit dem KNX-Adapter habe ich ein downgrade durchgeführt auf Version 2.0.13. Und es läuft wieder wie früher :)
Danke!