Ankündigung

Einklappen
Keine Ankündigung bisher.

Item mit Zeitberechnung bspw für Verbrauchsauswertung als Systemitems bereitstellen

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Msinn
    antwortet
    Das hängt stark von der Anzahl History Werte und der Größe der Datenbank ab. Das könntest Du mit SmartHomeNG v1.7.2 evtl. entschärfen.
    Falls Du die Detaildaten nicht mehr benötigst, z.B. weil Du sie in Summen-Items zusammengerechnet hast, kannst Du sie Löschen lassen.

    Du kannst für solche Items das neue Attribut database_maxage (Anzahl Tage) setzen. Dann werden automatisch History Werte die älter sind gelöscht.

    Bitte beachten. Wenn Du bei einem solchen Item sehr viele History Werte hast, kann das database Plugin beim 1. Start nach dem setzen des Attributes viel Zeit/Rechenleistung benötigen um die große Menge alter Daten zu löschen. Im späteren Verlauf werden die raus-alternden Daten regelmäßig gelöscht, so dass das dann von der Zeit/Rechenleistung her unauffällig ist.

    Einen Kommentar schreiben:

  • kaiwerner
    Forums-Einsteiger

  • kaiwerner
    antwortet
    Ich habe mir in den Scheduler ein logging Ausgabe eingebaut, die mir sagt wie viele Aufgaben in der Queue sind, wenn diese größer der Anzahl der Worker ist.

    Code:
    2020-06-24 09:00:00 INFO lib.scheduler Needing more worker threads 8! (Queue size: 70)
    2020-06-24 09:00:00 INFO lib.scheduler Needing more worker threads 8! (Queue size: 70)
    2020-06-24 09:00:00 INFO lib.scheduler Adding worker thread. Total: 9
    2020-06-24 09:00:00 INFO lib.scheduler Adding worker thread. Total: 9
    2020-06-24 09:00:01 INFO lib.scheduler Needing more worker threads 9! (Queue size: 70)
    2020-06-24 09:00:01 INFO lib.scheduler Needing more worker threads 9! (Queue size: 70)
    2020-06-24 09:00:01 INFO lib.scheduler Needing more worker threads 9! (Queue size: 68)
    2020-06-24 09:00:01 INFO lib.scheduler Needing more worker threads 9! (Queue size: 68)
    2020-06-24 09:00:02 INFO lib.scheduler Needing more worker threads 9! (Queue size: 68)
    2020-06-24 09:00:02 INFO lib.scheduler Needing more worker threads 9! (Queue size: 68)
    2020-06-24 09:00:02 INFO lib.scheduler Needing more worker threads 9! (Queue size: 64)
    2020-06-24 09:00:02 INFO lib.scheduler Needing more worker threads 9! (Queue size: 64)
    2020-06-24 09:00:03 INFO lib.scheduler Needing more worker threads 9! (Queue size: 63)
    2020-06-24 09:00:03 INFO lib.scheduler Needing more worker threads 9! (Queue size: 63)
    2020-06-24 09:00:03 INFO lib.scheduler Needing more worker threads 9! (Queue size: 59)
    2020-06-24 09:00:03 INFO lib.scheduler Needing more worker threads 9! (Queue size: 59)
    2020-06-24 09:00:04 INFO lib.scheduler Needing more worker threads 9! (Queue size: 57)
    2020-06-24 09:00:04 INFO lib.scheduler Needing more worker threads 9! (Queue size: 57)
    2020-06-24 09:00:04 INFO lib.scheduler Needing more worker threads 9! (Queue size: 54)
    2020-06-24 09:00:04 INFO lib.scheduler Needing more worker threads 9! (Queue size: 54)
    2020-06-24 09:00:05 INFO lib.scheduler Needing more worker threads 9! (Queue size: 53)
    2020-06-24 09:00:05 INFO lib.scheduler Needing more worker threads 9! (Queue size: 53)
    2020-06-24 09:00:05 INFO lib.scheduler Needing more worker threads 9! (Queue size: 53)
    2020-06-24 09:00:05 INFO lib.scheduler Needing more worker threads 9! (Queue size: 53)
    2020-06-24 09:00:06 INFO lib.scheduler Needing more worker threads 9! (Queue size: 52)
    2020-06-24 09:00:06 INFO lib.scheduler Needing more worker threads 9! (Queue size: 52)
    2020-06-24 09:00:06 INFO lib.scheduler Needing more worker threads 9! (Queue size: 50)
    2020-06-24 09:00:06 INFO lib.scheduler Needing more worker threads 9! (Queue size: 50)
    2020-06-24 09:00:07 INFO lib.scheduler Needing more worker threads 9! (Queue size: 50)
    2020-06-24 09:00:07 INFO lib.scheduler Needing more worker threads 9! (Queue size: 50)
    2020-06-24 09:00:07 INFO lib.scheduler Needing more worker threads 9! (Queue size: 48)
    2020-06-24 09:00:07 INFO lib.scheduler Needing more worker threads 9! (Queue size: 48)
    2020-06-24 09:00:08 INFO lib.scheduler Needing more worker threads 9! (Queue size: 47)
    2020-06-24 09:00:08 INFO lib.scheduler Needing more worker threads 9! (Queue size: 47)
    2020-06-24 09:00:08 INFO lib.scheduler Needing more worker threads 9! (Queue size: 44)
    2020-06-24 09:00:08 INFO lib.scheduler Needing more worker threads 9! (Queue size: 44)
    2020-06-24 09:00:09 INFO lib.scheduler Needing more worker threads 9! (Queue size: 43)
    2020-06-24 09:00:09 INFO lib.scheduler Needing more worker threads 9! (Queue size: 43)
    2020-06-24 09:00:09 INFO lib.scheduler Needing more worker threads 9! (Queue size: 40)
    2020-06-24 09:00:09 INFO lib.scheduler Needing more worker threads 9! (Queue size: 40)
    2020-06-24 09:00:10 INFO lib.scheduler Needing more worker threads 9! (Queue size: 38)
    2020-06-24 09:00:10 INFO lib.scheduler Needing more worker threads 9! (Queue size: 38)
    2020-06-24 09:00:10 INFO lib.scheduler Needing more worker threads 9! (Queue size: 36)
    2020-06-24 09:00:10 INFO lib.scheduler Needing more worker threads 9! (Queue size: 36)
    2020-06-24 09:00:11 INFO lib.scheduler Needing more worker threads 9! (Queue size: 33)
    2020-06-24 09:00:11 INFO lib.scheduler Needing more worker threads 9! (Queue size: 33)
    2020-06-24 09:00:11 INFO lib.scheduler Needing more worker threads 9! (Queue size: 33)
    2020-06-24 09:00:11 INFO lib.scheduler Needing more worker threads 9! (Queue size: 33)
    2020-06-24 09:00:12 INFO lib.scheduler Needing more worker threads 9! (Queue size: 28)
    2020-06-24 09:00:12 INFO lib.scheduler Needing more worker threads 9! (Queue size: 28)
    2020-06-24 09:00:12 INFO lib.scheduler Needing more worker threads 9! (Queue size: 27)
    2020-06-24 09:00:12 INFO lib.scheduler Needing more worker threads 9! (Queue size: 27)
    2020-06-24 09:00:13 INFO lib.scheduler Needing more worker threads 9! (Queue size: 22)
    2020-06-24 09:00:13 INFO lib.scheduler Needing more worker threads 9! (Queue size: 22)
    2020-06-24 09:00:13 INFO lib.scheduler Needing more worker threads 9! (Queue size: 22)
    2020-06-24 09:00:13 INFO lib.scheduler Needing more worker threads 9! (Queue size: 22)
    2020-06-24 09:00:14 INFO lib.scheduler Needing more worker threads 9! (Queue size: 15)
    2020-06-24 09:00:14 INFO lib.scheduler Needing more worker threads 9! (Queue size: 15)
    2020-06-24 09:00:14 INFO lib.scheduler Needing more worker threads 9! (Queue size: 15)
    2020-06-24 09:00:14 INFO lib.scheduler Needing more worker threads 9! (Queue size: 15)
    2020-06-24 10:00:00 INFO lib.scheduler Needing more worker threads 9! (Queue size: 67)
    2020-06-24 10:00:00 INFO lib.scheduler Needing more worker threads 9! (Queue size: 67)
    2020-06-24 10:00:00 INFO lib.scheduler Adding worker thread. Total: 10
    2020-06-24 10:00:00 INFO lib.scheduler Adding worker thread. Total: 10
    2020-06-24 10:00:01 INFO lib.scheduler Needing more worker threads 10! (Queue size: 67)
    2020-06-24 10:00:01 INFO lib.scheduler Needing more worker threads 10! (Queue size: 67)
    2020-06-24 10:00:02 INFO lib.scheduler Needing more worker threads 10! (Queue size: 62)
    2020-06-24 10:00:02 INFO lib.scheduler Needing more worker threads 10! (Queue size: 62)
    2020-06-24 10:00:02 INFO lib.scheduler Needing more worker threads 10! (Queue size: 61)
    2020-06-24 10:00:02 INFO lib.scheduler Needing more worker threads 10! (Queue size: 61)
    2020-06-24 10:00:03 INFO lib.scheduler Needing more worker threads 10! (Queue size: 55)
    2020-06-24 10:00:03 INFO lib.scheduler Needing more worker threads 10! (Queue size: 55)
    2020-06-24 10:00:03 INFO lib.scheduler Needing more worker threads 10! (Queue size: 54)
    2020-06-24 10:00:03 INFO lib.scheduler Needing more worker threads 10! (Queue size: 54)
    2020-06-24 10:00:04 INFO lib.scheduler Needing more worker threads 10! (Queue size: 48)
    2020-06-24 10:00:04 INFO lib.scheduler Needing more worker threads 10! (Queue size: 48)
    2020-06-24 10:00:04 INFO lib.scheduler Needing more worker threads 10! (Queue size: 46)
    2020-06-24 10:00:04 INFO lib.scheduler Needing more worker threads 10! (Queue size: 46)
    2020-06-24 10:00:05 INFO lib.scheduler Needing more worker threads 10! (Queue size: 40)
    2020-06-24 10:00:05 INFO lib.scheduler Needing more worker threads 10! (Queue size: 40)
    2020-06-24 10:00:05 INFO lib.scheduler Needing more worker threads 10! (Queue size: 40)
    2020-06-24 10:00:05 INFO lib.scheduler Needing more worker threads 10! (Queue size: 40)
    2020-06-24 10:00:06 INFO lib.scheduler Needing more worker threads 10! (Queue size: 34)
    2020-06-24 10:00:06 INFO lib.scheduler Needing more worker threads 10! (Queue size: 34)
    2020-06-24 10:00:06 INFO lib.scheduler Needing more worker threads 10! (Queue size: 33)
    2020-06-24 10:00:06 INFO lib.scheduler Needing more worker threads 10! (Queue size: 33)
    2020-06-24 10:00:07 INFO lib.scheduler Needing more worker threads 10! (Queue size: 27)
    2020-06-24 10:00:07 INFO lib.scheduler Needing more worker threads 10! (Queue size: 27)
    2020-06-24 10:00:07 INFO lib.scheduler Needing more worker threads 10! (Queue size: 25)
    2020-06-24 10:00:07 INFO lib.scheduler Needing more worker threads 10! (Queue size: 25)
    2020-06-24 10:00:08 INFO lib.scheduler Needing more worker threads 10! (Queue size: 19)
    2020-06-24 10:00:08 INFO lib.scheduler Needing more worker threads 10! (Queue size: 19)
    2020-06-24 10:00:08 INFO lib.scheduler Needing more worker threads 10! (Queue size: 17)
    2020-06-24 10:00:08 INFO lib.scheduler Needing more worker threads 10! (Queue size: 17)
    2020-06-24 10:00:09 INFO lib.scheduler Needing more worker threads 10! (Queue size: 11)
    2020-06-24 10:00:09 INFO lib.scheduler Needing more worker threads 10! (Queue size: 11)
    Damit erklärt sich der Anstieg der Worker zum Stundenwechsel bis auf die besagten 70 Stück.

    Ich hab erstmal die restart_on_num_workers hoch gesetzt. Da werde ich wohl doch mal was umbauen müssen. Hätte nicht gedacht das die DB-Aufgaben so lange brauchen. Läuft ja bis zu 15 Sekunden.

    Danke für die Unterstützung!

    Einen Kommentar schreiben:


  • Msinn
    antwortet
    Du könntest auch noch statt eine Logik zu erstellen, mit den Item Attributen on_update bzw. oh_change arbeiten und Threads sparen.

    Du könntest ein Hilfsitem erzeugen, welches rechnet. Etwa so:

    Code:
    hilfsitem:
        contab: ...
        on_change:
          - <item1>=<eval Ausdruck>
          - <item2>=<eval Ausdruck>
          - <item3>=<eval Ausdruck>
    Damit würde nur ein Task für das hilfsitem erzeugt und per on_change würden die berechneten Werte in den ganzen anderen Items geschrieben.

    Einen Kommentar schreiben:


  • Msinn
    antwortet
    Woher soll SmartHomeNG wissen, dass bei Dir über 20 Threads gebraucht werden? Bei mir sind nach der Initialisierung nur 6 Worker-Threads aktiv und die Zahl steigt innerhalb der ersten 3-4 Tage auf das dann konstante Maxium von 11.

    Du siehst in dem Graphen auch, dass Du bei vollständiger Entzerrung der Laufzeiten nur um die 5 Worker Threads bräuchtest.

    Einen Kommentar schreiben:

  • kaiwerner
    Forums-Einsteiger

  • kaiwerner
    antwortet
    Danke für die ausführliche Erklärung .

    Das Verhalten sieht im Moment halt so aus:

    Threads.JPG
    Es könnten doch die ersten 20-30 Therads erzeugt werden, wenn sie benötigt werden. Alles was da über geht wird begrenzt.

    Aber klar es läuft bei vielen auf dünnerer Hardware und
    Zitat von Msinn Beitrag anzeigen
    Weil das in smarthome.py ursprünglich mal so definiert wurde
    ist auch ein Punkt.

    Danke nochmal!

    Einen Kommentar schreiben:


  • Msinn
    antwortet
    Zitat von kaiwerner Beitrag anzeigen
    Danke für den Tipp den Wert zu überschreiben.
    Nicht überschreiben, setzen. Der Wert ist in der smarthome.yaml normalerweise nicht gesetzt. Dann wird 30 angenommen.
    Zitat von kaiwerner Beitrag anzeigen
    Wo ich aber noch auf dem Schlauch sehe ist, warum nur alle 60 Sekunden ein neuer Worker erzeugt wird wenn er nötig ist.
    Zitat von kaiwerner Beitrag anzeigen
    Wo ich aber noch auf dem Schlauch sehe ist, warum nur alle 60 Sekunden ein neuer Worker erzeugt wird wenn er nötig ist.
    Zwei Antworten:
    1. Weil das in smarthome.py ursprünglich mal so definiert wurde
    2. Damit nicht eine hohe Zahl an Tasks die Anzahl der Worker-Threads instant ins unermessliche treibt. (Das Erzeugen eines Threads ist im Verhältnis ein sehr großer Rechen-/Resoucen Aufwand) und: Threads werden nicht wieder abgebaut, weil das nochmal ein hoher Aufwand wäre, und im Zweifelsfall dann doch wieder ein neuer Thread erzeugt werden müsste.

      Wenn Du gesetzt den (übertriebenen) Fall hättest, dass zur gleichen Zeit 1.000 Scheduler Tasks starten sollen die jeweils 1 bis 2 Millisekunden rechnen, würdest Du sonst 1.000 Threads erzeugen, und das obwohl die sequenzielle Abarbeitung der nur 1 bis 2 Sekunden benötigt. So lange würde das übrigens auch dauern wenn Du 1000 Worker-Threads hättest, da Python nur einen Core der CPU nutzt. Da käme sogar noch die Rechenzeit zur Erzeugung der 1000 Threads dazu. Außerdem würdest Du dann aufgrund des GIL (Global Interpreter Lock) von Python die Abarbeitung zum erliegen bringen, wenn Du nicht eine sehr schnelle CPU hast.

    Nachtrag: Threads sollen eine quasi-Parallelisierung ermöglichen. Das macht bei sehr kurz laufenden Tasks nur sehr begrenzt sinn, da dann der Verwaltungsoverhead einen großen Teil der quasi-Parallelisierung wieder auffrisst (oder sogar überkompensiert).
    Zuletzt geändert von Msinn; 23.06.2020, 15:10. Grund: Nachtrag

    Einen Kommentar schreiben:

  • kaiwerner
    Forums-Einsteiger

  • kaiwerner
    antwortet
    Danke für den Tipp den Wert zu überschreiben. Soweit habe ich wieder mal nicht gedacht. Läuft bei mir in einen VM. Da ist Luft nach oben.

    Werde mir die Sache mit einer Logik aber mal ansehen.
    Ich finde sehr übersichtlich, wenn crontab Definition an einem Item bzw. an einem Itemstruct ist. Das würde dann ja entfallen.

    Wo ich aber noch auf dem Schlauch sehe ist, warum nur alle 60 Sekunden ein neuer Worker erzeugt wird, wenn er benötig wird.
    Code:
    now = self.shtime.now()
      if self._runq.qsize() > len(self._workers):
        delta = now - self._last_worker
        if delta.seconds > self._worker_delta:
          if len(self._workers) < self._worker_max:
             self._add_worker()
    Was ist der Grund dafür? Um Spitzen auszugleichen?
    kaiwerner
    Forums-Einsteiger
    Zuletzt geändert von kaiwerner; 23.06.2020, 15:02.

    Einen Kommentar schreiben:


  • Msinn
    antwortet
    Ein Ansatzpunkt wäre, genau wie weiter oben in diesem Thread beschrieben, die Berechnungen in einem Task auszuführen (da die Berechnungen alle zeitgleich stattfinden sollen), statt für jede Berechnung
    - zu prüfen, ob ein Worker-Thread idle ist und falls ja einen Thread zu selektieren und aus der Liste der idle Threads zu entfernen
    - oder evtl. einen neuen Thread zu starten
    - den Worker-Thread aufzusetzen
    - die einzelne Berechnung durchzuführen
    - den Thread in die Liste der idle Threads aufzunehmen

    Die gesamten Berechnungen die zeitgleich ausgeführt werden sollen, könnte man in eine Logik packen und diese per crontab starten (das wäre dann im Idealfall 1 Thread statt 60). Das spart in Summe auch Rechenzeit, da das gesamte Worker-Handling nur 1 mal statt 60 mal durchgeführt werden muss.

    Zitat von kaiwerner Beitrag anzeigen
    Ich hatte vor den Änderungen immer so um die 60 Worker-Threads und keine Probleme damit. Diese haben sich genau wie jetzt, nach einem Neustart, einer nach dem anderen Aufgebaut. Aber halt da eingependelt.
    Eine andere (bewusst nicht groß dokumentierte) Möglichkeit könntest Du nutzen, da bei Deiner Hardwareausstattung und Task Beschaffenheit wie Du schreibst 60 Tasks kein Problem darstellen, ist es die Anzahl Worker-Threads bei der ein Restart ausgeführt wird zu erhöhen.

    Dazu kannst Du in ../etc/smarthome.yaml folgenden Eintrag vornehmen, um den Restart z.B. erst bei 45 Workern vorzunehmen:
    Code:
    restart_on_num_workers: 45

    Einen Kommentar schreiben:


  • bmx
    antwortet
    Zitat von kaiwerner Beitrag anzeigen
    In der Tasks werden auch nur DB-Abfragen ausgewertet, das sollte keine Ewigkeiten brauchen.
    Doch, genau das. Wenn die zeitgleich angestossen werden sollen und alle Datenbank Abfragen starten dann behindern sich die Abfragen unter Umständen schon gegenseitig...

    Einen Kommentar schreiben:

  • kaiwerner
    Forums-Einsteiger

  • kaiwerner
    antwortet
    Danke für die Erklärungen.

    ich kenne diese Probleme und Beiträge "Needing more worker threads..."

    Vor allem wollte ich Deine Schedule Commit's auf keinen Fall kritisieren.
    Ich hatte vor den Änderungen immer so um die 60 Worker-Threads und keine Probleme damit. Diese haben sich genau wie jetzt, nach einem Neustart, einer nach dem anderen Aufgebaut. Aber halt da eingependelt.

    Anfangs bin ich von einem Plugin-Problem ausgegangen. So wie das Verbindungsproblem bei HUE-Plugin. Doch Abhilfe schaft bei mir nur, die stündlichen Scheduler nicht zu starten.

    Ich habe auf meinem Testsystem folgende Logeinträge.

    smarthome-details.log:2020-06-23 00:00:00 INFO lib.scheduler Adding worker thread. Total: 20
    smarthome-details.log:2020-06-23 00:00:00 INFO lib.scheduler Adding worker thread. Total: 20
    smarthome-details.log:2020-06-23 01:00:00 INFO lib.scheduler Adding worker thread. Total: 21
    smarthome-details.log:2020-06-23 01:00:00 INFO lib.scheduler Adding worker thread. Total: 21
    smarthome-details.log:2020-06-23 02:00:00 INFO lib.scheduler Adding worker thread. Total: 22
    smarthome-details.log:2020-06-23 02:00:00 INFO lib.scheduler Adding worker thread. Total: 22
    smarthome-details.log:2020-06-23 03:00:00 INFO lib.scheduler Adding worker thread. Total: 23
    smarthome-details.log:2020-06-23 03:00:00 INFO lib.scheduler Adding worker thread. Total: 23
    smarthome-details.log:2020-06-23 04:00:01 INFO lib.scheduler Adding worker thread. Total: 24
    smarthome-details.log:2020-06-23 04:00:01 INFO lib.scheduler Adding worker thread. Total: 24
    smarthome-details.log:2020-06-23 04:56:23 INFO lib.scheduler Adding worker thread. Total: 25
    smarthome-details.log:2020-06-23 04:56:23 INFO lib.scheduler Adding worker thread. Total: 25
    smarthome-details.log:2020-06-23 05:00:00 INFO lib.scheduler Adding worker thread. Total: 26
    smarthome-details.log:2020-06-23 05:00:00 INFO lib.scheduler Adding worker thread. Total: 26
    smarthome-details.log:2020-06-23 06:00:00 INFO lib.scheduler Adding worker thread. Total: 27
    smarthome-details.log:2020-06-23 06:00:00 INFO lib.scheduler Adding worker thread. Total: 27
    smarthome-details.log:2020-06-23 07:00:00 INFO lib.scheduler Adding worker thread. Total: 28
    smarthome-details.log:2020-06-23 07:00:00 INFO lib.scheduler Adding worker thread. Total: 28
    smarthome-details.log:2020-06-23 08:00:00 INFO lib.scheduler Adding worker thread. Total: 29
    smarthome-details.log:2020-06-23 08:00:00 INFO lib.scheduler Adding worker thread. Total: 29
    smarthome-details.log:2020-06-23 09:00:00 INFO lib.scheduler Adding worker thread. Total: 30
    smarthome-details.log:2020-06-23 09:00:00 INFO lib.scheduler Adding worker thread. Total: 30
    Auffällig ist das es meist zum Stundenwechsel ist und danach sind die idle Threads immer eins mehr.
    In der Tasks werden auch nur DB-Abfragen ausgewertet, das sollte keine Ewigkeiten brauchen.

    Das Du für mich vielleicht noch einen Ansatzpunkt wie ich dem Problem zu leibe Rücken kann?

    Danke


    Einen Kommentar schreiben:


  • Msinn
    antwortet
    Zitat von kaiwerner Beitrag anzeigen
    die aktuellen 5 Worker
    Wenn Du aktuell nur 5 Worker hast, Tut Dein Scheduler nicht viel (oder fast nichts). Die Erhöhung der Anzahl Worker-Threads ist seit jeher (smarthome.py) implementiert. Ab 20 Worker-Threads wurde gewarnt, dass es evtl. zu Problemen kommen kann (und evtl. auch tut. Siehe diverse Threads hier im Forum dazu, z.B. zum HUE Plugin). Neu ist nur, dass ab 30 Threads neu gestartet wird, statt zu warten bis SmartHomeNG sich "festfräst" und nicht mehr reagiert.

    Zitat von kaiwerner Beitrag anzeigen
    Durch die Änderung von msinn lib.scheduler: Implemented restart of SmartHomeNG if number of worker… werden die _restart_on_num_workers (30 Stück) nach einem Tag erreicht und ein Neustart ausgeführt.
    falsch, sonst hättest Du bisher schon keine 5 Worker sondern Warnungen, dass Du die 20 Worker-Threads überschreitest.

    Zitat von kaiwerner Beitrag anzeigen
    Habe ich das richtig verstanden?
    zum Teil

    Zitat von kaiwerner Beitrag anzeigen
    Ist das so gewollt?
    Ja

    Zitat von kaiwerner Beitrag anzeigen
    Sind die ca. 70 Schedulern die zum Stundenwechsel triggern zuviel?
    Nein, es sei denn Du hast einen Raspi 1 o.Ä. im Einsatz und/oder Deine Tasks brauchen Ewigkeiten um ihre Berechnungen durchzuführen.

    Zitat von kaiwerner Beitrag anzeigen
    Wäre es nicht besser die Worker zu begrenzen und die Queue weiter abzuarbeiten, wenn wieder einer frei ist?
    Genau da passiert doch. Deshalb wird nur ein Worker-Thread je Minute erzeugt und nur, wenn keiner der existierenden Worker-Threads idle ist. (Das ist übrigens seit Urzeiten so).
    Du läufst also nur in Probleme, wenn Deine durch crontab ausgelösten Berechnungen jeweils länger als eine Minute benötigen.

    Einen Kommentar schreiben:

  • kaiwerner
    Forums-Einsteiger

  • kaiwerner
    antwortet
    Hallo zusammen,

    ich weiß nicht ob ich hier jetzt out of topic bin. Sorry.
    Ich benutze auch einige Berechnungen an Items die, ähnlich wie die Verbrauchsauswertung, mit crontabs stündlich und / oder tageweise getriggert werden.
    Wenn jetzt zum Stunden- oder Tageswechsel 60-70 Scheduler triggern reichen die aktuellen 5 Worker nicht aus und es wird ein neuer Worker erzeugt.
    Da die Abarbeitung der getriggerten Scheduler aber innerhalb der 60 Sekunden von _worker_delta erfolgt wird jede Stunde, bei erneuten triggern, ein weiterer Worker erzeugt.
    Durch die Änderung von msinn lib.scheduler: Implemented restart of SmartHomeNG if number of worker… werden die _restart_on_num_workers (30 Stück) nach einem Tag erreicht und ein Neustart ausgeführt.

    Habe ich das richtig verstanden? Ist das so gewollt? Sind die ca. 70 Schedulern die zum Stundenwechsel triggern zuviel? Wäre es nicht besser die Worker zu begrenzen und die Queue weiter abzuarbeiten, wenn wieder einer frei ist? Oder habe ich da was nicht durchschaut?

    Vielen Dank.

    Einen Kommentar schreiben:


  • Onkelandy
    antwortet
    Gemäß https://knx-user-forum.de/forum/supp...99#post1508399 ist es Vorwoche. Hab mir aber nicht übermäßig viel Gedanken dazu gemacht. Ansonsten
    Sisamiwe alles so wie du geschrieben hast. Ließe sich bestimmt noch optimieren.

    Msinn hat auch Recht, dass man die Wochenwerte immer eine Ebene weiter nach unten kopieren könnte. Selbes natürlich auch mit mit den anderen "minusX" Werten.
    Zuletzt geändert von Onkelandy; 15.06.2020, 23:22.

    Einen Kommentar schreiben:


  • Msinn
    antwortet
    Ohne das im Detail mitverfolgt zu haben. Eine Logik müsste eigentlich nur auf woche triggern und bei der Ausführung einfach die bisherigen Wochen-Werte auf die Vorwoche Items kopieren bevor sie ihre eigentlichen Berechnungen durchführt... oder habe ich die Diskussion misverstanden?

    Einen Kommentar schreiben:


  • Sisamiwe
    antwortet
    Zitat von Onkelandy Beitrag anzeigen
    Da nun aber auch andere Items ein "gestern" haben könnten, hab ich bei mir das Struct in ein Unteritem "wertehistorie" gesteckt. Dann muss man die relativen Itemangaben mit einem weiteren Punkt bestücken, also zB sh....db statt sh...db

    Wildcards funktionieren nicht wirklich, aber normale substring Vergleiche. Meine Logik sieht nun so aus, muss ich aber noch ne Zeit testen.
    Danke für den Vorschlag. Ich versuche das noch nachzuvollziehen, denke auch verstanden zu haben, wie es funktionieren soll. Aber so ganz bin ich noch nicht dabei.

    Dein Item sieht bspw so aus:
    Code:
    %YAML 1.1
    ---
    stromzaehler:
        bezug:
            energie:
                name: Wirkarbeit Bezug total
                type: num
                sml_obis: 1-0:1.8.0*255
                sml_prop: valueReal
                eval: round(value / 1000, 2)
                database: init
    
                wertehistorie:
                    struct: wertehistorie_total
    Richtig?

    Mit der Logik machst du folgendes:
    Zitat von Onkelandy Beitrag anzeigen
    if not hasattr(logic, 'all_items'): logic.all_items = items.return_items()
    Es wird für die Logik eine persistente Variable erstellt, in der alle Items sind.

    Zitat von Onkelandy Beitrag anzeigen
    for item in logic.all_items: if not "wertehistorie" in item.property.path: pass
    Wenn "wertehistorie" (= Name des Unteritems mit dem struct) nicht im Pfad des Items vorkommt, dann fertig.

    Zitat von Onkelandy Beitrag anzeigen
    elif sh.now().strftime("%H") == "0" and sh.now().strftime("%M") == "0" and ("wertehistorie.gestern" in item.property.path or "wertehistorie.vorwoche" in item.property.path): item(1)
    Wenn "wertehistorie" im Itempfad und Stunden und Minuten zur Zeit der Logikausführung = 0 und ("wertehistorie.gestern" oder "wertehistorie.vorwoche") im Itempfad, dann wird das Item auf "1" gesetzt, also getriggert.

    Ist meine Interpretation korrekt?
    Wenn ja, warum triggerst Du "vorwoche" um 0:00? das müsste doch "woche" sein, oder?

    Einen Kommentar schreiben:

Lädt...
X