Re: [vz-dev] Performance Optimierung mysql
Hallo Rainer,
geht mir genau wie dir - ich hab den raspi jetzt erst ein paar Wochen
laufen, aber in Anbetracht der vielen Daten kann man wohl drauf warten,
bis die Sache langsam und langsamer wird.
Zu deinen Vorschlägen kann ich leider nichts beitragen, habe noch nichts
mit partitions gearbeitet - wäre aber mal ein netter Anfang. Alternativ
dazu werd ich wohl alle paar Monate die Daten komplett auf einen PC
ziehen und dort das "Langzeitarchiv" aufbauen, während im raspi dann
eben nur den aktuellen Teilbestand liegen.
Oder es findet sich noch eine elegantere Lösung...?
LG Heiko
da ich gerne meine Daten behalte, aber dennoch langsam
Performanceprobleme kommen sehe habe ich mir mal Gedanken gemacht, wie
man mysql noch etwas optimieren könnte.
Abgesehen vom Hauptspeicherverbrauch (der auf dem Raspi eh begrenzt
ist) kam ich auf folgende Ideen:
a) myisam vs innodb
MyIsam soll ja beim Lesen von Daten schneller sein als InnoDB. Hat da
jemand Zahlen, ob das wirklich relevant ist?
b) Partitionierung von Tabellen
Wenn man die Daten in Partitionen nach Monaten aufteilt, dann hat man
in dem Bereich in dem man häufig schaut nur wenig Daten. Ich dachte da
an:
PARTITION BY RANGE ( timestamp ) (
PARTITION p0 VALUES LESS THAN ( UNIX_TIMESTAMP('2013-01-01 00:00:00')
*1000 ),
PARTITION p1 VALUES LESS THAN ( UNIX_TIMESTAMP('2013-02-01 00:00:00')
*1000),
PARTITION p2 VALUES LESS THAN ( UNIX_TIMESTAMP('2013-03-01 00:00:00')
*1000 ),
usw. Damit sollten dann lediglich 1-2 Partitionen im Speicher liegen.
Die letzten 2 Monate wären dann detailliert performant abfragbar.
Hat damit jemand Erfahrungen?
Kommentare?
Gruss
Rainer
Re: [vz-dev] Fehler: vz und Temperaturen unter -10°
Am 08.12.2013 13:44, schrieb Andreas Goetz: Versuch bitte erstmal rauszufinden welche Werte der Sensor eigentlich liefert- ein Fehler der Middleware ist hier ziemlich unwahrscheinlich. Hi Andi, du meinst also dass der Sensor bei < -10° falsche Werte liefert? Hm, dann müsst ich den Außenfühler mal auswechseln. In den Specs steht halt "Temperaturbereich -55° bis +125°C". Wär dann ja schon arg bitter wenn er bei exakt -10,0°C streikt... Hab ich noch eine andere Möglichkeit, die gelieferten Werte außerhalb der DB auszulesen und nachzuprüfen? Danke! LG Heiko 2013/12/8 Heiko Baumann mailto:h...@gmx.de>> Hallo zusammen, nachdem es jetzt bei uns leider ziemlich kalt wird, ist mir ein Darstellungsproblem im Frontend aufgefallen. Fällt die Temperatur unter -10°, werden z.B. "-1,5°" anstelle von "-11.5°" angezeigt (siehe Screenshot). Erst dachte ich, das wäre ein Fehler im Frontend, aber leider stehen auch die Werte falsch in der DB: mysql> select *, from_unixtime(timestamp/1000) from data where timestamp>1385517696591 and timestamp<1385517998592 and channel_id=10; +-++---+---+---+ | id | channel_id | timestamp | value | from_unixtime(timestamp/1000) | +-++---+---+---+ | 6816491 | 10 | 1385517696592 | -9.94 | 2013-11-27 03:01:37 | | 6816638 | 10 | 1385517779731 |-1 | 2013-11-27 03:03:00 | | 6816772 | 10 | 1385517855444 | -1.01 | 2013-11-27 03:04:15 | | 6816916 | 10 | 1385517937645 | -1.02 | 2013-11-27 03:05:38 | +-++---+---+---+ 4 rows in set (0.00 sec) Datensatz 6816638 müsste eigentlich "-10" als Value haben, 6816772 "-10.1" usw. Die Temperatursensoren gehen lt. Hersteller bis -55°C. Woran könnte das liegen? Ich verwende einen raspi mit Udos Hardware und Henriks 1wirevz. Danke und schöne Grüße Heiko
Re: [vz-dev] Fehler: vz und Temperaturen unter -10°
Am 14.12.2013 19:49, schrieb Udo1: Am 08.12.2013 13:34, schrieb Heiko Baumann: Woran könnte das liegen? Ich verwende einen raspi mit Udos Hardware und Henriks 1wirevz. Es liegt an Henriks 1wirevz. Speziell an der 1wirevz.c Habe mal meinen Sohnemann gebeten das zu fixen. Jetzt tuts bis -43°C (tiefer ging das Kältespray nicht ) :) Die 1wirevz.c und eine binary dazu häng ich mal an. Wenns die binary nicht tut, bitte die .c selbst compilieren. @Henrik: Bitte die Änderung in deine 1wirevz.c einfließen lassen. Mangels Kältespray warte ich die letzte Zeit, bis es wieder richtig kalt wird, aktuell Fehlanzeige. Aber Dank Udo ist wohl klar, dass es nicht an meinem Sensor liegt, da bin ich beruhigt. @ Henrik: kannst du bitte nochmal kurz schreiben, wie ich ein git update mit der gefixten Version bekomme? Danke!
Re: [vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository
So, inzwischen hatte ich endlich auch mal Zeit zum Probieren. Da ich
beim Backup offenbar mein Image auf der Karte zerschossen hab, musste
ich ein komplett neues System aufsetzen und hab jetzt mal das fertige
Image von Rainer probiert (da sind leider noch ein paar "Probleme" beim
s0vz und 1wirevz drin). Läuft aber jetzt jedenfalls wieder.
Konnte die Anleitung wie beschrieben nachvollziehen, lief gut durch.
Einzige Unklarheit: es steht öfters, dass man
/var/www/volkszaehler.org/etc/volkszaehler.conf.php nach
/etc/volkszaehler.conf.php kopieren soll. Kopieren oder verlinken? Im
Image sind die anderen conf-Dateien (1wirevz.cfg, s0vz.cfg) verlinkt.
Jedenfalls steht in volkszaehler.conf.php was von "administration
credentials" - ich gehe mal davon aus, dass ich für den user root mein
login-PW eintrage.
Die Timezone ("Europe/Berlin") ist rauskommentiert - soll das so sein?
Tja und dann kommt also noch als letzte Zeile
$config['aggregation']=true;
mit rein. Speichern, aber selbst nach reboot kann ich keine
Beschleunigung erkennen.
Die aggregate-Tabellen wurden erzeugt und sind befüllt, hat bei 500MB
data doch ganz schön gedauert.
Woran könnte es liegen, dass die Performanceoptimierungen bei mir nicht
greifen?
Danke!
LG Heiko
PS: Habe im wiki mal die hier weiter oben im Thread genannten Schritte
ergänzt, weil das aktuelle Image ja noch vom August ist...
Am 27.12.2013 18:22, schrieb Andreas Goetz:
2013/12/27 W3ll Schmidt >
Super Arbeit, läuft aum Raspi wie 'Schmidts Katze' !!!
Das hört man doch gerne ;) Hat sich die Arbeit gelohnt :))
Re: [vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository
Ergänzung:
http://vz/middleware.php/capabilities/database.json
liefert mir:
{"version":"0.3","capabilities":{"database":{"data_rows":6420892,"data_size":592134144,"aggregation_enabled":1,"aggregation_rows":58082,"aggregation_ratio":110.549}}}
... also ist das doch offenbar richtig aktiviert?
Re: [vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository
Hi Andi...
http://vz/middleware.php/capabilities/database.json
liefert mir:
{"version":"0.3","capabilities":{"database":{"data_rows":6420892,"data_size":592134144,"aggregation_enabled":1,"aggregation_rows":58082,"aggregation_ratio":110.549}}}
... also ist das doch offenbar richtig aktiviert
Erstmal sind Daten drin. Ob die für die Kanäle drin sind die bei Dir
"langsam" sind sieht man daran nicht.
|select *, from_unixtime(timestamp/1000) from aggregate order by channel_id,
timestamp
|
Untitled zeigt mir, dass für *alle* channels stündlich ein Wert
vorhanden ist. Zudem gibts je einen Tageswert (type=3 nehme ich an).
Jedenfalls steht in volkszaehler.conf.php was von "administration
credentials" - ich gehe mal davon aus, dass ich für den user root
mein login-PW eintrage.
Ganz sicher nicht?! Da kommt ein DB-User mit CREATE/DROP Privilegien
rein falls Dein normaler DB-User die nicht hat.
Hm, ich hab den Standarduser nicht geändert, also lass ich das
default-PW drin, ok. Diese Geschichte ist mir auch erst gestern ganz
spät nachts aufgefallen, da hab ich aggregate-Tabelle schon längst
erzeugt. Habs gerade nochmal getestet, hast recht: mit meinem
root-shell-PW gibts nen "access denied for user root..." Fehler. Klappt
jetzt wieder:
pi@BauratPi ~ $ php /var/www/volkszaehler.org/misc/tools/aggregate.php
-m full -l day -l hour run
Performing 'full' aggregation on 'day' level.
Updated 3999 rows.
Performing 'full' aggregation on 'hour' level.
Updated 83685 rows.
Die Timezone ("Europe/Berlin") ist rauskommentiert - soll das so sein?
Eher nicht.
Ok, also Kommmentare raus. Done.
Tja und dann kommt also noch als letzte Zeile
$config['aggregation']=true;
mit rein. Speichern, aber selbst nach reboot kann ich keine
Beschleunigung erkennen.
Reboot ist nicht nötig. Woran machst Du "keine Beschleunigung" das
fest? Bestimmte Abfrage? Nutzung des Frontends?
Ja, Nutzung des Frontends. Bei mir dauert nach wie vor eine Tagesabfrage
ca. 10 Sekunden, für einen Monat ca. 80 Sekunden, da hat sich gar nichts
geändert (Zeitangaben bei Ansicht mit allen 19 Channels).
Die aggregate-Tabellen wurden erzeugt und sind befüllt, hat bei
500MB data doch ganz schön gedauert.
Macht nix. Für Deltabefüllung gibts ja dann den entsprechenden Modus
womit's auch fix geht.
Klar, kein Thema. Nur hab ich mich jetzt auf Schmidts Katze gefreut,
aber die mag nicht ;)
Woran könnte es liegen, dass die Performanceoptimierungen bei mir
nicht greifen?
S.o.
...h leider wohl eher nicht. Menno, ich will aber die Katze
rennen sehen... wie kann ich dem Fehler auf die Schliche kommen?
Bin jetzt echt am Grübeln - vielleicht läuft die Optimierung ja doch
schon? hmmm... ahhh.. moment, ich schau einfach mal ins mysql.log.
Tatsächlich: da wird fleissig auf die aggregate-Tabelle zugegriffen:
140109 20:37:15 70465 Connect vz@localhost on volkszaehler
70465 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 =
'9a7ed6c0-f2dc-11e2-b13e-b9abb50897a8') AND e0_.class IN ('channel',
'aggregator') ORDER BY p1_.pkey ASC
70465 Query SELECT MIN(timestamp) FROM (SELECT
timestamp FROM data WHERE channel_id='15' AND timestamp<'1389209549459'
ORDER BY timestamp DESC LIMIT 2) t
70465 Query SELECT MAX(timestamp) FROM (SELECT
timestamp FROM data WHERE channel_id='15' AND timestamp>'1389295949459'
ORDER BY timestamp ASC LIMIT 2) t
70465 Query SELECT aggregate.type,
COUNT(aggregate.id) AS count FROM aggregate INNER JOIN entities ON
aggregate.channel_id = entities.id WHERE uuid =
'9a7ed6c0-f2dc-11e2-b13e-b9abb50897a8' GROUP BY type HAVING count > 0
ORDER BY type DESC
70465 Query SELECT
UNIX_TIMESTAMP(FROM_UNIXTIME(MIN(timestamp) / 1000, "%Y-%m-%d")) * 1000
FROM aggregate WHERE channel_id='15' AND type='3' AND
timestamp>='1388227905662'
70465 Query SELECT
UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(MAX(timestamp) / 1000,
"%Y-%m-%d"), INTERVAL 1 day)) * 1000 FROM aggregate WHERE
channel_id='15' AND type='3' AND timestamp<'1389296017384'
70465 Query SELECT SUM(count) FROM (SELECT COUNT(1)
AS count FROM data WHERE channel_id = '15' AND ( timestamp >=
'1388227905662' AND timestamp < '138818520' OR timestamp >=
'138827160' AND timestamp <= '1389296017384') UNION SELECT
SUM(count) AS count FROM aggregate WHERE channel_id = '15' AND type =
'3' AND timestamp >= '138818520' AND timestamp < '138827160') AS agg
...also alles richtig und muss damit leben, dass Schmidts Katze bei mir
nicht mag...?
Danke...!
LG Heiko
Am 27.12.2013 18:22, schrieb Andreas Goetz:
2013/12/27 W3ll Schmidt mailto
Re: [vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository
Bin jetzt echt am Grübeln - vielleicht läuft die Optimierung ja doch
schon? hmmm... ahhh.. moment, ich schau einfach mal ins mysql.log.
Tatsächlich: da wird fleissig auf die aggregate-Tabelle zugegriffen:
140109 20:37:15 70465 Connect vz@localhost on volkszaehler
70465 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 = '9a7ed6c0-f2dc-11e2-b13e-b9abb50897a8') AND e0_.class IN
('channel', 'aggregator') ORDER BY p1_.pkey ASC
70465 Query SELECT MIN(timestamp) FROM (SELECT
timestamp FROM data WHERE channel_id='15' AND timestamp<'1389209549459'
ORDER BY timestamp DESC LIMIT 2) t
70465 Query SELECT MAX(timestamp) FROM (SELECT
timestamp FROM data WHERE channel_id='15' AND
timestamp>'1389295949459' ORDER BY timestamp ASC LIMIT 2) t
70465 Query SELECT aggregate.type,
COUNT(aggregate.id) AS count FROM aggregate INNER JOIN entities ON
aggregate.channel_id = entities.id WHERE uuid =
'9a7ed6c0-f2dc-11e2-b13e-b9abb50897a8' GROUP BY type HAVING count > 0
ORDER BY type DESC
70465 Query SELECT
UNIX_TIMESTAMP(FROM_UNIXTIME(MIN(timestamp) / 1000, "%Y-%m-%d")) *
1000 FROM aggregate WHERE channel_id='15' AND type='3' AND
timestamp>='1388227905662'
70465 Query SELECT
UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(MAX(timestamp) / 1000,
"%Y-%m-%d"), INTERVAL 1 day)) * 1000 FROM aggregate WHERE
channel_id='15' AND type='3' AND timestamp<'1389296017384'
70465 Query SELECT SUM(count) FROM (SELECT
COUNT(1) AS count FROM data WHERE channel_id = '15' AND ( timestamp >=
'1388227905662' AND timestamp < '138818520' OR timestamp >=
'138827160' AND timestamp <= '1389296017384') UNION SELECT
SUM(count) AS count FROM aggregate WHERE channel_id = '15' AND type =
'3' AND timestamp >= '138818520' AND timestamp < '138827160')
AS agg
...also alles richtig und muss damit leben, dass Schmidts Katze bei
mir nicht mag...?
... das war dann wohl auch ein Hauptgrund für die Lahmheit: jetzt hab
ich das mysql-logging abgedreht, und siehe da... miau ;)
Das Logging kostet einfach zu viel Performance auf der kleinen Kiste...
Also: Logging zugedreht... tata 11 Sek. für die Jahresansicht
eines Temperatur-Channels (allerdings nur Werte aus dem 2. Halbjahr) -
das ist cool..
Sieht gut aus, vielen Dank!!
Schönen Abend...
Heiko
Re: [vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository
Am 09.01.2014 21:26, schrieb Andreas Goetz:
Hallo Heiko,
jetzt hatte ich extra den Schlepptop hochgefahren um Dich mit
Diagnosetipps zu versorgen und schon rennt die Mieze?! Aber lieber so
als anders ;)
Sorry und Danke dir für deine Arbeit, sieht top aus!
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?
(/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.
Ok, der aggregate-Teil dauert wohl nur 3 Sekunden, der Rest wird von
s0-Ereignissen erzeugt.
Also doch alles ok?
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)
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..? ;)
Denke also dass alles passt. Werds mal beobachten wie sich die Zeiten
und Zahlen verhalten...
DANKE und ne gute Nacht :)
Heiko
/usr/sbin/mysqld, Version: 5.5.33-0+wheezy1 ((Debian)). started with:
Tcp port: 3306 Unix socket: /var/run/mysqld/mysqld.sock
Time Id CommandArgument
140109 22:45:36 1242 Connect vz@localhost on volkszaehler
1242 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 =
'37e34a40-f2dc-11e2-a9f5-617f327e9a54') AND e0_.class IN ('channel',
'aggregator') ORDER BY p1_.pkey ASC
1242 Query SELECT MIN(timestamp) FROM (SELECT timestamp
FROM data WHERE channel_id='7' AND timestamp<'1357767914445' ORDER BY timestamp
DESC LIMIT 2) t
1242 Query SELECT MAX(timestamp) FROM (SELECT timestamp
FROM data WHERE channel_id=
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
[vz-dev] s0vz: Überflüssige Updates bei jedem Insert?
Hallo zusammen,
beim Installieren der neuen aggregate-Tabelle von Andi bin ich mehr oder
weniger zufällig beim Betrachten der mysql-logs darauf gestoßen, dass
jedes s0-Event neben dem eigentlichen Insert offenbar immer auch einen
join und drei Updates ausführt:
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? Andi hat sich im Originalthread
ja schon dazu geäußert:
"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, soll mir recht sein.
Aber danach werden _immer_ die Werte für resolution, active und public
"geupdatet" (Unnötig, sind die alten Werte)
-> das sind drei sinnlose Updates pro s0-insert.
Da die s0-Stromzähler ja mitunter heftig feuern (Wärmepumpe unter Last
4kWh, PV-Wechselsrichter gern auch mal 12kWh, zudem zwei
Geschoss-Stromzähler), könnt ich mir vorstellen, dass das ziemlich viel
unnötige Queries auslöst. Da kommt insgesamt schon einiges zusammen -
und wenn zu jedem Insert eines neuen Werts drei überflüssige Updates
kommen, ist mir klar, warum meine kleine Kiste etwas schwächelt...
Frage deswegen: Ist die Problematik bekannt? Kann das optimiert werden?
Vielen Dank und schöne Grüße!
Heiko
Re: [vz-dev] s0vz: Überflüssige Updates bei jedem Insert?
Hm. Ich hab vorhin mit git pull meinen vz geupdatet:
pi@BauratPi /var/www/volkszaehler.org $ sudo git pull
remote: Counting objects: 73, done.
remote: Compressing objects: 100% (70/70), done.
remote: Total 73 (delta 29), reused 34 (delta 3)
Unpacking objects: 100% (73/73), done.
From git://github.com/volkszaehler/volkszaehler.org
ec0c82d..ba113f6 master -> origin/master
Updating ec0c82d..ba113f6
Fast-forward
.../Interpreter/CounterInterpreter.php | 27 ++
lib/Volkszaehler/Interpreter/MeterInterpreter.php |3 +-
.../Interpreter/SQL/MySQLAggregateOptimizer.php| 90
+++-
lib/Volkszaehler/Interpreter/SQL/SQLOptimizer.php |3 +-
lib/Volkszaehler/Interpreter/SensorInterpreter.php |3 +-
lib/Volkszaehler/Model/Property.php| 13 ++-
lib/Volkszaehler/View/CSV.php | 52 +++
lib/Volkszaehler/View/JSON.php | 32 ++-
lib/Volkszaehler/View/JpGraph.php |8 +-
lib/Volkszaehler/View/XML.php | 80
++---
misc/tools/vzclient| 16 ++--
test/Tests/DataCounterTest.php |2 +-
test/Tests/DataMeterTest.php |2 +-
13 files changed, 135 insertions(+), 196 deletions(-)
- damit sollten doch alle updates drin sein, oder?
Im mysql-log gehts aber nach wie vor extrem wüst zu:
17345 Connect vz@localhost on volkszaehler
17345 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 =
'ae9d1b00-f2f5-11e2-8a1f-0dad1c039958') AND e0_.class IN ('channel',
'aggregator') ORDER BY p1_.pkey ASC
140112 22:33:47 17345 Query START TRANSACTION
17345 Query INSERT INTO data (timestamp, value,
channel_id) VALUES ('1389562426842', '1', 16)
17345 Query UPDATE properties SET value = '1' WHERE
id = 83
17345 Query UPDATE properties SET value = '1' WHERE
id = 81
17345 Query UPDATE properties SET value = '360'
WHERE id = 79
17345 Query commit
17345 Quit
Insofern also alles beim alten. Wie krieg ich die neueste Version?
Danke und gute Nacht :)
Heiko
Am 12.01.2014 22:25, schrieb Andreas Götz:
...und ist auch schon behoben?!
Am 12.01.2014 um 22:15 schrieb W3ll Schmidt >:
Hi Heiko,
das hat aber nichts mit *S0VZ* zu tun, der Deamon macht keine
Datenbankzugriffe ...
Re: [vz-dev] s0vz: Überflüssige Updates bei jedem Insert?
Hi Andi
Ja- Commit 8ac2c5039273b590aec2a9890f87400c08b949a8 liegt dazwischen.
Ich kann's nicht mehr nachvollziehen:
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 = ?) AND e0_.class IN
('channel', 'aggregator') ORDER BY p1_.pkey ASC
START TRANSACTION
INSERT INTO data (timestamp, value, channel_id) VALUES (?, ?, ?)
COMMIT
Bist Du sicher dass der Code den Du siehst auch wirklich der ist der
ausgeführt wird?
Ich bin sicher, dass das aktueller Code ist, ja. Zur Sicherheit habe
ich gerade eben nochmal kurz mitgeloggt:
/usr/sbin/mysqld, Version: 5.5.33-0+wheezy1 ((Debian)). started with:
Tcp port: 3306 Unix socket: /var/run/mysqld/mysqld.sock
Time Id CommandArgument
140113 *20:16:29 *118183 Connect vz@localhost on volkszaehler
118183 QuerySELECT 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 =
'89277390-f2dc-11e2-94d6-9984a2fec1dc') AND e0_.class IN ('channel',
'aggregator') ORDER BY p1_.pkey ASC
118183 QuerySTART TRANSACTION
118183 QueryINSERT INTO data (timestamp, value,
channel_id) VALUES ('1389640589168', '1', 13)
118183 QueryUPDATE properties SET value = '1' WHERE
id = 65
118183 QueryUPDATE properties SET value = '1' WHERE
id = 63
118183 QueryUPDATE properties SET value = '1000'
WHERE id = 61
118183 Querycommit
118183 Quit
140113 20:16:43 118184 Connect vz@localhost on volkszaehler
118184 QuerySELECT 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 =
'267f2810-f2dc-11e2-8d7c-cb14f79472e0') AND e0_.class IN ('channel',
'aggregator') ORDER BY p1_.pkey ASC
118184 QuerySTART TRANSACTION
118184 QueryINSERT INTO data (timestamp, value,
channel_id) VALUES ('1389640603905', '3.81', 6)
118184 QueryUPDATE properties SET value = '1' WHERE
id = 28
118184 QueryUPDATE properties SET value = '1' WHERE
id = 26
118184 Querycommit
118184 Quit
140113 20:16:44 118185 Connect vz@localhost on volkszaehler
118185 QuerySELECT 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 =
'c80251e0-f2db-11e2-8178-ef2453dba49c') AND e0_.class IN ('channel',
'aggregator') ORDER BY p1_.pkey ASC
118185 QuerySTART TRANSACTION
140113 20:16:45 118185 QueryINSERT INTO data (timestamp, value,
channel_id) VALUES ('1389640604969', '3.62', 1)
118185 QueryUPDATE properties SET value = '1' WHERE
id = 2
118185 Querycommit
118185 Quit
140113 *20:16:46 *118075 QuerySET GLOBAL general_log = 'OFF'
Insofern würde ich schon sagen, dass die updates immer noch heftig
einprasseln...
