[vz-dev] Hoher CPU Load nach Neuinstallation

Mon Oct 2 11:43:53 CEST 2017

Indizes sind in der Tabelle data drin, einer kombiniert auf channel_id und
timestamp und noch einer auf channel_id alleine. Ich habe gerade auch noch
mal mit der SD gestartet, daran liegt es wohl nicht.

Gruß
André

Andreas Götz <cpuidle at gmail.com> schrieb am Mo., 2. Okt. 2017 um 09:56 Uhr:

> Schau mal bitte die explain plans an. Ich habe das Gefühl Dir fehlen die
> Indizes?
>
> Viele Grüße,
> Andreas
>
> Am 02.10.2017 um 09:42 schrieb Andre Bernemann <andre.bernemann at gmail.com
> >:
>
> Hallo,
>
> also die Last ohne VZ MW ist natürlich fast 0, so wie es sein sollte.
> Sobald die mysql DB aber angesprochen wird, geht der mysql Prozess nach
> oben:
>
> top - 09:28:59 up 7 days, 16:06,  1 user,  load average: 2.12, 1.81, 0.91
> Tasks: 140 total,   1 running, 139 sleeping,   0 stopped,   0 zombie
> %Cpu(s): 23.9 us,  2.2 sy,  0.0 ni, 67.0 id,  6.1 wa,  0.0 hi,  0.7 si,
> 0.0 st
> KiB Mem :   994236 total,    22936 free,   263024 used,   708276 buff/cache
> KiB Swap:        0 total,        0 free,        0 used.   660048 avail Mem
>
>   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
>  3685 mysql     20   0  675080 195168   5236 S  99.3 19.6 108:29.17 mysqld
>
> Ich hab auch das Slow Query Log mal bemüht, da habe ich dann teilweise 10
> Sekunden für ein einfaches Insert:
>
> # Query_time: 19.537992  Lock_time: 0.000294  Rows_sent: 0  Rows_examined:
> 0
> # Rows_affected: 1
> SET timestamp=1506276604;
> INSERT INTO data (channel_id, timestamp, value) VALUES
> (12,'1506276580000','525.83845872566');
>
> und (unglaubliche) 800 Sekunden für eine komplexere vz Query :
>
> # Query_time: 825.361587  Lock_time: 0.000829  Rows_sent: 684
> Rows_examined: 16190955
> # Rows_affected: 0
> SET timestamp=1506276040;
> SELECT MAX(agg.timestamp) AS timestamp, COALESCE( SUM(agg.val_by_time) /
> (MAX(agg.timestamp) - MIN(agg.prev_timestamp)), AVG(agg.value)) AS value,
> COUNT(agg.value) AS count FROM ( SELECT timestamp, value, value *
> (timestamp - @prev_timestamp) AS val_by_time, GREATEST(0,
> IF(@prev_timestamp = NULL, NULL, @prev_timestamp)) AS prev_timestamp,
> @prev_timestamp := timestamp FROM data CROSS JOIN (SELECT @prev_timestamp
> := NULL) AS vars WHERE channel_id='12'  AND timestamp >= '0' ORDER BY
> timestamp ) AS agg GROUP BY YEAR(FROM_UNIXTIME(timestamp/1000)),
> DAYOFYEAR(FROM_UNIXTIME(timestamp/1000)) ORDER BY timestamp ASC;
>
> Ja, es sind super viele Einträge in der DB, aber es lief vorher ja
> zufriedenstellend. Ich könnte mal versuchen, es wieder über die SD Karte
> laufen zu lassen, aber vom Grundsatz her hätte ich mit dem USB Stick eine
> bessere Performance erwartet als mit der SD Karte. Any ideas?
>
> Gruß
> André
>
>
>
>
>
>
> F. S. <mailing3000 at googlemail.com> schrieb am Fr., 29. Sep. 2017 um
> 12:11 Uhr:
>
>> hier noch meine Anwendung inkl. Powerbank-USV. Damit ist der RPi ziemlich
>> abgesichert:
>>
>> https://drive.google.com/file/d/0B6lNUASUD83URFBRRjZmNVFHczg/view
>> https://forum.unipi.technology/topic/62/power-supply-with-ups/4
>>
>> VG
>> Frank S.
>>
>> Am 29. September 2017 um 12:05 schrieb F. S. <mailing3000 at googlemail.com>
>> :
>>
>>> Moin,
>>> M2 SSD (Sata) ! nicht PCI-E !:
>>> Das sind die Steckmodule. Schau mal hier ganz unten.
>>> Es gibt da verschiedene Längen =>
>>> http://www.ryli.net/the-best-fastest-m-2-solid-state-drive-ssd/
>>>
>>> Ich hatte meinen Adapter bei Conrad für 18,- Eur geholt:
>>> http://www.conrad.com/ce/de/product/1337091/mSATA-SSD-Erweiterungs-Platine-fuer-den-Raspberry-Pi
>>> Die M2-SSD separat bestellen. Ich bin nicht mehr sicher, aber ich
>>> dachtem, den kleinsten Formfakter verwendet zu haben:
>>> https://geizhals.de/?cat=hdssd&sort=bew&xf=4832_4%7E4836_4
>>>
>>> VG
>>> Frank S.
>>>
>>> Am 29. September 2017 um 09:15 schrieb Frank Richter <
>>> frank.richter83 at gmail.com>:
>>>
>>>> Moin,
>>>>
>>>> was ihr meint ist M.2 ;-)
>>>>
>>>> Grüße
>>>> Frank
>>>>
>>>> Am 29.09.2017 07:59 schrieb "F. S." <mailing3000 at googlemail.com>:
>>>>
>>>>> SD-card Ersatz mit USB-Adapterplatine und M0-SSD funktioniert hier
>>>>> seit 1 Jahr auch bestens.
>>>>> Frank S.
>>>>>
>>>>> Am 29.09.2017 7:01 AM schrieb "Andreas Götz" <cpuidle at gmail.com>:
>>>>>
>>>>>> Erstmal würde ich die Last ohne vz diagnostizieren. Die sollte im
>>>>>> Ruhezustand etwa 0, nicht 1! Was sagt denn top wer- ohne vz- für die
>>>>>> Grundlast verantwortlich ist?
>>>>>>
>>>>>> Apropos SD: hab ich bei mir durch M0 SSD ersetzt mit Adapterplatine.
>>>>>>
>>>>>> Viele Grüße, Andreas
>>>>>>
>>>>>> > Am 28.09.2017 um 20:17 schrieb Andre Bernemann <
>>>>>> andre.bernemann at gmail.com>:
>>>>>> >
>>>>>> > Hallo zusammen,
>>>>>> >
>>>>>> > mein Thema ist ein wenig OT, aber vielleicht hat trotzdem jemand
>>>>>> eine Idee:
>>>>>> >
>>>>>> > Bei meinem rPi (2 Model B) ist leider mal wieder die SD Karte
>>>>>> abgeraucht und ich habe eine neue Installation aufgesetzt (stretch). Um
>>>>>> weniger Ausfälle zu haben, verwende ich die SD-Karte nun nur noch als
>>>>>> Bootpartition, den Rest habe ich auf einen USB Stick ausgelagert. Dann hab
>>>>>> ich nur noch die VZ MW installiert und die Datenbank wiederhergestellt. Der
>>>>>> vzlogger läuft auf einem anderen PI. Funktioniert soweit alles, nur
>>>>>> seltsamerweise schnellt die CPU-Auslastung des mysqld Prozesses in die Höhe
>>>>>> sobald die Datenbank über das FE angesprochen wird (100% CPU, Avg-Load ~3).
>>>>>> Auch ohne FE Nutzung ist der Load relativ hoch (~1). Bei der alten
>>>>>> Installation war das alles einwandfrei nahe 0.
>>>>>> >
>>>>>> > Kann das an der USB Auslagerung liegen? Hat einer etwas ähnliches
>>>>>> schon mal gehabt? Die Konfigurationen (mysql, vz, apache, ...) habe ich von
>>>>>> der alten Installation übernommen. Meine Datenbank ist mittlerweile
>>>>>> ziemlich groß und kann sicherlich optimiert werden, war aber vorher auch
>>>>>> unproblematisch, daher würde ich den Punkt zunächst ausschließen wollen.
>>>>>> >
>>>>>> > Besten Dank für Eure Ideen!
>>>>>> >
>>>>>> > Gruß
>>>>>> > André
>>>>>>
>>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20171002/b192acde/attachment.html>