VIS nach einigen Monaten recht träge

Christobal0815

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

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

Raspberry Pi 2 Model B Rev 1.1

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

ich verwende auf einem Raspi 3B

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

werde ich wohl doch auf eine Proxmox VM migrieren müssen um mehr RAM zur Verfügung zu haben.

währe angebracht bei der Anzahl von Adaptern

Das mit Mod. 2 habe ich beim Posten des Berichts auch gesehen. Ich war tatsächlich der Meinung dass das ein 3b ist. Danke Euch allen für die Hilfe

Thomas Braun

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

dann werde ich wohl doch auf eine Proxmox VM migrieren müssen um mehr RAM zur Verfügung zu haben.

Dann pfleg das System dort besser als das jetzige.

Christobal0815

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

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

dann werde ich wohl doch auf eine Proxmox VM migrieren müssen um mehr RAM zur Verfügung zu haben.

Dann pfleg das System dort besser als das jetzige.

Bin für tipps dankbar.

Thomas Braun

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

Bin für tipps dankbar.

Was meinst du?
Ich spreche z. B. von

Pending Updates: 95
nodejs v14.20.1

Christobal0815

@thomas-braun Ich habe darauf geachtet, dass regelmäßig die Instanzen oder Host upgedatet werden. Um das Linux System habe ich mich mangels Kenntnissen wenig gekümmert.

sind
apt-get update
apt-get upgrade

die richtigen Befehle um die Baustelle mit Pending Updates zu fixen?

Thomas Braun

@christobal0815

sudo apt update
sudo apt full-upgrade

Für nodejs schau in meiner Signatur, da muss die nodesource.list angepasst werden.
Um eine potentere Lösung kommst du aber nicht herum.

crunchip

@christobal0815 und die ein oder andere verzichtbare Instanz vorübergehend stilllegen, um Ram zu sparen
z.b. discovery

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.

NEWS

VIS nach einigen Monaten recht träge

Support us

1.1k
Online

32.4k
Users

81.2k
Topics

1.3m
Posts

NEWS

VIS nach einigen Monaten recht träge

Support us

1.1kOnline

32.4kUsers

81.2kTopics

1.3mPosts

1.1k
Online

32.4k
Users

81.2k
Topics

1.3m
Posts