Auslastung des eigenen Segments ansehen (reloaded)

[MartinP_Do]

Ich habe den CableLoad Monitor reaktiviert. Leider plottet er derzeit Lückenhaft.

Kann es sein, dass der Raspberry Pi B+ nicht "hinterherkommt", und für das Rendern der Grafiken zu lange braucht?

Alle 10 min ca 2 min Sendepause



Das ist der Aufruf des Skriptes:

sh CableLoadMonitor -t /var/www/html -d 1 -r 604800 -f 546:554:562:570:578:586:594:602:618:626:634:642:650:658:666:674:682:690:698:706:746:754:762:770 -i

Und hier einen Teil des Loggings

{ LD_PRELOAD=/opt/lib/libmediaclient.so timeout 10 dvbtune -c 0 -f 546000000 -s 6952 -qam 256; LD_PRELOAD=/opt/lib/libmediaclient.so timeout 1 dvbsnoop -adapter 0 -s bandwidth 8190 -n 80000; } 2>&1
## PID: 8190 (0x1ffe) bad/total packets: 0/18850 (= 0.0%) Avrg: 30064.051 kbit/s 30064
CMD: /bin/bash -c 'rrdtool update /home/pi/docsis-cable-load-monitor/CableLoadMonitor.rrd N:30064000:27817000:25200000:27347000:22759000:25646000:24103000:26181000:20982000:13391000:21337000:26897000:21634000:20112000:18925000:20153000:45390000:18937000:16561000:15972000:20094000:21776000:17027000:13177000:541482000' 2>&1
{ LD_PRELOAD=/opt/lib/libmediaclient.so timeout 10 dvbtune -c 0 -f 554000000 -s 6952 -qam 256; LD_PRELOAD=/opt/lib/libmediaclient.so timeout 1 dvbsnoop -adapter 0 -s bandwidth 8190 -n 80000; } 2>&1
## PID: 8190 (0x1ffe) bad/total packets: 0/14907 (= 0.0%) Avrg: 23525.843 kbit/s 23526
CMD: /bin/bash -c 'rrdtool update /home/pi/docsis-cable-load-monitor/CableLoadMonitor.rrd N:30064000:23526000:25200000:27347000:22759000:25646000:24103000:26181000:20982000:13391000:21337000:26897000:21634000:20112000:18925000:20153000:45390000:18937000:16561000:15972000:20094000:21776000:17027000:13177000:537191000' 2>&1
{ LD_PRELOAD=/opt/lib/libmediaclient.so timeout 10 dvbtune -c 0 -f 562000000 -s 6952 -qam 256; LD_PRELOAD=/opt/lib/libmediaclient.so timeout 1 dvbsnoop -adapter 0 -s bandwidth 8190 -n 80000; } 2>&1

 

[Joerg]

Du kannst versuchen die -n 80000 bei dvbsnoop auf eine kleinere Zahl zu ändern; dvbsnoop "blockt" solange, bis 80000 Pakete auf dem grade gescannten Kanal empfangen wurden. Da kann bei geringer Auslastung zu lange dauern. Eine Veringerung der Paketzahl führt indirekt dazu dass über einen kürzeren Zeitraum "gescannt" und gemittelt wird, die Ergebnisse sind also gewissermaßen etwas ungenauer, aber nicht falsch. Vielleicht hilft das.

Jörg

 

[Holzlenkrad]

@MartinP_Do
Kommentier mal in der Datei CableLoadMonitor bei Zeile ca. 59 alles ab

RRDGRAPHS[RRDGRAPHS_CNT++] = 60 * 60 * 6 " |6h"

aus, mit einer Raute #, sodass nur noch die wenig rechenintensive minütliche Grafik erstellt wird.

Aber bei meinem PI sind das nur ein paar Sekunden, wenn das bei dir mehrere Minuten dauert, dann ist irgendwas kaputt (SD-Karte) oder im Hintergrund laufen noch andere Prozesse.

 

[MartinP_Do]

Der Tipp von @Holzlenkrad hat schon einmal nichts gebracht. gibt immer noch die Lücke. Tendentiell sieht man ja trotzdem, woran man ist ... An den -n 80000 kann es eigentlich auch nicht liegen - derzeit kommen über die 24 Kanäle fast 800 MBit/s von 1200 möglichen ...

 

[Holzlenkrad]

Der Tipp von @Holzlenkrad hat schon einmal nichts gebracht. gibt immer noch die Lücke. Tendentiell sieht man ja trotzdem, woran man ist ... An den -n 80000 kann es eigentlich auch nicht liegen - derzeit kommen über die 24 Kanäle fast 800 MBit/s von 1200 möglichen ...

Die Grafiken für die 6h, 24h und Wochenansicht werden nach der Code-Änderung aber sicher nicht mehr aktualisiert?

Kannst du mal versuchen die zeitlich korrespondieren Log-Einträge zu posten? Also zum Zeitpunkt wo die Pause in der Grafik ist?

 

[MartinP_Do]

Die Grafiken für die 6h, 24h und Wochenansicht werden nach der Code-Änderung aber sicher nicht mehr aktualisiert?

Kannst du mal versuchen die zeitlich korrespondieren Log-Einträge zu posten? Also zum Zeitpunkt wo die Pause in der Grafik ist?

In meinen Loggings sind keine Zeitstempel ....

Habe inzwischen auch mit "-n 1" und "-m 1" versucht, die Suche nach nicht vorhandenen weiteren USB-Tunern zu unterbinden, hat auch nichts gebracht - Lücke immer noch vorhanden ...

tail CableLooadMonitor.log

{ LD_PRELOAD=/opt/lib/libmediaclient.so timeout 10 dvbtune -c 0 -f 762000000 -s 6952 -qam 256; LD_PRELOAD=/opt/lib/libmediaclient.so timeout 1 dvbsnoop -adapter 0 -s bandwidth 8190 -n 80000; } 2>&1
## PID: 8190 (0x1ffe) bad/total packets: 0/11982 (= 0.0%) Avrg: 18949.451 kbit/s 18949
CMD: /bin/bash -c 'rrdtool update /home/pi/docsis-cable-load-monitor/CableLoadMonitor.rrd N:15531000:12904000:21298000:25311000:14897000:18695000:16669000:14336000:18515000:19262000:19866000:15424000:21219000:15087000:20534000:20191000:21159000:19503000:24015000:19376000:21707000:14959000:18949000:14467000:443874000' 2>&1
{ LD_PRELOAD=/opt/lib/libmediaclient.so timeout 10 dvbtune -c 0 -f 770000000 -s 6952 -qam 256; LD_PRELOAD=/opt/lib/libmediaclient.so timeout 1 dvbsnoop -adapter 0 -s bandwidth 8190 -n 80000; } 2>&1
## PID: 8190 (0x1ffe) bad/total packets: 0/10991 (= 0.0%) Avrg: 17418.824 kbit/s 17419
CMD: /bin/bash -c 'rrdtool update /home/pi/docsis-cable-load-monitor/CableLoadMonitor.rrd N:15531000:12904000:21298000:25311000:14897000:18695000:16669000:14336000:18515000:19262000:19866000:15424000:21219000:15087000:20534000:20191000:21159000:19503000:24015000:19376000:21707000:14959000:18949000:17419000:446826000' 2>&1
446826
scanning output for: <^(.*ERROR.*)$>

EDIT - jetzt habe ich ALLES, bis auf die 1 h Erfassung auskommentiert - sieht besser aus ... keine Lücken ... Vielleicht mache ich mir mal eine neue SD-Karte - die ist schon etwas älter ...

 

[Holzlenkrad]

EDIT - jetzt habe ich ALLES, bis auf die 1 h Erfassung auskommentiert - sieht besser aus ... keine Lücken ... Vielleicht mache ich mir mal eine neue SD-Karte - die ist schon etwas älter ...

Ach hattest du vorher nur die eine Zeile für die 6 Stunden-Grafik auskommentiert?

Naja im Logfile ist halt die Zeit während der Pause ganz interessant. Wenn die Pause bei dir fast 3 Minuten lang ist, dann sollte dafür ja genügend Zeit sein.

Aber ich kann mir vorstellen, dass es einfach zu lange dauert um von der SD-Karte die kompletten historischen Werte zu öffnen um dann die Grafiken für z.B. eine Woche zu erstellen.
Du kannst ja mal gucken, ob du einfach mal die SD-Karte benchmarken kannst ob das halbwegs im normalen Rahmen ist.

 

[MartinP_Do]

Mache ich ... lasse es jetzt erstmal die Nacht durchlaufen. Habe inzwischen die Stundengrafik und die Tagesgrafik wieder reaktiviert. Das kriegt der Pi 1 B+ gestemmt ...

 

[bliblablubbe]

Auf einem PI1 mit 6 X-Box Tunern hatte ich auch falsche Messwerte. Ich kenne die Auswertetechnik nicht genau, kann deshalb zum Grund nichts genaues sagen. WEnn man nebenher noch load erzeugt, dann kann man die falschen Messwerte besonders hervorrufen. Und ja, das erzeugen der Grafiken auf nem PI1 dauert sehr lange. Bin nun auf nen PI3 gewechselt, das scheint deutlich zuverlässiger und schneller.

 

[MartinP_Do]

Interessanterweise hat es mit einem alten Stand des Scripts vor ein paar Monaten noch funktioniert. Ob die Verschlechterung an einer Änderung des Skripts, Alterung der SD-Karte oder am Wechsel des Platzes, an dem ich das DOCSIS-Signal mit dem Raspberry abgreife liegt, weiß ich nicht ...

Damals konnte ich aber die 7 Tage Grafik nicht erzeugen, da wurde die RRD anscheinend zu groß, musste alles auf 3 Tage begrenzen, sonst schmierte das Script schon bei der Initialisierung des RRD ab ...


Ich werde die SD-Karte aus dem Pi ggfs. mal an meinem Linux-PC einem file system check unterziehen ...


Wie groß ist eigentlich die RRD? Könnte man nicht die Auswertung/Bilderzeugung des RRD auf ein potenteres System auslagern, ggfs die Bilder nur erzeugen lassen, wenn jemand sie anschaut, also das Auswerteprogramm startet?

 

[mulder77]

Verlege das doch mal testweise nach /dev/shm. Dann spielt die SD-Karte keine Rolle.

 

[MartinP_Do]

Verlege das doch mal testweise nach /dev/shm. Dann spielt die SD-Karte keine Rolle.

Naja ich bin da skeptisch - der Pi 1B hat nur 512 MB RAM ....

 

[MartinP_Do]

Ich schaue mal, habe etwas gefunden, dass man den Pi 1B+ auch von 700 MHz auf 1 GHz übertakten kann...

 

[sparkie]

Kann es sein, dass der Raspberry Pi B+ nicht "hinterherkommt", und für das Rendern der Grafiken zu lange braucht?

sehr merkwürdig. Was gibt den der 'CableLoadMonitor' direkt aus? Daran kannst Du doch genau sehen wie lange er zum Scan braucht:
Beispiel:

downstream channel frequencies now in use: [ 20 ]
634/QAM256 618/QAM256 626/QAM256 642/QAM256 650/QAM256 658/QAM256 666/QAM256
674/QAM256 682/QAM256 690/QAM256 698/QAM256 706/QAM256 714/QAM256 722/QAM256
730/QAM256 738/QAM256 746/QAM256 754/QAM256 762/QAM256 770/QAM256
graph display mode: accumulated
graph destination dir: /root/bin/
recording RRA step size: 10 seconds
recording RRA history size: 7 day(s) 0 hour(s) 0 minute(s) 0 second(s)
using multiple DVB-C tuners: in parallel (if applicable)
DVB-C bit errors reported: ignored
DVB-C failure recovery method: retry
generating graph for: 1h recording length, size 1500x200 pixels
generating graph for: 6h recording length, size 1500x200 pixels
generating graph for: 1d recording length, size 1500x200 pixels
generating graph for: 7d recording length, size 1500x200 pixels
no Sundtek card(s) found, trying others (unsupported)
DVB-C tuner(s) found: 2, using thereof: 1
18:05:53: 19172 16772 16963 15816 17189 16764 15812 15726 14615 14719 18179 14957 14208 15192 14390 14176 15176 13975 14067 14173 312041
18:06:52: 18503 20154 18930 18695 17954 19584 18910 18004 14917 13580 13924 13808 14023 15004 14837 14642 14881 14561 14733 15578 325222
18:07:40: 22771 21532 21523 17012 17804 17648 16488 18581 14343 13965 14213 14430 14615 14682 15102 13844 13782 13726 14114 14570 324745
18:08:27: 17573 17081 17212 19009 17078 15867 16650 16383 14505 13932 13765 13732 13459 14020 13758 13037 13972 13926 14688 13941 303588
18:09:14: 15744 16065 15621 16687 15471 15492 15311 16918 14087 14060 14520 14294 13536 14398 14111 13477 14328 13836 12575 13794 294325
18:10:02: 16165 15130 15248 15324 16171 15549 16382 8613 12952 9494 8566 9903 7666 8699 2901 950 1927 1938 2432 852 186862
18:10:49: 3906 8352 7731 7854 5225 5843 6195 5323 1290 3299 1443 1888 983 1100 2283 2575 2761 3420 5243 2967 79681
18:11:36: 9223 5286 8138 4812 5986 4832 4837 14955 1334 1143 4480 1138 1120 1099 2106 1596 1797 3046 1697 3343 81968

 

[sparkie]

falls das keine Fehlerhinweise ergibt das Programm mit '-v' starten und File 'CableLoadMonitor.log' ansehen/posten.

 

[MartinP_Do]

Okay, ich schaue mir das heute abend mal weiter an ... Eventuell baue ich auch noch in den Teil "Generating Graph for:" Zeistempel ein - es gibt ja die Vermutung, dass das Generieren der Grafiken selber die meiste Zeit schluckt ...

 

[MartinP_Do]

Hier der Output, statt ca 1 Minute für eine Scan-Runde, wie bei Dir braucht mein Raspberry Pi fast 3 Minuten ...

evaluating given downstream channel frequencies
downstream channel frequencies now in use: [ 24 ]
546/QAM256 554/QAM256 562/QAM256 570/QAM256 578/QAM256 586/QAM256 594/QAM256
602/QAM256 618/QAM256 626/QAM256 634/QAM256 642/QAM256 650/QAM256 658/QAM256
666/QAM256 674/QAM256 682/QAM256 690/QAM256 698/QAM256 706/QAM256 746/QAM256
754/QAM256 762/QAM256 770/QAM256
graph display mode: accumulated
graph destination dir: /var/www/html/
recording RRA step size: 10 seconds
recording RRA history size: 7 day(s) 0 hour(s) 0 minute(s) 0 second(s)
using multiple DVB-C tuners: in parallel (if applicable)
DVB-C bit errors reported: ignored
DVB-C failure recovery method: retry
generating graph for: 1h recording length, size 1200x600 pixels
generating graph for: 6h recording length, size 1200x600 pixels
generating graph for: 1d recording length, size 1200x600 pixels
generating graph for: 7d recording length, size 1200x600 pixels
no Sundtek card(s) found, trying others (unsupported)
DVB-C tuner(s) found: 1, using thereof: 1
19:33:23: 24285 29712 25718 25568 28170 26050 27014 20289 19144 21077 19748 24380 25831 22473 20898 24515 27915 29630 25582 27238 14342 20534 26829 24604 581546
19:36:12: 31894 27085 16417 15237 19391 16707 15001 23969 18580 15628 19138 20884 19748 17944 20272 19301 21889 25295 19025 20371 15993 17765 21307 12075 470916

 

[sparkie]

was bedeutet "minutenlang"? Für den ersten Scan hat er knapp 3 Minuten gebraucht. Braucht er dann plötzlich länger?

gibt es Platzprobleme auf der Platte? Steht was im "/var/log/messages"?

 

[MartinP_Do]

Ich habe mal beim Generieren der Grafik auch Zeitstempel machen lassen

SCAN 20:02:15: 16636 16386 14636 23493 22850 18361 14488 23669 18168 16999 17661 17778 23457 17774 18010 21730 17445 30265 23357 17732 24771 16962 24677 24841 482146
RRD 0 20:03:18: RRD 1 20:03:26: RRD 2 20:03:34: RRD 3 20:05:06: SCAN 20:05:06: 28283 14887 16232

Hier die Änderung (2 x PRF in die Schleife)
Und beim Auslesen der Werte aus dem Tuner habe ich "SCAN" vorangestellt ...

func generate_rrdgraphs( \ i, a)
{ for (i = 0; RRDGRAPH_CMD[i]; ++i) { if (i && RRDGRAPH_LUPD[i - 1] - RRDGRAPH_LUPD[i] < RRDGRAPH_UPDATE_RATE) { break } if (ex(RRDGRAPH_CMD[i], verbose ? 0 : 256, "^(.*ERROR.*)$", a)) { PR(a[1]) exit_("rrdtool graph fails") } ex("mv " RRDGRAPH_TMP " " RRDGRAPH_FILE[i], 2) RRDGRAPH_LUPD[i] = strftime("%s") PRF("RRD " i " "); PRF(strftime("%T: ")) }
}

In /var/log/messages nix auffälliges

Apr 6 20:05:12 raspberrypi kernel: [98656.946382] si2157 12-0060: found a 'Silicon Labs Si2157-A30'
Apr 6 20:05:12 raspberrypi kernel: [98656.974211] si2157 12-0060: firmware version: 3.0.5
Apr 6 20:05:15 raspberrypi kernel: [98659.924995] si2157 12-0060: found a 'Silicon Labs Si2157-A30'
Apr 6 20:05:15 raspberrypi kernel: [98659.951929] si2157 12-0060: firmware version: 3.0.5

 

[sparkie]

die Zeit die der alte Pi zwischen RRD 2 und RRD 3 benötigt ist schon etwas heftig

 

[MartinP_Do]

Ich habe noch ein wenig mehr Ausgaben hereingemacht, die Rechenzeit für die Berechnung der Wochengrafik ist relativ hoch ...
RRD -> Start der Berechnung, MV -> vor dem mv Aufruf, DONE-> vor der nächsten Runde

DVB-C tuner(s) found: 1, using thereof: 1
SCAN 20:25:20: 14841 20400 15971 20511 19599 18907 24751 17175 19164 20034 23520 24198 16136 16751 21922 18594 24053 16234 23930 23272 22441 17613 22815 19445 482277
RRD 0 20:26:20: MV 20:26:23: DONE 20:26:23
RRD 1 20:26:23: MV 20:26:31: DONE 20:26:31
RRD 2 20:26:31: MV 20:26:39: DONE 20:26:39
RRD 3 20:26:39: MV 20:28:10: DONE 20:28:10

 

[bliblablubbe]

kann das verhalten auf einem pi1 bestätigen

 

[MartinP_Do]

Ich kenne mich nicht besonders gut mit RRD aus - kann es sein, dass beim Generieren der letzten RRD-Grafik zu viele Daten geschaufelt werden müssen?
Eigentlich sollte ja die RRD (wenn ich das richtig verstanden habe) selber für das Vorhalten verschiedener "Zoomstufen" sorgen, sodass beim Generieren der Grafiken die Datensätze "mundgerecht" vorliegen ..

 

[boba]

kann es sein, dass beim Generieren der letzten RRD-Grafik zu viele Daten geschaufelt werden müssen?

Das CableLoadMonitor Skript verwendet die rrd-Konzepte nicht richtig. Es missbraucht rrd eigentlich nur als Datenbank mit integrierter Grafikerstellung. Die Konsolidierungsmöglichkeiten werden nicht genutzt, und das vorgegebene Speicherraster von 10 Sekunden ist viel zu kurz. Deshalb gibts Lücken und vermutlich auch die Performanceprobleme, weil viel zuviel gespeichert wird.

Ich würde den Aufbau der rrd wie folgt machen: (von Hand - wie das im Skript gebaut werden müsste, keine Ahnung)

#!/bin/sh
# 1 Step = 60 Sekunden = 1 Minute
# 1 Minute Auflösung 1440 steps = 1 Minute * 1440 Steps = 1440 Minuten = 1 Tag
# 5 Minute Auflösung 2016 steps = 5 Minuten * 2016 Steps = 10080 Minuten = 7 Tage
# 30 Minute Auflösung 2976 steps = 30 Minuten * 2976 Steps = 89280 Minuten = 62 Tage = 2 Monate
# 60 Minute Auflösung 8760 steps = 60 Minuten * 8760 Steps = 525600 Minuten = 365 Tage = 1 Jahr
rrdtool create CableLoadMonitor-X.rrd \
-s 60 \
DS:f00:GAUGE:120:U:U \
DS:f01:GAUGE:120:U:U \
DS:f02:GAUGE:120:U:U \
DS:f03:GAUGE:120:U:U \
DS:f04:GAUGE:120:U:U \
DS:f05:GAUGE:120:U:U \
DS:f06:GAUGE:120:U:U \
DS:f07:GAUGE:120:U:U \
DS:f08:GAUGE:120:U:U \
DS:f09:GAUGE:120:U:U \
DS:f10:GAUGE:120:U:U \
DS:f11:GAUGE:120:U:U \
DS:f12:GAUGE:120:U:U \
DS:f13:GAUGE:120:U:U \
DS:f14:GAUGE:120:U:U \
DS:f15:GAUGE:120:U:U \
DS:f16:GAUGE:120:U:U \
DS:f17:GAUGE:120:U:U \
DS:f18:GAUGE:120:U:U \
DS:f19:GAUGE:120:U:U \
DS:f20:GAUGE:120:U:U \
DS:f21:GAUGE:120:U:U \
DS:f22:GAUGE:120:U:U \
DS:f23:GAUGE:120:U:U \
DS:f24:GAUGE:120:U:U \
DS:f25:GAUGE:120:U:U \
DS:f26:GAUGE:120:U:U \
DS:f27:GAUGE:120:U:U \
DS:f28:GAUGE:120:U:U \
DS:f29:GAUGE:120:U:U \
DS:f30:GAUGE:120:U:U \
DS:sum:GAUGE:120:U:U \
RRA:AVERAGE:0.5:1:1440 \
RRA:AVERAGE:0.5:5:2016 \
RRA:AVERAGE:0.5:30:2976 \
RRA:AVERAGE:0.5:60:8760

Die resultierende rrd ist nur ein Bruchteil so groß, bewahrt aber Daten bis zu einem Jahr auf. Die dann allerdings nur mit einer konsolidierten Auflösung von 1 Stunde. Eine 2-monatliche Aufbewahrung in 30 Minuten Auflösung ist auch drin. Eine Generierung von Grafiken über 7 Tage hinaus scheint im Skript vorgesehen zu sein, habe mich aber nicht damit beschäftigt ob und inwieweit man die aktivieren kann.

 

[why_]

Eine Generierung von Grafiken über 7 Tage hinaus scheint im Skript vorgesehen zu sein, habe mich aber nicht damit beschäftigt ob und inwieweit man die aktivieren kann.

Kann man aktivieren, frisst aber speicher wie blöd, so ab 90 Tage reichen dann selbst 16 gb ram nicht mehr für die Generierung und das schmiert mit malloc ab. Die rrd ist an dem Punkt schon über einen gigabyte groß