Lange Projektaktivierung Queue = 1

[Peterich]

Nabend Zusammen,

Weihnachtszeit ist Edomi Zeit

Mir ist aufgefallen das Edomi immer ziemlich lange zum Starten braucht, und erst wieder reagiert wenn die Queue auf 0 ist.
Also hab ich mal in die SQL geschaut und die einzige Queue die mir etwas anzeigt ist RAMcmdQueue
Dachte ich schau ich mal in RAMlogicCmdList
Hier hab ich 2 spalten cmd und cmdid1 die ich vermute mit cmd und cmdid aus RAMcmdQueue übereinstimmen sollten..., kann das jemand verifizieren bei mir gibts zwar viele einträge mit CMD=1 aber keiner dieser einträge hat cmdid1=3 oder schaue ich an der falschen stelle ?

[gaxy]

Stimmt Deine Systemzeit?

[Peterich]

Geht ca 6 sekunden vor der Windows Uhr.

[EDIT]

Ich hab jetzt mal weitergesucht - alle Logic seiten ausgeschaltet keine Besserung.
Ich hab jetzt herausgefunden das während des Startens scheinbar die edomiLive.archivKoData optimiert wird

kann man das Deaktivieren zum testen ob es daran liegt ?
in der Basisconfig hab ich auch schon die Automatische Reparatur ausgeschaltet bringt für diesen punkt allerdings nichts.

[givemeone]

Das ist mir aucb schon aufgefallen.
Da mich im Log rein Zahlenwerte interessieren, habe ich die edomiLive.archivKoData von varchar auf float geändert, ohne merklich Nebenwirkungen. Das beschleunigt auch die Anzeige von Plots immens, diese Tabelle würde deutlich kleiner, aber ich könnte mir vorstellen, dass es Christian bei dieser Tat den Magen umdreht ;-)

[Peterich]

So für mich konnte ich das Folgendermaßen lösen:

mysql
use edomiLive
create index Idx_1 on archivKoData(targetid, datetime);

nano /etc/my.cnf

[mysqld]
key_buffer_size=1024M
sort_buffer_size=1024M
read_buffer_size=128M
read_rnd_buffer_size=128M
myisam_sort_buffer_size=128M
join_buffer_size=128M
query_cache_limit=128M
query_cache_size=128M
query_cache_type=1
wait_timeout=28800
interactive_timeout=28800
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
thread_concurrency = 8
thread_cache_size = 8
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under a different user or group,
# customize your systemd unit file for mariadb according to the
# instructions in http://fedoraproject.org/wiki/Systemd

[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid

#
# include all files from the config directory
#
!includedir /etc/my.cnf.d

und in Edomi bei sämtlichen Archiven die speicherdauer auf Unendlich gestellt.

---

Letzeres bewirkte das der Start wirklich wesentlich schneller ist da das Archiv nicht mehr auf Löschungen überprüft wird (scheint zumindest für mich so).

Das erste hab ich auch hier aus dem Forum ich glaube von starwarsfan der Befehl dauerte ziemlich lange bei mir seit diesem gehen Diagramme aber Instant auf.

die Änderungen an der my.cnf sollen zur Beschleunigung führen ob das so ist ist mal dahingestellt das könnte man auch erstmal weglassen.

[saegefisch]

Große Datenarchive = lange Aktivierung (jedes Mal)

sinnvoll begrenzte Datenarchive (zb 1 Woche) = angemessene Aktivierungszeit (große Datenmengen/langzeit bei Bedarf auslagern -> influxDB)

keine Datenarchive (zb DEV-edomi-Instanz) = wenige Sekunden Aktivierungszeit

ein nur 1x tägliche Archiv-housekeeping (statt bei jeder Aktivierung) wurde schon gelegentlich bei Christian angefragt, zZ (noch?) nicht implementiert.

mit obiger Lösung (schöne Idee!) kann man das sicher umgehen, aber ich persönlich mag am Original nicht rumschrauben (muss man bei jedem Update nachziehen) und löse es mit sinnvoll ausgelegten Archiven und influxDB für alles andere.

[Peterich]

sinnvoll begrenzte Datenarchive (zb 1 Woche) = angemessene Aktivierungszeit (große Datenmengen/langzeit bei Bedarf auslagern -> influxDB)

Meine Archive bis auf Außentemperatur sind eigt. alle auf 1 Monat begrenzt gewesen.
Ich hab nur viele

ein nur 1x tägliche Archiv-housekeeping (statt bei jeder Aktivierung) wurde schon gelegentlich bei Christian angefragt, zZ (noch?) nicht implementiert.

Glaube das würde wirklich alles besser machen.
Mal abwarten vllt. kommt das

[NorbertB]

Große Datenarchive = lange Aktivierung (jedes Mal)

sinnvoll begrenzte Datenarchive (zb 1 Woche) = angemessene Aktivierungszeit (große Datenmengen/langzeit bei Bedarf auslagern -> influxDB)

Das würden viel (auch ich) sicher gerne machen, nur fehlen hier Datenbankkenntnisse.
saegefisch , vielleicht lässt Du Dich ja motivieren Dein Wissen zu teilen? 😉
https://knx-user-forum.de/forum/proj...orkshop-teil-4