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

  • AtomicInteger vs. Integer

    24.03.2019

    Ich habe am Wochenende wieder einmal mit Java-Benchmarks experimentiert

    Weiterlesen...

Neueste Artikel

  • Konstruktive Geometrie mit dem Computer

    Ich habe in einem vorhergehenden Artikel beschrieben, dass ich eine weitere neue Graphik-Primitive erstellt habe. Dabei musste ich mir meine verschütteten Trigonometrie-Kenntnisse wieder vor Augen führen - mit Bleistift und Papier. Das müsste doch auch anders gehen dachte ich mir und begann...

    Weiterlesen...
  • GitHub-Projekte

    Mal abgesehen von den anderen Links, die ich in unregelmäßigen Intervallen hier poste kommt heute ein Schwung (aus meiner Sicht) interessanter/skurriler Projekte auf GitHub:

    Weiterlesen...
  • Mehrere Datenbanken und Postgis-Erweiterung in Docker

    Ich hatte ja schon beschrieben, dass ich mich in diesem Jahr wieder intensiver um mein Geoinformationssystem EBMap4D kümmern möchte. Dazu habe ich jetzt einige infrastrukturelle Vorbereitungen getroffen...

    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.