Dies ist eine Übersetzung des Original-Artikel geschrieben von @blocktrades zur Arbeit an der Hive Software: https://peakd.com/hive-139531/@blocktrades/10th-update-of-2021-on-blocktrades-work-on-hive-software
Nachfolgend eine Auflistung einiger Hive-bezogener Programmieraufgaben, an denen das BlockTrades-Team in den letzten Wochen gearbeitet hat:
Hived Work (Blockchain Node Software)
Wir haben letzten Mittwoch das erste Testnetzwerk von hived für den Hardfork 25 gestartet und haben mit der Konfiguration von Tinman dafür experimentiert.
Tinman ist ein Testnetz-Verwaltungswerkzeug für hived, das Konten erstellen und verschiedene Formen von Testdaten in eine hived-Node injizieren kann.
Während einiger unserer Tests haben wir ein Problem mit hived gefunden, bei dem es 100% der CPU eines Kerns auffrisst, wenn ein hived ohne einen gültigen Seed-Node gestartet wird, weil der Blockchain-Code in einer engen Schleife feststeckt und nach Transaktionen und Blöcken fragt, die nie auftauchen (weil die Node keine Peers hat, von denen er Daten bekommen kann).
Noch problematischer ist, dass in dieser Situation keine vernünftigen Diagnoseinformationen gemeldet wurden, so dass es eine Weile dauerte, bis wir das wirkliche Problem identifizieren konnten. Wir arbeiten derzeit an einem Fix für dieses Problem, der den CPU-Overhead in diesem Fall senkt und außerdem Warnmeldungen hinzufügt, um das Problem zu identifizieren.
Wir haben ein Problem mit beem (der Python-basierten API-Bibliothek für Hive) gefunden, das für die Ausführung von API-Tests auf Hive verwendet wird. @howo hat einen schnellen Patch zur Verfügung gestellt und wir arbeiten jetzt an einem langfristigen Fix (sollte morgen behoben sein).
@howo hat außerdem Aktualisierungen an der Funktion für wiederkehrende Überweisungen vorgenommen, die auf Änderungswünschen unserer Entwickler basieren, und wir planen für morgen eine abschließende Überprüfung dieser Änderungen mit dem Plan, sie in den Entwicklungszweig für den Einsatz beim nächsten Testnet-Start einzubinden.
Jussi Caching-Optimierung
Über das Wochenende habe ich beobachtet, dass unser hivemind viel stärker belastet wurde als normal (dies fiel zunächst auf hive.blog auf, wo es länger dauerte, einen Beitrag zum Lesen zu öffnen).
Schließlich fand ich heraus, dass unser Nodes mit einem dramatischen Anstieg der Anzahl von bridge.get_discussion API-Aufrufen belastet wird (diese Aufrufe werden gemacht, wenn man zu einem Beitrag eines Benutzers auf einer Seite wie peakd oder hive.blog navigiert) und dies führte zu einem CPU-Engpass im Python-Code, der die API-Aufrufe verarbeitet.
Es stellte sich heraus, dass es eine neue Seite gibt, die das Durchsuchen von Hive-Beiträgen ermöglicht, aber leider ist sie derzeit so programmiert, dass sie diesen Aufruf etwa jede Sekunde durchführt (ich vermute, um neue Kommentare zum Beitrag zu erkennen), und das führte zu einem großen Anstieg der Anzahl von API-Aufrufen, die unser Hivemind verarbeiten musste.
Die endgültige Lösung war ziemlich einfach: Wir haben unseren Jussi-Prozess so umkonfiguriert, dass er die Ergebnisse dieses Aufrufs für 1 Sekunde zwischenspeichert (vorher hatten wir für diesen Aufruf kein Caching konfiguriert).
Alle API-Aufrufe gehen zuerst zu Jussi, bevor sie an hivemind weitergeleitet werden, und wenn Jussi die Antwort auf einen früheren API-Aufruf zwischengespeichert hat, dann kann es einfach die vorherige Antwort zurückgeben, anstatt hivemind erneut zu fragen.
Bis jetzt haben wir auf api.hive.blog nicht viel Caching aktiviert, abgesehen von ein paar grundlegenden Dingen, damit wir erkennen konnten, welche Aufrufe für hivemind teuer zu verarbeiten sind, und dann die Verarbeitung dieser Aufrufe optimieren konnten.
Aber jetzt ist diese Optimierungsarbeit größtenteils abgeschlossen, so dass wir bald einen Blick darauf werfen werden, wie wir unser Jussi-Caching optimieren können, um die Last auf hivemind und hived zu reduzieren, da dies eine erhebliche Skalierung für unsere Node ermöglichen sollte.
Modulares hivemind (Anwendungs-Framework für 2nd-Layer-Apps)
Wir haben die Ursache für das Speicherleck in hivemind isoliert: Es scheint ein Fall zu sein, in dem Python den Speicher von Dictionaries nicht freigibt, wenn die Daten im Dictionary gelöscht werden. Wir haben Code hinzugefügt, um eine "Tiefenreinigung" dieser Dictionaries durchzuführen. Wir werden wahrscheinlich Ende nächster Woche Performance-Messungen darüber haben, wie viel Speicher dies bei der aktuellen Blockhöhe spart.
Nebenbei bemerkt: Ich glaube, dass aktuelle Nodes diesen Speicher wiederherstellen können, bevor sie unseren Fix erhalten, indem sie ihre Hivemind-Instanz stoppen und neu starten.
Wir haben auch einige Änderungen an den Hivemind-Tests vorgenommen, die auf der Änderung der Art und Weise basieren, wie das Community-Muting implementiert wird, und diese Änderungen werden wahrscheinlich morgen in den Entwicklungszweig eingebunden.
Wir haben volle Hivemind-Synchronisationen auf mehreren Systemen durchgeführt, um die Leistung unter verschiedenen Hivemind-Konfigurationen zu testen. Wir haben eine Verlangsamung auf einer Maschine gefunden, die mit einer neuen hivemind Kommandozeilenoption läuft und wir versuchen zu analysieren, ob es an der Verwendung der neuen Kommandozeilenoption liegt oder an einem anderen Konfigurationsproblem auf diesem System (z.B. Hardware oder Datenbankkonfiguration). Im Moment versuchen wir mit verschiedenen Experimenten, das Grundproblem auf diesem System zu isolieren.
Modular hivemind (Framework für Hive-Anwendungen)
Diese Woche haben wir die ersten Arbeiten am Fork-Resolution-Code für modular hivemind abgeschlossen. Wir verwenden eine vollständig SQL-basierte Lösung, die auf Shadow-Tabellen (shadow tables) basiert, die Änderungen speichern, die im Falle eines Fork-Switches rückgängig gemacht werden müssen.
Wir erstellen derzeit ein Architekturdokument, das beschreibt, wie der Fork-Resolution-Code funktioniert und wie man ihn für eine Hive-basierte Anwendung verwendet.
Aktualisierung des hived testnet
Wir planen, am Donnerstag ein aktualisiertes Testnet mit den oben erwähnten Korrekturen an hived zu starten.
Danach wird eine API-Node gestartet, der so konfiguriert ist, dass er Daten aus dem Testnet bezieht (wahrscheinlich am Freitag, wenn alles gut geht).
Dieser API-Knotenpunkt wird es Hive-Anwendungen ermöglichen, Code-Änderungen vorzunehmen, um neue Funktionen zu unterstützen, die durch den Hardfork hinzugekommen sind, wie z. B. das Melden des Verfalls von Votes/Stimmen.
Neues hivemind Release bald geplant
In der nächsten Woche werden wir die letzten Änderungen an hivemind weiter testen: zuerst weitere Leistungstests von hivemind sync, dann reale Leistungstests auf api.hive.blog.
Wenn all diese Tests gut verlaufen, können wir vielleicht schon Ende nächster Woche eine neue Version von hivemind für API-Nodebetreiber freigeben. Diese Version würde die verschiedenen Fehlerbehebungen und Leistungsoptimierungen enthalten, über die in früheren Beiträgen berichtet wurde.
SQL-Kontohistorie-Plugin für hived (Voraussetzung für modulares hivemind)
Wir hatten geplant, diese Aufgabe letzte Woche anzugehen, aber leider wurde sie durch andere Aufgaben verzögert. Wir hoffen aber, dass wir die Änderungen am SQL Account History Plugin, das die Daten nach Postgres schiebt (wodurch Hivemind die Daten nicht mehr über RPC-Aufrufe abrufen muss), in den nächsten Tagen abschließen können.
Nachdem die Plugin-Änderungen abgeschlossen sind, werden wir eine gleichzeitiges Replay von hived mit einer Vollsynchronisation von hivemind durchführen, um die Beschleunigung zu messen und zu sehen, ob sie mit der von uns erwarteten Verbesserung der Zeit für die Vollsynchronisation von hivemind übereinstimmt (wir erwarten 2 Tage gegenüber den derzeit benötigten 4 Tagen).
Voraussichtliches Hardfork-Datum
Ich glaube, wir müssen noch mehr Testnet-basierte Tests durchführen, bevor wir die Börsen über die neue Version des Codes informieren, und da wir ihnen ungefähr 30 Tage Zeit geben wollen, um zu aktualisieren, nachdem wir eine gut getestete Code-Version haben, denke ich, dass wir noch mindestens 1,5 Monate von einem möglichen Hardfork-Datum entfernt sind.
Congratulations @louis88! You have completed the following achievement on the Hive blockchain and have been rewarded with new badge(s) :
Your next target is to reach 62000 upvotes.
You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPCheck out the last post from @hivebuzz:
Support the HiveBuzz project. Vote for our proposal!