Re: [vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository

2014-01-09 Diskussionsfäden 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 ;)

Viel Spass mit dem Tier,
Andreas

PS.: Logging brauchst Du egtl auch nicht- dafür gibts ja debug=1 im
Querystring ;)



2014/1/9 Heiko Baumann h...@gmx.de



 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

2014-01-09 Diskussionsfäden Heiko Baumann 

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='7'