Comment les performances de la mémoire et du disque affectent votre base de données MongoDB

Cet article a été initialement publié dans MongoDB. Merci aux partenaires qui soutiennent SitePoint comme possible.

Comprendre la relation entre divers caches internes et les performances du disque et comment ces relations affectent la base de données et les performances des applications peuvent être difficiles. Nous avons utilisé des repères YCSB pour modifier l'ensemble de travail (le nombre de documents utilisés dans le test) et les performances du disque pour mieux démontrer leur relation. Lors de l'examen des résultats, nous introduirons certains mécanismes internes MongoDB pour améliorer la compréhension des modèles d'utilisation de la base de données communs.

Points clés

1. Comprendre les performances de base du disque est essentielle pour comprendre les performances globales de la base de données.
2. Le temps d'attente et l'utilisation du disque élevé indiquent un goulot d'étranglement du disque.
3. wiredtiger io est aléatoire.
4. Les requêtes pour un seul ensemble de répliques sont uniquement enfilées et séquentielles.
5. Les performances du disque sont étroitement liées à la taille de l'ensemble de travail.

Résumé

Les principales influences des performances globales du système sont la façon dont l'ensemble de travail est lié à la taille du cache du moteur de stockage (mémoire dédiée au stockage des données) et aux performances du disque (elle fournit une limitation physique de la rapidité avec laquelle les données sont accessibles).

En utilisant YCSB, nous avons exploré l'interaction entre les performances du disque et la taille du cache, démontrant comment ces deux facteurs affectent les performances. Bien que ce test utilise le YCSB, les repères synthétiques ne peuvent pas représenter les charges de travail de production. Les nombres de latence et de débit obtenus par ces méthodes ne mappent pas les performances de production. Nous avons utilisé MongoDB 3.4.10, YCSB 0.14 et MongoDB 3.6.0 pour ces tests. YCSB est configuré avec 16 threads et des charges de travail en lecture seule "uniformes".

Nous démontrons que la mise en mémoire de la mémoire fournit des performances d'application optimales, et comme toute base de données, dépassant cette limite affecte négativement la latence et le débit global.

Comprendre les métriques du disque

Lorsque l'on considère les performances du disque, il existe quatre indicateurs importants:

1. Le débit de disque, ou le nombre de demandes multiplié par la taille des demandes. Ceci est généralement mesuré dans les mégaoctets par seconde. Les performances de lecture et d'écriture aléatoires dans la gamme 4KB représentent le mieux les charges de travail standard de la base de données. Notez que de nombreux fournisseurs de cloud limitent le débit de disque ou la bande passante.
2. Délai de disque. Sur Linux, ceci est représenté par Await, c'est-à-dire l'heure (en millisecondes) qui est faite de l'application au moment où les données sont écrites ou renvoyées à l'application. Pour les SSD, le retard est généralement inférieur à 3 millisecondes. Les disques durs sont généralement supérieurs à 7 millisecondes. La latence élevée signifie que le disque est difficile à suivre une charge de travail donnée.
3. IOPS de disque (opérations d'entrée / sortie par seconde). IOSTAT rapporte cette métrique comme TPS. Un fournisseur de cloud donné peut garantir un certain nombre de IOPS pour un lecteur donné. Si vous atteignez ce seuil, tout accès supplémentaire sera mis en file d'attente, ce qui entraînera un goulot d'étranglement du disque. Les périphériques NVME joints PCIe haut de gamme peuvent fournir 1 500 000 IOPS, tandis qu'un disque dur typique ne peut prendre en charge que 150 IOPS.
4. Utilisation du disque. Rapporté par Util dans IOSTAT. Linux a plusieurs files d'attente par appareil pour servir IO. L'utilisation indique le pourcentage de ces files d'attente dans un délai donné. Bien que ce nombre puisse être déroutant, c'est un bon indicateur de la santé globale du disque.

Performance du disque de test

Bien que les fournisseurs de cloud puissent fournir des seuils IOPS pour un volume et un disque donné, et les fabricants de disques publient des chiffres de performance attendus, les résultats réels de votre système peuvent varier. La réalisation de tests IO peut être très utile s'il y a un problème avec les performances du disque observées.

Nous utilisons généralement FIO (testeur IO flexible) pour les tests. Nous avons testé sur 10 Go de données, IoEngine est PSYNC et la plage de lecture se situe entre 4 Ko et 32 ​​Ko. Bien que le paramètre FIO par défaut ne représente pas les charges de travail Wiredtiger, nous avons constaté que cette configuration était une bonne approximation de l'utilisation du disque Wiredtiger.

Tous les tests sont répétés dans trois scénarios de disque:

scène 1

Paramètres de disque par défaut fournis par AWS C5 IO1 100 Go de volume. 5000 IOPS

• 1144 IOPS / 5025 lectures physiques / second / 99,85% Utilisation

scène 2

Limitez le disque à 600 IOPS et introduisez un délai de 7 millisecondes. Cela devrait refléter les performances d'un RAID10 typique avec un disque dur

• 134 IOPS / 150 lectures physiques / sec / 95,72% Utilisation

scène 3

limiter davantage le disque à 150 IOPS avec une latence de 7 millisecondes. Cela devrait simuler un disque dur normal.

• 34 IOPS / 150 lectures physiques / sec / 98,2% Utilisation

Query Comment servir à partir du disque?

Le moteur de stockage Wiredtiger exécute son propre cache. Par défaut, la taille du cache Wiredtiger est de 50% de la mémoire système moins 1 Go pour permettre d'autres processus système, les caches système de fichiers et les opérations internes MongoDB qui utilisent une mémoire supplémentaire (comme la création d'index, l'exécution de tri de mémoire, les résultats de déduplication, le score texte, rejoindre le traitement et l'agrégation) laissez suffisamment d'espace. Pour éviter la dégradation des performances de la plénitude du cache, lorsque l'utilisation dépasse 80%, Wiredtiger commencera automatiquement à éjecter les données de Cache. Pour nos tests, cela signifie que la taille du cache valide est (7634 Mo - 1024 Mo) *. 5 * .8 ou 2644 Mo.

Toutes les requêtes sont mises en cache par Wiredtiger. Cela signifie que la requête entraînera la lecture de l'index et du document dans le cache Wiredtiger via le cache du système de fichiers, puis renvoie le résultat. Sautez cette étape si les données demandées sont déjà en cache.

Wiredtiger utilise l'algorithme de compression Snappy pour stocker les documents par défaut. Toutes les données lues dans le cache du système de fichiers sont décompressées avant d'être stockées dans le cache Wiredtiger. Les index sont compressés par défaut avec le préfixe et sont compressés à la fois en disque et en cache Wiredtiger.

Le cache du système de fichiers est une structure du système d'exploitation utilisé pour stocker des fichiers fréquemment accessibles en mémoire pour un accès plus facile. Linux est très actif dans les fichiers en cache et essaiera de consommer toute la mémoire disponible à l'aide du cache du système de fichiers. Si plus de mémoire est nécessaire, le cache du système de fichiers est expulsé pour fournir plus de mémoire pour l'application.

Il s'agit d'un graphique animé montrant l'accès au disque à la collection YCSB générée par 100 opérations de lecture YCSB. Chaque opération est une seule recherche de _ID pour un seul document.

Le coin supérieur gauche représente le premier octet du fichier de collection Wiredtiger. La position du disque est incrémentée à droite et entoure. Chaque ligne représente un segment de 3,5 Mo du fichier de collecte Wiredtiger. L'accès est organisé en ordre chronologique et représenté par des cadres d'animation. L'accès est représenté par des carrés rouges et verts pour mettre en évidence l'accès actuel sur le disque.

3,5 Mo vs 4KB

Ici, nous voyons que notre fichier de données de collecte est lu dans la mémoire. Étant donné que les données sont stockées dans le B-Tree, nous devrons peut-être trouver l'emplacement du disque du document (petit accès) en accédant à un ou plusieurs emplacements sur le disque avant de pouvoir trouver et lire notre document (plus grand accès).

Cela démontre le modèle d'accès typique pour les requêtes MongoDB - les documents sont peu susceptibles d'être proches les uns des autres sur le disque. Cela montre également que même après s'être inséré, les documents sont peu susceptibles d'être dans des emplacements de disque continu.

Le moteur de stockage de Wiredtiger est conçu pour "Lire complète": il émettra une demande de lecture pour toutes les données requises à la fois. Cela nous amène à recommander de limiter les lectures d'avance sur le disque pour les déploiements Wiredtiger à zéro, car il est peu probable que l'accès ultérieur profite des données supplémentaires récupérées par les lectures avancées.

Les ensembles de travail conviennent au cache

Pour notre premier ensemble de tests, nous avons réglé le nombre d'enregistrements à 2 millions, ce qui a entraîné une taille totale des données et des indices de 2,43 Go, ou 92% du cache.

Ici, nous voyons la puissante performance de la scène 1 est de 76 113 demandes par seconde. En vérifiant les statistiques sur le cache du système de fichiers, nous avons observé que le taux de succès du cache Wiredtiger est de 100%, pas d'accès et aucun octet ne lut dans le cache du système de fichiers, ce qui signifie qu'aucun IO supplémentaire n'est nécessaire tout au long du test.

Comme prévu, dans le scénario 2 et le scénario 3, la modification des performances du disque (ajoutant 7 millisecondes et limitant les IOPS à 600 ou 150) a un impact minimal sur le débit (69, 579,5 et 70 252 opérations / sec, respectivement).

Le délai de réponse de 99% pour nos trois tests variait de 0,40 à 0,44 milliseconde.

L'ensemble de travail est plus grand que le cache Wiredtiger, mais il convient toujours au cache du système de fichiers

Le cache des systèmes d'exploitation moderne a fréquemment accédé aux fichiers pour améliorer les performances de lecture. Parce que le fichier est déjà en mémoire, l'accès au fichier mis en cache n'entraînera pas de lecture physique. Les statistiques de cache du système de fichiers affichées par la commande linux libre détaille la taille du cache du système de fichiers.

Lorsque nous avons augmenté le nombre de records de 2 millions à 3 millions, nous avons augmenté la taille totale des données et de l'indice à 3,66 Go, 38% plus importants que celui du service de cache Wiredtiger seul.

La métrique montre clairement que nous lisons une moyenne de 548 Mbps dans le cache Wiredtiger, mais lors de la vérification de la métrique du cache du système de fichiers, nous pouvons observer un taux de réussite de 99,9%.

Pour ce test, nous avons commencé à voir des baisses de performances, avec seulement 66 720 opérations effectuées par seconde, une diminution de 8% par rapport à notre ligne de base, tandis que notre ligne de base n'était que du service de cache Wiredtiger.

Comme prévu, dans ce cas, la diminution des performances du disque n'affecte pas significativement notre débit global (64 484 et 64 229 opérations, respectivement). La pénalité pour la lecture du cache du système de fichiers sera plus évidente lorsque les documents sont plus faciles à compresser ou si le CPU est un facteur limitant.

Nous avons remarqué une augmentation de 54% de la latence P99 à 0,53 à 55 ms.

L'ensemble de travail est légèrement plus grand que Wiredtiger et le cache du système de fichiers

Nous avons déterminé que Wiredtiger et le cache du système de fichiers fonctionnent ensemble pour fournir des données pour servir nos requêtes. Cependant, lorsque nous augmentons le nombre de records de 3 millions à 4 millions, nous ne pouvons plus tirer parti de ces caches pour servir les requêtes. Notre taille de données est passée à 4,8 Go, 82% plus grande que notre cache Wiredtiger.

Ici, nous avons lu le cache Wiredtiger à 257,4 Mbps. Le taux de hit du cache du système de fichiers est réduit à 93 à 96%, ce qui signifie que 4 à 7% des lectures conduisent à des lectures physiques du disque.

Changer les IOPS disponibles et la latence du disque a un impact énorme sur les performances de ce test.

Le retard de réponse du 99e centile augmente encore. Scène 1:19 millisecondes, scène 2: 171 millisecondes, scène 3: 770 millisecondes, qui sont 43 fois, 389 fois et 1751 fois par rapport à la situation dans la cache.

Par rapport à nos tests précédents qui étaient entièrement adaptés à la mise en cache, nous avons vu une réduction des performances de 75% lorsque MongoDB offre un 5000 IOPS complet. Le scénario 2 et le scénario 3 ont atteint 5139,5 et 737,95 opérations par seconde, respectivement, prouvant davantage le goulot d'étranglement IO.

L'ensemble de travail est beaucoup plus grand que le cache Wiredtiger et le système de fichiers

Passez à 5 millions d'enregistrements, nous augmentons les données et la taille de l'indice à 6,09 Go, ce qui est plus grand que notre cache combiné Wiredtiger et Système de fichiers. Nous voyons notre débit sous nos IOPS. Dans ce cas, nous servons toujours 81% des lectures de Wiredtiger à partir du cache du système de fichiers, mais les lectures du débordement du disque saturent notre IO. Nous voyons que les vitesses de lecture du cache du système de fichiers pour ce test sont 71, 8,3 et 1,9 Mbps.

Le retard de réponse du 99e centile augmente encore. Scénario 1: 22 ms, scénario 2: 199ms, scénario 3: 810ms, qui sont 52 fois, 454 fois et 1841 fois par rapport à la latence de réponse au cache. Ici, la modification des IOPS de disque affecte considérablement notre débit.

Résumé

Grâce à cette série de tests, nous avons prouvé deux points principaux.

1. Si l'ensemble de travail convient à la mise en cache, les performances du disque n'affectent pas grandement les performances de l'application.
2. Les performances du disque deviennent rapidement un facteur limitant du débit lorsque l'ensemble de travail dépasse la mémoire disponible.

Comprendre comment MongoDB exploite la mémoire et le disque est une partie importante de l'ajustement de la taille du déploiement et de la compréhension des performances. Le travail interne du moteur de stockage Wiredtiger tente de tirer le meilleur parti du matériel, mais la mémoire et le disque sont deux pièces d'infrastructure critiques qui affectent les caractéristiques de performance globales de la charge de travail.

Des questions fréquemment posées sur la mémoire et les performances du disque dans MongoDB

Comment MongoDB utilise-t-il la mémoire et l'espace disque?

MongoDB utilise la mémoire et l'espace disque pour stocker et gérer les données. Il utilise un système de fichiers mappé de mémoire pour le stockage de données, ce qui signifie qu'il mappe l'intégralité du fichier de données dans RAM. Cela permet à MongoDB de traiter efficacement les grands ensembles de données. Les détails de gestion des sous-systèmes de mémoire virtuelle du système d'exploitation, échangent des données dans et hors de la mémoire au besoin. D'un autre côté, l'espace disque est utilisé pour stocker les fichiers de données, les index et les journaux. MongoDB alloue automatiquement l'espace disque en gros morceaux pour optimiser les opérations d'écriture.

Quel est l'impact de l'utilisation des E / S à disque élevé dans MongoDB?

L'utilisation des E / S à disque élevé affectera sérieusement les performances de la base de données MongoDB. Il provoque des opérations de lecture et d'écriture plus lentes, ce qui peut réduire les performances globales de l'application. Ceci est particulièrement problématique pour les applications qui nécessitent un accès aux données en temps réel. Une utilisation élevée des E / S de disque peut également conduire à une utilisation accrue du processeur, car le système passe plus de temps à gérer les opérations du disque.

Comment surveiller l'utilisation de l'espace disque dans MongoDB?

MongoDB fournit plusieurs outils pour surveiller l'utilisation de l'espace disque. La commande db.stats () fournit un aperçu de haut niveau de la base de données, y compris la taille totale du fichier de données et de l'index. La commande db.collection.stats () fournit des informations plus détaillées sur une collection spécifique, y compris la taille des données et de l'index. De plus, MongoDB Atlas (un produit de base de données en tant que service fourni par MongoDB) fournit un ensemble complet d'outils de surveillance, y compris des alertes sur une utilisation à haut disque.

Comment résoudre l'utilisation élevée de l'espace disque dans MongoDB?

Il existe plusieurs stratégies pour traiter l'utilisation élevée de l'espace disque dans MongoDB. Une façon consiste à supprimer des données ou des collections inutiles. Une autre approche consiste à utiliser la commande compacte, qui défrags les fichiers de données et recycle l'espace disque inutilisé. Cependant, cette commande nécessite beaucoup d'espace disque libre et peut affecter les performances de la base de données. La rupture (distribue des données sur plusieurs serveurs) peut également aider à gérer l'utilisation de l'espace disque.

Qu'est-ce qu'un lecteur RAM et comment cela a-t-il à voir avec MongoDB?

Le lecteur RAM est un morceau de mémoire que le système d'exploitation considère comme un lecteur de disque. Parce que la RAM est beaucoup plus rapide que le stockage du disque, l'utilisation des lecteurs de RAM peut améliorer considérablement les performances des applications qui nécessitent un accès aux données à grande vitesse. Cependant, comme la RAM est volatile, les données stockées dans le lecteur RAM sont perdues lorsque le système redémarre. Dans le contexte de MongoDB, les lecteurs de RAM peuvent être utilisés pour stocker des données ou des index fréquemment accessibles pour améliorer les performances. Cependant, cela doit être fait avec prudence, car une perte de données peut se produire si le système redémarre.

Comment MongoDB gère-t-il la gestion de la mémoire?

MongoDB repose sur le système d'exploitation sous-jacent pour la gestion de la mémoire. Il utilise des systèmes de fichiers mappés de mémoire, permettant au sous-système de mémoire virtuel du système d'exploitation de gérer les détails des données en mémoire ainsi que des données sur le disque. Cette approche permet à MongoDB de traiter efficacement de grands ensembles de données, mais cela signifie également que l'utilisation de la mémoire de MongoDB peut être affectée par d'autres processus exécutés sur le même système.

Comment optimiser l'utilisation de la mémoire de MongoDB?

Il existe plusieurs stratégies pour optimiser l'utilisation de la mémoire de MongoDB. Une façon consiste à vous assurer que votre ensemble de travail convient à la mémoire. Les ensembles de travail sont fréquemment accessibles dans des parties de données. Si votre ensemble de travail convient à la mémoire, MongoDB peut éviter les opérations coûteuses d'E / S de disque. Une autre approche consiste à utiliser efficacement les index. Les index peuvent améliorer considérablement les performances de la requête, mais elles peuvent également consommer de la mémoire. Par conséquent, il est important de créer des index judicieusement et de surveiller leur impact sur l'utilisation de la mémoire.

Comment MongoDB gère-t-il les opérations d'E / S du disque?

MongoDB utilise des logs écrits pour assurer l'intégrité des données. Ils sont d'abord écrits dans le journal avant que toutes les modifications ne soient apportées au fichier de données. Cela permet à MongoDB de se remettre d'un accident ou d'une panne de courant. Cependant, l'exploitation forestière peut également augmenter les opérations d'E / S du disque, ce qui peut affecter les performances. Par conséquent, il est important de surveiller l'utilisation des E / S du disque et de prendre des mesures pour l'optimiser si nécessaire.

Comment optimiser les opérations d'E / S disque de MongoDB?

Il existe plusieurs stratégies pour optimiser les opérations d'E / S disque de MongoDB. Une façon consiste à utiliser un SSD, qui peut gérer plus de IOPS que les disques durs traditionnels. Une autre approche consiste à utiliser une configuration RAID optimisée pour les opérations d'écriture. De plus, vous pouvez ajuster les paramètres de journalisation de MongoDB pour réduire l'impact sur les E / S du disque. Cependant, cela doit être fait avec prudence, car il peut affecter l'intégrité des données.

Comment les performances de la mémoire et du disque affectent-elles les performances globales de la base de données MongoDB?

Les performances de la mémoire et du disque sont des facteurs clés dans les performances globales des bases de données MongoDB. Si votre ensemble de travail convient à la mémoire, MongoDB peut éviter les opérations coûteuses d'E / S de disque, ce qui peut considérablement améliorer les performances. De même, les opérations efficaces des E / S de disque peuvent améliorer les performances des opérations d'écriture et assurer l'intégrité des données. Par conséquent, il est important de surveiller et d'optimiser les performances de la mémoire et du disque pour assurer les meilleures performances des bases de données MongoDB.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!