Re: [vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository
Moin,
2014/1/9 Heiko Baumann h...@gmx.de
Am 09.01.2014 21:26, schrieb Andreas Goetz:
Hallo Heiko,...
PS.: Logging brauchst Du egtl auch nicht- dafür gibts ja debug=1 im
Querystring ;)
Hm, wie kann ich das dem Server beim Starten mit übergeben?
Davon war nicht die Rede. Mit Querystring meine ich das Ding im Browser in
der URL hinter dem Fragezeichen. Einfach bei der Abfrage mit angeben!!
(/etc/init.d/mysql start debug=1 oder wie? Nee funktioniert nicht. Aber
so: im laufenden Betrieb einfach eine mysql-shell aufmachen und dann SET
GLOBAL general_log = 'ON', danach dann mit ... 'OFF' wieder ausschalten).
Beim 2. Nachdenken- 11s für 180 Werte (=Tage) ist _viel_ zu langsam.
Kannst Du mal die Queries für diese eine Abfrage abschauen? Bei mir geht
sowas in 1sec...
Ok, was ich gemacht hab: startseite vz, erst mal alle Channels unsichtbar
gestellt, dann nur einen sichtbar gemacht. Logging an, auf Jahresansicht
geklickt, gewartet bis der Graph angezeigt wurde, dann logging aus. Ergibt
das angehängte Log.
Viel zu kompliziert. 1 Kanal, nur den Middlewarerequest anschauen. Im
Browser, mit debug=1. Dann schauen was/wo das wie lange dauert.
Ok, der aggregate-Teil dauert wohl nur 3 Sekunden, der Rest wird von
s0-Ereignissen erzeugt.
d.h. Dein Raspi ist von endlosen S0-Ereignnisse zugemüllt? Wieviele pro
Minute?
Also doch alles ok?
Es ist lngsam- aber anscheinend nicht Problem der Aggregation.
Kleine Anmerkung zu den s0-Ereignissen - ist aber andere Baustelle: im log
fällt mir auf, dass das sehr häufig vorkommt:
911 Query SELECT e0_.id AS id0, e0_.uuid AS uuid1,
e0_.type AS type2, p1_.id AS id3, p1_.pkey AS pkey4, p1_.value AS value5,
e0_.class AS class6, p1_.entity_id AS entity_id7 FROM entities e0_ LEFT
JOIN properties p1_ ON e0_.id = p1_.entity_id WHERE (e0_.uuid =
'90da22c0-f2dc-11e2-a59d-e9b55d71b128') AND e0_.class IN ('channel',
'aggregator') ORDER BY p1_.pkey ASC
911 Query START TRANSACTION
911 Query INSERT INTO data (timestamp, value,
channel_id) VALUES ('1389302896063', '1', 14)
911 Query UPDATE properties SET value = '1' WHERE id
= 71
911 Query UPDATE properties SET value = '1' WHERE id
= 69
911 Query UPDATE properties SET value = '1000' WHERE
id = 67
911 Query commit
Das ist offenbar ein s0-Eintrag (value=1 im channel 14, Stromzähler). Was
mich wundert: warum muss der aufwändige join vorher ausgeführt werden?
Liefert bei mir z.B.
+-+--+---+--
++-+-++
| id0 | uuid1| type2 | id3 | pkey4 |
value5 | class6 | entity_id7 |
+-+--+---+--
++-+-++
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 71 | active
| 1 | channel | 14 |
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 70 | color
| navy| channel | 14 |
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 69 | public
| 1 | channel | 14 |
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 67 | resolution
| 1000| channel | 14 |
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 72 | style
| steps | channel | 14 |
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 68 | title
| Strom-Ferienwohnung | channel | 14 |
+-+--+---+--
++-+-++
6 rows in set (0.00 sec)
Muss das wirklich vor jedem Insert sein?
Und danach werden _immer_ die Werte für resolution, active und public
geupdatet (Unnötig, sind die alten Werte)
Den Join braucht Doctrine, das scheint auch mit Query Cache nicht weg
optimierbar zu sein da es immer einen aktuellen Stand aus der DB haben
will, die Abfrage ist auch schnell.
Was mich wundert sind Property Updates denn diese sind wirklich völlig
sinnlos. War das auch mit alten VZ-Versionen (also noch vor Einführung
Composer mit Doctrine 2.0) schon so? Die würde ich gerne loswerden...
Da die Stromzähler ja mitunter heftig feuern (Wärmepumpe unter Last 4kWh,
PV-Wechselsrichter gern auch mal 12kWh), könnt ich mir vorstellen, dass das
ziemlich viel unnötige Queries auslöst.
@ Hendrik, liest du vielleicht mit? s0vz ist ja dein Baby, oder..? ;)
Da liegt m.E. das Grundproblem. s0vz scheint nicht wie vzlogger eine
eingebaute Datenaggregation zu haben bevor es an die Middleware geht. Das
Thema gabs auch in anderen Threads schon.
Aus meiner Sicht ist das das Hauptproblem für die Perfprobleme wenn s0
ordentlich Impulse liefert. Da müsste allerdigns der Autor ran, C ist nicht
meine Welt...
vg
Andrea
Re: [vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository
Hi Heiko,
schau doch mal ob Du mit diesem PR hier
https://github.com/volkszaehler/volkszaehler.org/pull/95 die überflüssigen
SQLs für die properties Tabelle loswerden kannst.
Löst aber nicht die (wichtigeren...) Probleme mit s0vz.
vg
Andreas
2014/1/10 Andreas Goetz cpui...@gmail.com
Moin,
2014/1/9 Heiko Baumann h...@gmx.de
Am 09.01.2014 21:26, schrieb Andreas Goetz:
Hallo Heiko,...
PS.: Logging brauchst Du egtl auch nicht- dafür gibts ja debug=1 im
Querystring ;)
Hm, wie kann ich das dem Server beim Starten mit übergeben?
Davon war nicht die Rede. Mit Querystring meine ich das Ding im Browser in
der URL hinter dem Fragezeichen. Einfach bei der Abfrage mit angeben!!
(/etc/init.d/mysql start debug=1 oder wie? Nee funktioniert nicht. Aber
so: im laufenden Betrieb einfach eine mysql-shell aufmachen und dann SET
GLOBAL general_log = 'ON', danach dann mit ... 'OFF' wieder ausschalten).
Beim 2. Nachdenken- 11s für 180 Werte (=Tage) ist _viel_ zu langsam.
Kannst Du mal die Queries für diese eine Abfrage abschauen? Bei mir geht
sowas in 1sec...
Ok, was ich gemacht hab: startseite vz, erst mal alle Channels unsichtbar
gestellt, dann nur einen sichtbar gemacht. Logging an, auf Jahresansicht
geklickt, gewartet bis der Graph angezeigt wurde, dann logging aus. Ergibt
das angehängte Log.
Viel zu kompliziert. 1 Kanal, nur den Middlewarerequest anschauen. Im
Browser, mit debug=1. Dann schauen was/wo das wie lange dauert.
Ok, der aggregate-Teil dauert wohl nur 3 Sekunden, der Rest wird von
s0-Ereignissen erzeugt.
d.h. Dein Raspi ist von endlosen S0-Ereignnisse zugemüllt? Wieviele pro
Minute?
Also doch alles ok?
Es ist lngsam- aber anscheinend nicht Problem der Aggregation.
Kleine Anmerkung zu den s0-Ereignissen - ist aber andere Baustelle: im
log fällt mir auf, dass das sehr häufig vorkommt:
911 Query SELECT e0_.id AS id0, e0_.uuid AS uuid1,
e0_.type AS type2, p1_.id AS id3, p1_.pkey AS pkey4, p1_.value AS value5,
e0_.class AS class6, p1_.entity_id AS entity_id7 FROM entities e0_ LEFT
JOIN properties p1_ ON e0_.id = p1_.entity_id WHERE (e0_.uuid =
'90da22c0-f2dc-11e2-a59d-e9b55d71b128') AND e0_.class IN ('channel',
'aggregator') ORDER BY p1_.pkey ASC
911 Query START TRANSACTION
911 Query INSERT INTO data (timestamp, value,
channel_id) VALUES ('1389302896063', '1', 14)
911 Query UPDATE properties SET value = '1' WHERE
id = 71
911 Query UPDATE properties SET value = '1' WHERE
id = 69
911 Query UPDATE properties SET value = '1000'
WHERE id = 67
911 Query commit
Das ist offenbar ein s0-Eintrag (value=1 im channel 14, Stromzähler).
Was mich wundert: warum muss der aufwändige join vorher ausgeführt werden?
Liefert bei mir z.B.
+-+--+---+--
++-+-++
| id0 | uuid1| type2 | id3 | pkey4
| value5 | class6 | entity_id7 |
+-+--+---+--
++-+-++
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 71 | active
| 1 | channel | 14 |
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 70 | color
| navy| channel | 14 |
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 69 | public
| 1 | channel | 14 |
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 67 | resolution
| 1000| channel | 14 |
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 72 | style
| steps | channel | 14 |
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 68 | title
| Strom-Ferienwohnung | channel | 14 |
+-+--+---+--
++-+-++
6 rows in set (0.00 sec)
Muss das wirklich vor jedem Insert sein?
Und danach werden _immer_ die Werte für resolution, active und public
geupdatet (Unnötig, sind die alten Werte)
Den Join braucht Doctrine, das scheint auch mit Query Cache nicht weg
optimierbar zu sein da es immer einen aktuellen Stand aus der DB haben
will, die Abfrage ist auch schnell.
Was mich wundert sind Property Updates denn diese sind wirklich völlig
sinnlos. War das auch mit alten VZ-Versionen (also noch vor Einführung
Composer mit Doctrine 2.0) schon so? Die würde ich gerne loswerden...
Da die Stromzähler ja mitunter heftig feuern (Wärmepumpe unter Last 4kWh,
PV-Wechselsrichter gern auch mal 12kWh), könnt ich mir vorstellen, dass das
ziemlich viel unnötige Queries auslöst.
@ Hendrik, liest du vielleicht mit? s0vz ist ja dein Baby, oder..? ;)
Da liegt m.E. das Grundproblem. s0vz scheint nicht
Re: [vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository
Guten Abend...
1 Kanal, nur den Middlewarerequest anschauen. Im Browser, mit
debug=1. Dann schauen was/wo das wie lange dauert.
Ok. Für einen Kanal sind ja offenbar 3 Queries nötig: von-Timestamp,
bis-Timestamp und dann die eigentlichen Werte.
Rattert gnadenlos schnell durch. Schmidts Katze ist ne Schildkröte im
Vergleich ;)
d.h. Dein Raspi ist von endlosen S0-Ereignnisse zugemüllt? Wieviele
pro Minute?
Ich fürchte ja. Attack of the killer s0-events. Ich hab leider einige
s0-Zähler: PV-Wechselrichter (erzeugt wohl am meisten), Wärmepumpe (ist
im Winter auch gut dabei, 20kWh am Tag?) und dann noch Stromzähler für
Ferienwohnung und Hauptwohnung. Kommt insgesamt schon einiges zusammen.
Es ist lngsam- aber anscheinend nicht Problem der Aggregation.
Zustimmung.
Kleine Anmerkung zu den s0-Ereignissen - ist aber andere Baustelle:
im log fällt mir auf, dass das sehr häufig vorkommt:
911 Query SELECT e0_.id AS id0, e0_.uuid AS
uuid1, e0_.type AS type2, p1_.id AS id3, p1_.pkey AS pkey4,
p1_.value AS value5, e0_.class AS class6, p1_.entity_id AS
entity_id7 FROM entities e0_ LEFT JOIN properties p1_ ON e0_.id =
p1_.entity_id WHERE (e0_.uuid =
'90da22c0-f2dc-11e2-a59d-e9b55d71b128') AND e0_.class IN ('channel',
'aggregator') ORDER BY p1_.pkey ASC
911 Query START TRANSACTION
911 Query INSERT INTO data (timestamp, value,
channel_id) VALUES ('1389302896063', '1', 14)
911 Query UPDATE properties SET value = '1'
WHERE id = 71
911 Query UPDATE properties SET value = '1'
WHERE id = 69
911 Query UPDATE properties SET value =
'1000' WHERE id = 67
911 Query commit
Den Join braucht Doctrine, das scheint auch mit Query Cache nicht weg
optimierbar zu sein da es immer einen aktuellen Stand aus der DB haben
will, die Abfrage ist auch schnell.
Ok.
Da liegt m.E. das Grundproblem. s0vz scheint nicht wie vzlogger eine
eingebaute Datenaggregation zu haben bevor es an die Middleware geht.
Das Thema gabs auch in anderen Threads schon.
Aus meiner Sicht ist das das Hauptproblem für die Perfprobleme wenn s0
ordentlich Impulse liefert. Da müsste allerdigns der Autor ran, C ist
nicht meine Welt...
Ja, und genau diese Situation habe ich, dass s0 ordentlich Last erzeugt.
Hndrik, kommst du mal eben bitte...? ;)
Ich hoff mal er liest mit und meldet sich, sonst werd ich ihn mal direkt
anmailen.
schau doch mal ob Du mit diesem PR hier
https://github.com/volkszaehler/volkszaehler.org/pull/95 die
überflüssigen SQLs für die properties Tabelle loswerden kannst.
Probier ich gern aus...ä... wenn du mir sagst, wie ich das mache?
Löst aber nicht die (wichtigeren...) Probleme mit s0vz.
Na jeder Fortschritt ist willkommen ;)
cu.. Heiko
