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
Re: [vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository
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
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'
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 w3llschm...@gmail.com mailto:w3llschm...@gmail.com 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
Moin Heiko,
2014/1/9 Heiko Baumann h...@gmx.de
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
Erstmal sind Daten drin. Ob die für die Kanäle drin sind die bei Dir
langsam sind sieht man daran nicht.
2014/1/9 Heiko Baumann h...@gmx.de
...
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.
Die Timezone (Europe/Berlin) ist rauskommentiert - soll das so sein?
Eher nicht.
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?
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.
Woran könnte es liegen, dass die Performanceoptimierungen bei mir nicht
greifen?
S.o.
vg
Andreas
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 w3llschm...@gmail.com
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
Hi, die Anleitung hat funktioniert. Vielen Dank! Gruß René From: volkszaehler-dev-boun...@lists.volkszaehler.org [mailto:volkszaehler-dev-boun...@lists.volkszaehler.org] On Behalf Of Andreas Goetz Sent: Montag, 23. Dezember 2013 15:23 To: volkszaehler.org - users; volkszaehler.org Subject: [vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository 1. Installiert die Composer Paketverwaltung ... 2. Aktualisiert Eure Installation ... 3. Performanceoptimierung einschalten ... smime.p7s Description: S/MIME cryptographic signature
Re: [vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository
Moin, 2013/12/27 René Hézser r...@hezser.de Nach der Anleitung (also als Punkt 4) habe ich noch in der volkszaehler.conf.template.php $config['aggregation'] = true; gesetzt. Ist die Aggregation nur dann aktiv? Gruß René So isses. Sonst würde der Eintrag ja nicht soviel Sinn machen :/ Und er wirkt auch nur dann wenn die Tabelle befüllt wird... vg Andreas
Re: [vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository
2013/12/27 W3ll Schmidt w3llschm...@gmail.com Super Arbeit, läuft aum Raspi wie 'Schmidts Katze' !!! Das hört man doch gerne ;) Hat sich die Arbeit gelohnt :))
[vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository
Hallo Zusammen, die VZ Admins bzw. Committer arbeiten derzeit daran, die verschiedenen Patches zur Performanceoptimierung in das VZ Hauptrepository einzubringen. Leider muss dazu die bestehende VZ Infrastraktur einmalig einer Änderung unterzogen werden die nicht durch ein einfaches git pull zu beheben ist. Wenn Ihr in den nächsten Tagen also vorhaben solltet Eure VZ-Installation mal wieder auf den aktuellen Stand zu bringen beachtet bitte folgende Punkte um die Installation möglichst unterbrechungsfrei durchzuführen: 1. Installiert die Composer Paketverwaltung $ mkdir composer $ cd composer $ curl -sS https://getcomposer.org/installer | php $ sudo cp composer.phar /usr/local/bin/composer Windowsnutzer laden sich den Installer unter http://getcomposer.org/download/ herunter. Zum testen: composer self-update Wenn das erfolgreich funktioniert seid Ihr das das Git Update vorbereitet. 2. Aktualisiert Eure Installation Dafür macht ihr wie immer in Eurem VZ Verzeichnis ein git pull ACHTUNG: nach diesem Schritt ist die Middleware zunächst nicht mehr erreichbar da die Abhängigkeiten (Doctrine etc) nicht gefunden werden. Deshalb jetzt schnell die Abhängigkeiten installieren: composer install sollten Hinweise über veraltete Software kommen könnt Ihr auch noch ein optionales composer update nachschieben. Nach diesem Schritt ist die Middleware wieder erreichbar da die notwendigen Bibliotheken jetzt verfügbar sind. 3. Performanceoptimierung einschalten Wenn Ihr MySQL nutzt (in der neuen Version werden auch SQlite und PostgreSQL zusätzlich unterstützt, allerdings ohne Vollständigkeitsgarantie) dann könnt Ihr die neuen Features wiefolgt aktivieren. Hilfstabelle anlegen: php misc/tools/aggregate.php create Hilfstabelle befüllen: php misc/tools/aggregate.php -m full -l day -l hour run Und den Prozess für die Aktualisierung noch automatisien: crontab -e und die folgenden Zeilen hinzufügen: * 2 * * * /usr/bin/php aggregate.php -m delta -l day run 9 * * * * /usr/bin/php aggregate.php -m delta -l hour run Damit ist's dann getan- ab jetzt sollte Euer VZ rennen. Wir melden uns wieder an dieser Stelle wenn die Änderungen drin sind. Die Ungeduldigen finden bis dahin im dev Zweig unter github.com/andig/volkszaehler den aktuellen Stand zum spielen. Euch allen ein Frohes Fest, Schöne Bescherung und Viel Spass beim auspacken der Geschenke! Euer Andreas
