Certstream - Ressourcenverbrauch

vorhergehende Artikel in: Linux TeleGrafana Security
24.05.2019

In meinem letzten Artikel zur Auswertung globaler Zertifikatslog war unter anderem ein Screenshot zu sehen, der die Systembelastung des für die Durchführung der Tests benutzten Raspberry Pi darstellte.

Diese Ergebnisse brachten mich dazu, diese Analysen nicht ständig laufen zu lassen - denn abgesehen vom gestiegenen Energiebedarf lag die Temperatur meines passiv gekühlten Pi dabei auch gerne mal über 70 Grad Celsius. Das ist eine Temperatur, die ich einem Gerät nicht gestatte, wenn ich nicht im Haus oder zumindest auf dem Grundstück bin.

Dazu kommt noch, dass dieser spezielle Anwendungsfall - was die Last angeht - schwer abzuschätzen ist: Da die Anzahl der im Strom auftretenden Zertifikate sehr stark schwankt kann es sein, dass diese 70 Grad Celsius noch nicht das Maximum darstellen.

Daher hatte ich schon längere Zeit vor, dem Mysterium der hohen Auslastung nachzugehen und idealerwese Mittel und Wege zu finden, sie abzustellen. Dazu nahm ich mir nunmehr die Zeit. Zunächst wollte ich feststellen, was genau eigentlich für diese extrem hohe Last sorgt.

Die Anwendung arbeitet derzeit so, dass die Daten im Strom empfangen und aufbereitet werden, danach werden die einzelnen Datensätze analysiert, aufbereitet und nachdem das Ranking berechnet wurde an InfluxDB weitergeleitet. All das geschieht in dem aktuell von mir dazu bnutzten Python-Progrämmchen in einem Callback. Aktuell führt das dazu, dass auf dem Pi in top eine Prozessorlast von 100% für python3 gelistet wird. Daher schaltete ich den Callback komplett aus - das führte zu einem Wert von 98% in top.

Völlig überraschend für mich war also keineswegs mein Code zur Auswertung und Speicherung schuld - sondern de Code, der den Stream entgegennahm und aufbereitete, um dann die einzelnen Daten anden Callback zu geben.

An diesem Punkt experimentierte ich weiter - schließlich ist Python nicht die einzige Möglichkeit der Anbindung zur Konsumierung des Zertifikats-Stroms: andere Möglichkeiten sind Java, Go und Javascript. Ich testete Go und Java, weil - sind wir doch mal ehrlich: Javascriopt? ewww!.

Diese Tests fanden nicht mehr auf dem Pi statt, da das Installieren neuer Anwendungen dort ganz schön zur Geduldsprobe verkommen kann. Statt dessen führte ich den Test mit dem abgespeckten Python Programm ohne Callback nochmals auf einem PC (Ubuntu Linux 18.04) durch und stellte das Ergebnis entsprechenden Implementierungen in Go und Java gegenüber. Das Ergebnis sieht man in der untenstehenden Tabelle:

ProgrammierspracheAuslastung laut top
Python>20
Java<10
Go>5

Damit hatte ich deutliche Hinweise, auch wenn die Messungen ungenau und mit großer Unsicherheit beaufschlagt waren, ließ sich für mich ein klarer Trend ablesen, der es rechtfertigte, nun doch Go auf dem Raspi zu installieren und zu sehen, wie sich das Testprogramm dort schlagen würde.

Leider wurde meine Hoffnung nicht erfüllt - auf dem Pi listete top das Go-Programm immer noch mit ungefähr 40% Last (stark schwankend), so dass aus meiner Sicht (vor allem, da sämtliche Auswertung noch fehlte und ich ein völliger Go-Neuling bin) die Umstellung des Programms zur ständigen Überwachung des CertStream nicht lohnte. Interessant war in diesem Zusammenhang noch, dass

vcgencmd measure_clock arm

nur sehr selten das mögliche Maximum der Taktfrequenz anzeigte: meistens dümpelte diese bei 600MHz herum. Das erklärt eventuell auch die Tatsache, dass ein inzwischen über 12 Jahre alter Centrino-Laptop bei der Ausführung des Go-Programms lediglich eine Auslastung von 15% in top erreichte.

Das reichte trotzdem aus, zu versuchen ob dieser alte Laptop vielleicht das Mittel der Wahl sein könnte, den CertStream kontinuierlich zu überwachen. Ich benutzte für diesen Test das bereits vorhandene Python-Programm und musste leider erkennen, dass auch das keine Option ist - bei Benutzung von Pythen steigt die Auslastung lat top auf zwischen 60 und 70% an und der Lüfter ist kontinuierlich hörbar. Ein solcher Stress ist für über 12 Jahre alte Teile höchstwahrscheinlich nicht gut, daher brach ich den Test nach einem halben Tag wieder ab.

Artikel, die hierher verlinken

Grafana: Alarmierung mit XMPP

01.09.2019

Nachdem bei mir im "Home-Lab" Grafana kombiniert mit Influxdb prächtig funktioniert, habe ich mir über das Thema Alarmierung Gedanken gemacht...

Alle Artikel rss Wochenübersicht Monatsübersicht Github Repositories Gitlab Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

  • Aviator + Websockets

    15.06.2019

    Nachdem ich in den letzten Wochen und Monaten meine Zeit und Energie in die sQLshell gesteckt habe - was sowohl Bugfixing als auch neue Features betraf - habe ich nun endlich die Zeit gefunden, ein bereits lange überfälliges Feature an dWb+ und speziell am aviator zu implementieren.

    Weiterlesen...

Neueste Artikel

  • Neue Version plantumlinterfaceproxy napkin look

    Es gibt eine neue Version des Projektes plantumlinterfaceproxy - Codename napkin look.

    Weiterlesen...
  • Apache HTTPCore5 funktioniert nicht mit Docker

    Ich habe neulich drei Stunden meines Lebens verschwendet weil ich unbedingt die neueste Version der HTTPCore5 Library von Apache einsetzen wollte.

    Weiterlesen...
  • Entwurfsmodus für beliebige SVG Graphiken

    Nachdem ich in der Vergangenheit immer wieder Weiterentwicklungen der Idee vorgestellt habe, Graphiken mit dem Computer so zu ezeugen dass sie eine gewisse "handgemachte" Anmutung haben, habe ich nunmehr die durchschlagende Idee gehabt:

    Weiterlesen...

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen GitHub-Repositories findet man hier - meine öffentlichen GitLab-Repositories finden sich dagegen hier.