Visualisierung obs_face.py stürzt bei viel Daten wegen OOM ab seit März 22

[bossa]

Ich habe im März die neue Version des GitHub - openbikesensor/OpenBikeSensor-Scripts installiert.
Seit dieser Zeit laufen die Schritte

• exporting collected measurements und
• exporting visualization data
  um ein vielfaches länger und benötigen sehr viel Memory. Die annotation läuft wie vorher ohne Probleme.
  Beispiel:
  vorher bei ca. 200 csv files:
• 8 s: exporting collected measurements und
• 16 s: exporting visualization data
  seit März
• 9 Min: exporting collected measurements
• 18 Min: exporting visualization data
  zudem steigt der Memory-Verbrauch bei den beiden Schritten plötzlich stark an.
  Mein raspberry pi 4 Model B mit 8 GB ist dann bei 3 GB abgebrochen (war noch 32 bit OS).
  Jetzt habe ich das 64 bit OS und bereits
  463 files / 3914 measurments valid durchgebracht.
  Bei 618 files ist der raspberry kaum noch ansprechbar, da er dann die 8 GB Grenze erreicht hat und swapt.
  Ist das ein bug?
  Anbei die Statistik der Läufe von obs_face.py
  
  
  
  Der letzte Lauf ist jetzt im Schritt mit 6251 measurements valid Visualisierung durchgelaufen: mit 6:14 hh:mm und 10,2 GB Memory (bei 8 GB Phys Mem und 8 GB Swap).

[gluap]

Naja, wenn es swappt ist es nicht ungewöhnlich dass alles hängt oder sogar abstürzt. Dass mehr Daten mehr Speicher fressen ist auch nicht so ungewöhnlich. Die meisten benutzen das Script bei dieser Trackmenge vermutlich nur zur Analyse von Einzeltracks, weil das Portal das auf jeden Track einzeln ausführt und die Events dann in der Datenbank ablegt. Was passiert denn wenn du die vorherige Version auf den gleichen Datensatz loslässt? So könntest du rausfinden ob es an der eventmenge oder am Update liegt.

[bossa]

ich weiß leider nicht wo ich die alte Version herbekomme auf github sehe ich keine Releases. Ich habe im März einfach neu installiert. Wäre hilfreich zu wissen.

Aber ich hatte damals 310 files mit 18403 measurements laufen. die Zeiten stehen unten in der Tabelle. Im neuen mit ähnlich vielen 300 measurments mit sogar viel weniger confirmed und valid measurments sind die exporting Schritte viel länger gelaufen und haben erheblich mehr Speicher benötigt.

Datum	Uhrzeit	number of files	confirmed measurements	continuous segments	Measurements valid	annotating datasets	exporting collected measurements	exporting visualization data
13.12.2021	19:12:57	310	18403	890	4826	00:56:00	00:00:16	00:00:30
01.05.2022	17:01:00	300	8312	643	2202	00:50:00	00:17:00	00:31:00

Im Endeffekt heißt das aber, dass man das Skript für viele Daten nicht mehr hernehmen kann wenn man keinen riesen Server hat und folglich auf ein „eigenes“ bzw. ein irgendwie zentrales Portal umsteigen muss. Es wird ja nicht sinnvoll sein, dass jede Stadt den Aufwand für ein eigenes Portal betreibt. @jobuch hat schon eine Initiative gestartet, dass der ADFC Bayern das Thema unterstützt. Interesse besteht dort. Das wird aber ein bisschen dauern.

[gluap]

Du hast Recht, das ist ein starkes Indiz dafür dass die neuere Version es verschlechtert hat. Ich vermute auch dass der Usecase „Ich analysiere wirklich große Mengen an events mit dem script im standalone Modus“ bei der Weiterentwicklung der Skripten nicht mehr im Fokus war - Dass Menschen ein paar hundert events von Hand analysieren wussten wir, aber mehrere Tausend wusste zumindest ich nicht.

Einer der Gründe dafür dass wir den usecase mit der json-analyse nicht so auf dem Schirm hatten ist, dass die Browseransicht der Events jenseits von 5000-6000 events irgendwann zunehmend hakeliger wird, weil der Browser dann recht viel (=>10 Gigabyte je nach Eventanzahl). Wenn ihr beim ADFC Bayern ein Portal aufsetzen könnt ist das auf jeden Fall die zukunftssicherere Variante.

Falls du erstmal zurück auf eine ältere Version möchtest bis ein portal steht oder die scripts wieder performanter sind (kann ja auch nicht unmöglich sein die performance zurück zu bekommen):

Der kanonische Weg um eine ältere Revision zu bekommen wäre, den Codestand zu einem bestimmten Zeitpunkt mit der git command line zu holen. Das geht so:

• Aussuchen was man haben will kann man z.B. in der history Commits · openbikesensor/OpenBikeSensor-Scripts · GitHub wenn du weißt wann du deine letzte Version geholt hast kannst du z.b. nach Datum einen commit aussuchen und dir den hash mit dem copy symbol kopieren:
  
• Danach kannst du ein Verzeichnis mit den Quellen erzeugen indem du (am besten nicht über deinen aktuellen Ordner sondern in ein neues verzeichnis die revision mit diesem hash auscheckst (bei mir das lange ding was mit 37 anfängt):

  mkdir old_sources_test
  cd old_sources_test
  git clone https://github.com/openbikesensor/OpenBikeSensor-Scripts
  git checkout 37c4a241a75df93a083dedd858c3598d737dbf2e
  

  um einen anderen commit anzuspringen reicht dann der hash des commits:ö

  git checkout <hash>
  

  oder zurück auf main mit:

  git checkout main
  

[bossa]

Vielen Dank.
Nach git clone … musste ich noch nach cd OpenBikeSensor-Scripts wechseln.
Bin aber noch nicht erfolgreich geworden um die alte schnellere Vesion herauszufinden.
Habe noch
10.Okt 2021 a8582028c83d3b7d1196bfb14975830c57a8aabf
ausgecheckt. Diese Verison hat funktioniert war aber beim Export auch gleich langsam.
Bei den noch früheren Versionen habe ich keine funktionierende gefunden. Da gab es immer irgendwelche Fehler.
Beispiel:
08.Juni 2021 e79a269d0ead46081c18a99dd30faaf8eaced267 → beim Start osm Fehler "got an unexpected keyword argument ‚areas‘
22.Juni 2021 afeeeae1e46353b0d323e91a7598fb563b2e76d3 → line 84, in process_datasets: TypeError: Can’t instantiate abstract class MeasurementFilter with abstract method filter

Weiß nicht, ob das Sinn macht da noch mehr Zeit reinzustecken.