Benchmarks

• 1: Benchmark de l'utilisation de la mémoire de stockage
• 2: Benchmark de l'utilisation mémoire de la surveillance
• 3: Benchmarking d'etcd v3
• 4: Benchmarking etcd v2.2.0-rc-memory
• 5: Benchmarking etcd v2.2.0-rc
• 6: Benchmarking d'etcd v2.2.0
• 7: Test de performance d'etcd v2.1.0

1 - Benchmark de l'utilisation de la mémoire de stockage

Deux composants du stockage etcd consomment de la mémoire physique. Le processus etcd alloue un index en mémoire afin d’accélérer la recherche des clés. La mémoire tampon de pages, gérée par le système d’exploitation, stocke les données récemment accessibles sur disque pour une réutilisation rapide.

L’index en mémoire stocke toutes les clés dans une structure de données arbre B , accompagnées de pointeurs vers les données sur disque (les valeurs). Chaque clé dans l’arbre B peut contenir plusieurs pointeurs, chacun faisant référence à une version différente de sa valeur. La consommation mémoire théorique de l’index en mémoire peut donc être approximée par la formule :

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

où c1 représente la surcharge liée aux métadonnées de clé et c2 la surcharge liée aux métadonnées de version.

Le graphique montre la structure détaillée de l’arbre B en mémoire.

                                In mem index

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

La mémoire du cache Page cache est gérée par le système d’exploitation et n’est pas traitée en détail dans ce document.

Environnement de test

Version etcd

• git head https://github.com/etcd-io/etcd/commit/776e9fb7be7eee5e6b58ab977c8887b4fe4d48db

Type de machine GCE n1-standard-2

• 7,5 Go de mémoire
• 2x processeurs

Utilisation mémoire de l’index en mémoire

Dans ce test, nous ne mesurons que la consommation mémoire de l’index en mémoire. L’objectif est de déterminer c1 et c2 mentionnés ci-dessus, afin de comprendre la limite maximale de consommation mémoire du stockage.

Nous calculons la consommation de mémoire à l’aide de Go runtime.ReadMemStats. Nous déterminons la différence entre le nombre total d’octets alloués avant la création de l’index et après sa création. Cette méthode ne reflète pas parfaitement la consommation de mémoire de l’index en mémoire mais permet toutefois d’observer le profil de consommation approximatif.

En fonction du résultat, nous pouvons calculer c1=120bytes, c2=30bytes. Nous n’avons besoin que de deux jeux de données pour calculer c1 et c2, car ce sont les seules variables inconnues dans la formule. Les valeurs c1=120bytes et c2=30bytes correspondent à la moyenne des 4 jeux de c1 et c2 que nous avons calculés. La surcharge liée aux métadonnées clés reste encore relativement importante (50 %) pour des paires clé-valeur de petite taille. Toutefois, il s’agit d’une amélioration significative par rapport au vieux magasin, qui présentait au moins une surcharge de 1000 %.

Utilisation mémoire globale

La consommation mémoire globale indique la quantité de mémoire RSS utilisée par etcd, y compris le stockage. La taille des valeurs devrait avoir très peu d’impact sur la consommation mémoire globale d’etcd, car les valeurs sont conservées sur disque et seules les valeurs fréquemment utilisées sont conservées en mémoire, gérées par le cache de pages du système d’exploitation.

En fonction des résultats, nous savons que la taille des valeurs n’a pas d’impact significatif sur la consommation mémoire. Une légère augmentation est observée en raison de données supplémentaires conservées dans le cache de page du système d’exploitation.

2 - Benchmark de l'utilisation mémoire de la surveillance

Un objectif principal d’etcd est de prendre en charge un très grand nombre d’observateurs effectuant une surveillance massivement étendue. etcd vise à supporter O(10k) clients, O(100K) flux de surveillance (O(10) flux par client) et O(10M) surveillance totale (O(100) surveillance par flux). La mémoire consommée par chaque surveillance individuelle représente la plus grande partie de l’utilisation globale d’etcd, et constitue donc le point focal des optimisations actuelles et futures.

Trois composants liés de la surveillance etcd consomment de la mémoire physique : chaque grpc.Conn, chaque flux de surveillance et chaque instance d’activité de surveillance. grpc.Conn maintient la connexion TCP réelle et l’état de connexion gRPC associé. Chaque grpc.Conn consomme environ 10 ko de mémoire, et peut avoir plusieurs flux de surveillance attachés.

Chaque flux de surveillance est une connexion HTTP2 indépendante qui consomme une autre quantité de mémoire O(10 ko). Plusieurs surveillance peuvent partager un même flux de surveillance.

La surveillance est la structure réelle qui suit les modifications apportées au magasin clé-valeur. Chaque surveillance ne doit consommer que < 1 Ko.

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

La consommation mémoire théorique de la surveillance peut être approximée par la formule suivante : memory = c1 * number_of_conn + c2 * avg_number_of_stream_per_conn + c3 * avg_number_of_watch_stream

Environnement de test

Version etcd

• git head https://github.com/etcd-io/etcd/commit/185097ffaa627b909007e772c175e8fefac17af3

Type de machine GCE n1-standard-2

• 7,5 Go de mémoire
• 2x processeurs

Utilisation mémoire globale

La consommation mémoire globale indique la quantité de RSS consommée par etcd, incluant les observateurs clients. Bien que le résultat puisse varier jusqu’à 10 %, il reste significatif, car l’objectif est de comprendre l’usage mémoire approximatif et le schéma d’allocation.

À partir des résultats du benchmark, nous pouvons estimer approximativement que c1 = 17kb, c2 = 18kb et c3 = 350bytes. Ainsi, chaque connexion cliente supplémentaire consomme 17 ko de mémoire, chaque flux supplémentaire consomme 18 ko de mémoire, et chaque surveillance supplémentaire n’entraîne qu’une augmentation de 350 octets. Un serveur etcd unique peut maintenir des millions de surveillance avec quelques gigaoctets de mémoire dans un cas normal.

3 - Benchmarking d'etcd v3

Machines physiques

Type de machine GCE n1-highcpu-2

• 1 disque SSD local dédiqué monté sous /var/lib/etcd
• 1 disque lent dédié pour le système d’exploitation
• 1,8 Go de mémoire
• 2 processeurs
• version etcd 2.2.0

etcd cluster

1 membre etcd en mode démonstration v3

Test

Utilisez l’outil de benchmark etcd v3 .

Performances

lecture d’une seule clé

Les performances sont presque identiques à celles obtenues avec un gestionnaire de serveur vide.

lecture d’une seule clé après mise

La performance avec un gestionnaire de serveur vide n’est pas affectée par une opération put. Le dégradé de performance doit donc être dû au package de stockage.

4 - Benchmarking etcd v2.2.0-rc-memory

Machine physique

Type de machine GCE n1-standard-2

• 1 disque SSD local dédié monté sous /var/lib/etcd
• 1 disque lent dédié pour le système d’exploitation
• 7,5 Go de mémoire
• 2 processeurs

etcd

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

Test

Démarrez un cluster etcd composé de 3 membres, chacun utilisant 2 cœurs.

La longueur du nom de clé est toujours de 64 octets, ce qui constitue une longueur raisonnable pour une clé moyenne.

Utilisation maximale mémoire

• etcd peut utiliser une mémoire maximale si un suiveur est défaillant et que le leader continue d’envoyer des instantanés.
• max RSS est la consommation mémoire maximale enregistrée sur 3 exécutions.

Seuil de taille des données

• Lorsque etcd atteint le seuil de taille des données, il peut déclencher facilement une élection de leader et rejeter une partie des propositions.
• Dans la plupart des cas, le cluster etcd fonctionne correctement s’il ne dépasse pas ce seuil. Si le fonctionnement est dégradé en raison d’une ressource insuffisante, réduisez la taille des données.

5 - Benchmarking etcd v2.2.0-rc

Machine physique

Type de machine GCE n1-highcpu-2

• 1 disque SSD local dédié monté sous /var/lib/etcd
• 1 disque lent dédié pour le système d’exploitation
• 1,8 Go de mémoire
• 2 processeurs

etcd cluster

3 membres etcd 2.2.0-rc, chacun exécuté sur une seule machine.

Versions détaillées :

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

En outre, nous utilisons 3 membres etcd 2.1.0 en phase alpha pour constituer le cluster et obtenir des performances de base. La tête du commit d’etcd est située à c7146bd5 , identique à celle utilisée dans benchmark etcd 2.1 .

Test

Initialisez une autre machine et utilisez l’outil de benchmark HTTP hey pour envoyer des requêtes à chaque membre etcd. Consultez le guide de manipulation du benchmark pour des instructions détaillées.

Performances

lecture d’une seule clé

écriture d’une seule clé

explication des modifications de performance

• Le QPS de lecture est généralement réduit de 5 à 8 % dans la plupart des scénarios. La raison en est que etcd enregistre des métriques pour chaque opération de stockage. Ces métriques sont importantes pour la surveillance et le débogage, ce qui rend cette réduction acceptable.

• Le QPS d’écriture vers le leader augmente de 20 à 30 %. Cela est dû à la déconnexion de la boucle principale Raft et de la boucle d’application des entrées, ce qui empêche leurs blocages mutuels.

• Le débit d’écriture QPS sur tous les serveurs augmente de 30 à 80 % car le suiveur peut recevoir plus tôt l’index de validation le plus récent et valider les propositions plus rapidement.

6 - Benchmarking d'etcd v2.2.0

Machines physiques

Type de machine GCE n1-highcpu-2

• 1 disque SSD local dédié monté en répertoire de données etcd
• 1 disque lent dédié pour le système d’exploitation
• 1,8 Go de mémoire
• 2 processeurs

etcd cluster

3 membres etcd 2.2.0, chacun exécuté sur une machine unique.

Versions détaillées :

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

Test

Initialisez une autre machine, en dehors du cluster etcd, puis exécutez l’outil de benchmark HTTP hey avec un correctif de réutilisation de connexion pour envoyer des requêtes à chaque membre du cluster etcd. Consultez les instructions de benchmark pour obtenir le correctif et les étapes permettant de reproduire nos procédures.

Les performances sont calculées à partir des résultats de 100 itérations de benchmark.

Performances

Performance de lecture d’une clé unique

Performance d’écriture pour une clé unique

Améliorations des performances

• Comme etcd enregistre désormais des métriques pour chaque appel d’API, la performance en QPS de lecture semble légèrement diminuer dans la plupart des scénarios. Ce léger impact sur les performances a été jugé acceptable en échange de la richesse des informations de surveillance et de débogage fournies.

• Le taux de requêtes d’écriture QPS vers les leaders du cluster semble avoir légèrement augmenté. Cela est dû au fait que la boucle principale et les boucles d’entrée ont été déconnectées dans la logique Raft d’etcd, éliminant plusieurs blocages entre elles.

• Le QPS d’écriture vers tous les membres semble avoir augmenté de manière significative, car les suiveurs reçoivent désormais l’index de validation le plus récent plus rapidement, et traitent les propositions de validation plus rapidement.

7 - Test de performance d'etcd v2.1.0

Machines physiques

Type de machine GCE n1-highcpu-2

• 1 disque SSD local dédié monté sous /var/lib/etcd
• 1 disque lent dédié pour le système d’exploitation
• 1,8 Go de mémoire
• 2 processeurs
• version etcd 2.1.0 alpha

etcd cluster

3 membres etcd, chacun exécuté sur une machine unique

Test

Initialisez une autre machine et utilisez l’outil de benchmark HTTP hey pour envoyer des requêtes à chaque membre etcd. Consultez le guide de manipulation du benchmark pour des instructions détaillées.

Performances

lecture d’une seule clé

écriture d’une seule clé