Benchmarks

• 1: Benchmark zum Speicherverbrauch der Speicherschicht
• 2: Benchmark zum Speicherverbrauch von Watches
• 3: Benchmarks für etcd v3
• 4: Benchmarks für etcd v2.2.0-rc-memory
• 5: Benchmarks für etcd v2.2.0-rc
• 6: Benchmarks für etcd v2.2.0
• 7: Benchmarks für etcd v2.1.0

1 - Benchmark zum Speicherverbrauch der Speicherschicht

Zwei Komponenten der etcd-Speicherschicht beanspruchen physischen Speicher. Der etcd-Prozess legt einen Index im Arbeitsspeicher an, um Schlüssel schneller nachzuschlagen. Der vom Betriebssystem verwaltete Seitencache des Prozesses hält kürzlich vom Datenträger gelesene Daten zur schnellen Wiederverwendung vor.

Der Index im Arbeitsspeicher enthält alle Schlüssel in einer B-Baum -Datenstruktur, zusammen mit Zeigern auf die Daten (die Werte) auf dem Datenträger. Jeder Schlüssel im B-Baum kann mehrere Zeiger enthalten, die auf verschiedene Versionen seiner Werte verweisen. Der theoretische Speicherverbrauch des Index lässt sich daher mit folgender Formel näherungsweise berechnen:

N * (c1 + avg_key_size) + N * (avg_versions_of_key) * (c2 + size_of_pointer)

Dabei ist c1 der Zusatzaufwand für Schlüsselmetadaten und c2 der Zusatzaufwand für Versionsmetadaten.

Die Grafik zeigt den detaillierten Aufbau des B-Baum-Index im Arbeitsspeicher.

                                In mem index

                               +------------+
                               | key || ... |
  +--------------+             |     ||     |
  |              |             +------------+
  |              |             | v1  || ... |
  |   disk    <----------------|     ||     | Tree Node
  |              |             +------------+
  |              |             | v2  || ... |
  |           <----------------+     ||     |
  |              |             +------------+
  +--------------+       +-----+    |   |   |
                         |     |    |   |   |
                         |     +------------+
                         |
                         |
                         ^
                      ------+
                      | ... |
                      |     |
                      +-----+
                      | ... | Tree Node
                      |     |
                      +-----+
                      | ... |
                      |     |
                      ------+

Der Seitencache wird vom Betriebssystem verwaltet und in diesem Dokument nicht näher behandelt.

Testumgebung

etcd-Version

• Git-Stand https://github.com/etcd-io/etcd/commit/776e9fb7be7eee5e6b58ab977c8887b4fe4d48db

GCE-Rechnertyp n1-standard-2

• 7.5 GB Arbeitsspeicher
• 2x CPUs

Speicherverbrauch des Index im Arbeitsspeicher

Dieser Test misst ausschließlich den Speicherverbrauch des Index im Arbeitsspeicher. Ziel ist, die oben genannten Werte c1 und c2 zu bestimmen und die feste Grenze des Speicherverbrauchs der Speicherschicht zu verstehen.

Wir berechnen den Speicherverbrauch mit der Go-Funktion runtime.ReadMemStats. Dazu ermitteln wir die Differenz der insgesamt zugewiesenen Bytes vor und nach dem Erstellen des Index. Dies bildet den Speicherverbrauch des Index selbst nicht exakt ab, zeigt aber das ungefähre Verbrauchsmuster.

Aus den Ergebnissen lassen sich c1=120bytes und c2=30bytes berechnen. Da c1 und c2 die einzigen Unbekannten in der Formel sind, reichen zwei Datensätze zu ihrer Berechnung aus. Die Werte c1=120bytes und c2=30bytes sind die Mittelwerte der 4 berechneten Wertepaarungen für c1 und c2. Bei kleinen Schlüssel-Wert-Paaren ist der Zusatzaufwand für Schlüsselmetadaten mit 50% weiterhin beträchtlich. Gegenüber dem alten Speicher mit mindestens 1000% Zusatzaufwand ist dies jedoch eine erhebliche Verbesserung.

Gesamter Speicherverbrauch

Der gesamte Speicherverbrauch erfasst, wie viel RSS etcd mit der Speicherschicht beansprucht. Die Größe der Werte sollte den gesamten Speicherverbrauch von etcd nur wenig beeinflussen, da die Werte auf dem Datenträger liegen und nur häufig verwendete Werte im Arbeitsspeicher verbleiben, verwaltet vom Seitencache des Betriebssystems.

Die Ergebnisse zeigen, dass die Größe der Werte den Speicherverbrauch nicht wesentlich beeinflusst. Er steigt geringfügig, weil der Seitencache des Betriebssystems mehr Daten vorhält.

2 - Benchmark zum Speicherverbrauch von Watches

Ein wesentliches Ziel von etcd ist die Unterstützung sehr vieler Watcher mit einer außerordentlich großen Zahl von Watch-Registrierungen. Angestrebt werden O(10k) Clients, O(100K) Watch-Streams (O(10) Streams pro Client) und insgesamt O(10M) Watch-Registrierungen (O(100) pro Stream). Der Speicherverbrauch der einzelnen Watch-Registrierungen macht den größten Teil des gesamten Speicherverbrauchs von etcd aus und steht deshalb im Mittelpunkt der aktuellen und künftigen Optimierungen.

Drei zusammengehörige Komponenten der Watch-Funktion von etcd beanspruchen physischen Speicher: jede grpc.Conn, jeder Watch-Stream und jede einzelne Watch-Registrierung. grpc.Conn verwaltet die tatsächliche TCP-Verbindung und weitere gRPC-Verbindungszustände. Jede grpc.Conn beansprucht O(10kb) Speicher und kann mehrere Watch-Streams haben.

Jeder Watch-Stream ist eine eigenständige HTTP2-Verbindung, die weitere O(10kb) Speicher beansprucht. Mehrere Watch-Registrierungen können sich einen Watch-Stream teilen.

Eine Watch-Registrierung ist die eigentliche Struktur, die Änderungen im Schlüssel-Wert-Speicher verfolgt. Jede Registrierung sollte nur < O(1kb) beanspruchen.

                                          +-------+
                                          | watch |
                              +---------> | foo   |
                              |           +-------+
                       +------+-----+
                       |   stream   |
      +--------------> |            |
      |                +------+-----+     +-------+
      |                       |           | watch |
      |                       +---------> | bar   |
+-----+------+                            +-------+
|            |         +------------+
|   conn     +-------> |   stream   |
|            |         |            |
+-----+------+         +------------+
      |
      |
      |
      |                +------------+
      +--------------> |   stream   |
                       |            |
                       +------------+

Der theoretische Speicherverbrauch von Watch lässt sich mit folgender Formel näherungsweise berechnen: memory = c1 * number_of_conn + c2 * avg_number_of_stream_per_conn + c3 * avg_number_of_watch_stream

Testumgebung

etcd-Version

• Git-Stand https://github.com/etcd-io/etcd/commit/185097ffaa627b909007e772c175e8fefac17af3

GCE-Rechnertyp n1-standard-2

• 7.5 GB Arbeitsspeicher
• 2x CPUs

Gesamter Speicherverbrauch

Der gesamte Speicherverbrauch erfasst, wie viel RSS etcd mit den Client-Watchern beansprucht. Obwohl das Ergebnis um bis zu 10% schwanken kann, ist es aussagekräftig: Ziel ist, den ungefähren Speicherverbrauch und das Muster der Speicherzuweisungen zu verstehen.

Aus dem Benchmark-Ergebnis lassen sich näherungsweise c1 = 17kb, c2 = 18kb und c3 = 350bytes berechnen. Jede zusätzliche Clientverbindung beansprucht also 17kb Speicher, jeder zusätzliche Stream 18kb und jede weitere Watch-Registrierung nur 350bytes. Ein einzelner etcd-Server kann im Normalfall Millionen von Watch-Registrierungen mit wenigen GB Arbeitsspeicher verwalten.

3 - Benchmarks für etcd v3

Physische Rechner

GCE-Rechnertyp n1-highcpu-2

• 1x dedizierte lokale SSD, unter /var/lib/etcd eingebunden
• 1x dedizierter langsamer Datenträger für das Betriebssystem
• 1.8 GB Arbeitsspeicher
• 2x CPUs
• etcd-Version 2.2.0

etcd-Cluster

1 etcd-Mitglied im v3-Demomodus

Testverfahren

Das Benchmarkwerkzeug für etcd v3 verwenden.

Leistung

Einen einzelnen Schlüssel lesen

Die Leistung ist nahezu gleich wie mit einem leeren Server-Handler.

Einen einzelnen Schlüssel nach dem Schreiben lesen

Mit einem leeren Server-Handler beeinflusst ein einzelner put-Vorgang die Leistung nicht. Der Leistungsrückgang dürfte daher durch das Speicherpaket verursacht werden.

4 - Benchmarks für etcd v2.2.0-rc-memory

Physischer Rechner

GCE-Rechnertyp n1-standard-2

• 1x dedizierte lokale SSD, unter /var/lib/etcd eingebunden
• 1x dedizierter langsamer Datenträger für das Betriebssystem
• 7.5 GB Arbeitsspeicher
• 2x CPUs

etcd

etcd Version: 2.2.0-rc.0+git
Git SHA: 103cb5c
Go Version: go1.5
Go OS/Arch: linux/amd64

Testverfahren

Einen etcd-Cluster mit 3 Mitgliedern starten, von denen jedes 2 Kerne verwendet.

Schlüsselnamen sind stets 64 Bytes lang, was einer angemessenen durchschnittlichen Schlüssellänge entspricht.

Maximaler Speicherverbrauch

• etcd kann den maximalen Speicherverbrauch erreichen, wenn ein Follower ausgefallen ist und der Leader fortlaufend Snapshots sendet.
• max RSS ist der höchste in 3 Durchläufen gemessene Speicherverbrauch.

Schwellenwert für die Datenmenge

• Wenn etcd den Schwellenwert für die Datenmenge erreicht, kann es leicht zu einer Leader-Wahl kommen, und ein Teil der Vorschläge kann verworfen werden.
• In den meisten Fällen sollte der etcd-Cluster reibungslos arbeiten, solange er den Schwellenwert nicht erreicht. Arbeitet er wegen unzureichender Ressourcen nicht zuverlässig, die Datenmenge reduzieren.

5 - Benchmarks für etcd v2.2.0-rc

Physischer Rechner

GCE-Rechnertyp n1-highcpu-2

• 1x dedizierte lokale SSD, unter /var/lib/etcd eingebunden
• 1x dedizierter langsamer Datenträger für das Betriebssystem
• 1.8 GB Arbeitsspeicher
• 2x CPUs

etcd-Cluster

3 Mitglieder mit etcd 2.2.0-rc, jeweils auf einem eigenen Rechner.

Versionsdetails:

etcd Version: 2.2.0-alpha.1+git
Git SHA: 59a5a7e
Go Version: go1.4.2
Go OS/Arch: linux/amd64

Außerdem bilden wir aus 3 Mitgliedern mit etcd 2.1.0 im Alpha-Stadium einen Cluster, um die Ausgangsleistung zu ermitteln. Der verwendete etcd-Commit ist c7146bd5 , derselbe wie im etcd-2.1-Benchmark .

Testverfahren

Einen weiteren Rechner einrichten und mit dem HTTP-Benchmarkwerkzeug hey Anfragen an jedes etcd-Mitglied senden. Eine ausführliche Anleitung enthält der Leitfaden zur Benchmark-Entwicklung .

Leistung

Einen einzelnen Schlüssel lesen

Einen einzelnen Schlüssel schreiben

Erklärung der Leistungsänderungen

• Die Lese-QPS sinken in den meisten Szenarien um 5~8%. Der Grund ist, dass etcd für jede Speicheroperation Speichermetriken erfasst. Diese sind für Überwachung und Fehlersuche wichtig, weshalb der Rückgang vertretbar ist.

• Die Schreib-QPS an den Leader steigen um 20~30%. Dies liegt daran, dass wir die Raft-Hauptschleife von der Schleife zum Anwenden der Einträge entkoppeln, sodass sie sich nicht gegenseitig blockieren.

• Die Schreib-QPS an alle Server steigen um 30~80%, weil Follower den neuesten Commit-Index früher erhalten und Vorschläge schneller festschreiben können.

6 - Benchmarks für etcd v2.2.0

Physische Rechner

GCE-Rechnertyp n1-highcpu-2

• 1x dedizierte lokale SSD, als etcd-Datenverzeichnis eingebunden
• 1x dedizierter langsamer Datenträger für das Betriebssystem
• 1.8 GB Arbeitsspeicher
• 2x CPUs

etcd-Cluster

3 etcd-2.2.0-Mitglieder, jeweils auf einem eigenen Rechner.

Versionsdetails:

etcd Version: 2.2.0
Git SHA: e4561dd
Go Version: go1.5
Go OS/Arch: linux/amd64

Testverfahren

Einen weiteren Rechner außerhalb des etcd-Clusters einrichten und das HTTP-Benchmarkwerkzeug hey mit einem Patch zur Wiederverwendung von Verbindungen ausführen, um Anfragen an jedes Clustermitglied zu senden. Die Benchmark-Anleitung enthält den Patch und die Schritte zum Reproduzieren unserer Vorgehensweise.

Die Leistung wird aus den Ergebnissen von 100 Benchmark-Durchläufen berechnet.

Leistung

Leseleistung für einen einzelnen Schlüssel

Schreibleistung für einen einzelnen Schlüssel

Leistungsänderungen

• Da etcd jetzt für jeden API-Aufruf Metriken erfasst, scheinen die Lese-QPS in den meisten Szenarien geringfügig zu sinken. Angesichts der umfangreichen Informationen für Überwachung und Fehlersuche wurde dieser minimale Leistungsverlust als vertretbar eingeschätzt.

• Die Schreib-QPS an Cluster-Leader scheinen leicht gestiegen zu sein. Ursache ist die Entkopplung der Hauptschleife von den Schleifen zum Anwenden der Einträge in der Raft-Logik von etcd. Dadurch entfallen mehrere gegenseitige Blockierungen.

• Die Schreib-QPS an alle Mitglieder scheinen erheblich gestiegen zu sein, weil Follower den neuesten Commit-Index jetzt früher erhalten und Vorschläge schneller festschreiben.

7 - Benchmarks für etcd v2.1.0

Physische Rechner

GCE-Rechnertyp n1-highcpu-2

• 1x dedizierte lokale SSD, unter /var/lib/etcd eingebunden
• 1x dedizierter langsamer Datenträger für das Betriebssystem
• 1.8 GB Arbeitsspeicher
• 2x CPUs
• etcd-Version 2.1.0 alpha

etcd-Cluster

3 etcd-Mitglieder, jeweils auf einem eigenen Rechner

Testverfahren

Einen weiteren Rechner einrichten und mit dem HTTP-Benchmarkwerkzeug hey Anfragen an jedes etcd-Mitglied senden. Eine ausführliche Anleitung enthält der Leitfaden zur Benchmark-Entwicklung .

Leistung

Einen einzelnen Schlüssel lesen

Einen einzelnen Schlüssel schreiben