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 <cpui...@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.bernem...@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. <mailing3...@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. <mailing3...@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.richte...@gmail.com>: >>> >>>> Moin, >>>> >>>> was ihr meint ist M.2 ;-) >>>> >>>> Grüße >>>> Frank >>>> >>>> Am 29.09.2017 07:59 schrieb "F. S." <mailing3...@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" <cpui...@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.bernem...@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é >>>>>> >>>>> >>> >>