MongoDB
 sql >> Base de données >  >> NoSQL >> MongoDB

Une feuille de triche de performance pour MongoDB

Les performances de la base de données affectent les performances organisationnelles et nous avons tendance à rechercher une solution rapide. Il existe de nombreuses façons d'améliorer les performances dans MongoDB. Dans ce blog, nous vous aiderons à mieux comprendre la charge de travail de votre base de données et les éléments qui peuvent lui nuire. Savoir comment utiliser des ressources limitées est essentiel pour quiconque gère une base de données de production.

Nous allons vous montrer comment identifier les facteurs qui limitent les performances de la base de données. Pour nous assurer que la base de données fonctionne comme prévu, nous allons commencer à partir de l'outil de surveillance gratuit MongoDB Cloud. Ensuite, nous verrons comment gérer les fichiers journaux et comment examiner les requêtes. Pour être en mesure d'optimiser l'utilisation des ressources matérielles, nous examinerons l'optimisation du noyau et d'autres paramètres cruciaux du système d'exploitation. Enfin, nous examinerons la réplication MongoDB et comment examiner les performances.

Surveillance gratuite des performances

MongoDB a introduit un outil gratuit de surveillance des performances dans le cloud pour les instances autonomes et les jeux de répliques. Lorsqu'elles sont activées, les données surveillées sont téléchargées périodiquement sur le service cloud du fournisseur. Cela ne nécessite aucun agent supplémentaire, la fonctionnalité est intégrée au nouveau MongoDB 4.0+. Le processus est assez simple à configurer et à gérer. Après l'activation de la commande unique, vous obtiendrez une adresse Web unique pour accéder à vos statistiques de performances récentes. Vous ne pouvez accéder qu'aux données surveillées qui ont été téléchargées au cours des dernières 24 heures.

Voici comment activer cette fonctionnalité. Vous pouvez activer/désactiver la surveillance gratuite pendant l'exécution en utilisant :

-- Enable Free Monitoring
db.enableFreeMonitoring()
-- Disable Free Monitoring
db.disableFreeMonitoring()

Vous pouvez également activer ou désactiver la surveillance gratuite lors du démarrage de mongod à l'aide du paramètre de fichier de configuration cloud.monitoring.free.state ou de l'option de ligne de commande --enableFreeMonitoring

db.enableFreeMonitoring()

Après l'activation, vous verrez un message avec le statut actuel.

{
    "state" : "enabled",
    "message" : "To see your monitoring data, navigate to the unique URL below. Anyone you share the URL with will also be able to view this page. You can disable monitoring at any time by running db.disableFreeMonitoring().",
    "url" : "https://cloud.mongodb.com/freemonitoring/cluster/XEARVO6RB2OTXEAHKHLKJ5V6KV3FAM6B",
    "userReminder" : "",
    "ok" : 1
}

Copiez/collez simplement l'URL de la sortie d'état dans le navigateur, et vous pouvez commencer à vérifier les mesures de performance.

La surveillance MongoDB Free fournit des informations sur les métriques suivantes :

  • Temps d'exécution des opérations (LECTURE, ÉCRITURE, COMMANDES)
  • Utilisation du disque (% UTIL MAX DE TOUT LECTEUR, % UTILISATION MOYENNE DE TOUS LES LECTEURS)
  • Mémoire (RÉSIDENTE, VIRTUELLE, MAPPÉE)
  • Réseau - Entrée/Sortie (BYTES IN, BYTES OUT)
  • Réseau - Nombre de requêtes (NUM REQUESTS)
  • Opcounters (INSERT, QUERY, UPDATE, DELETE, GETMORE, COMMAND)
  • Opcounters - Réplication (INSERT, QUERY, UPDATE, DELETE, GETMORE, COMMAND)
  • Ciblage des requêtes (SCANNED/RENVOYÉ, OBJETS SCANNÉS/RENVOYÉS)
  • Files d'attente (LECTEURS, ÉCRIVAINS, TOTAL)
  • Utilisation du processeur système (USER, NICE, KERNEL, IOWAIT, IRQ, SOFT IRQ, STEAL, GUEST)
MongoDB Free Monitoring première utilisation Utilisation du processeur du système de surveillance gratuit MongoDB MongoDB Free Monitoring Charts

Pour afficher l'état de votre service de surveillance gratuit, utilisez la méthode suivante :

db.getFreeMonitoringStatus()

Le serverStatus et l'assistant db.serverStatus() incluent également des statistiques de surveillance gratuites dans le champ de surveillance gratuit.

Lors de l'exécution avec contrôle d'accès, l'utilisateur doit disposer des privilèges suivants pour activer la surveillance gratuite et obtenir l'état :

{ resource: { cluster : true }, actions: [ "setFreeMonitoring", "checkFreeMonitoringStatus" ] }

Cet outil peut être un bon début pour ceux qui ont du mal à lire la sortie d'état du serveur MongoDB à partir de la ligne de commande :

db.serverStatus()

Free Monitoring est un bon début mais il a des options très limitées, si vous avez besoin d'un outil plus avancé, vous pouvez vérifier MongoDB Ops Manager ou ClusterControl.

Enregistrement des opérations de base de données

Les pilotes MongoDB et les applications clientes peuvent envoyer des informations au fichier journal du serveur. Ces informations dépendent du type d'événement. Pour vérifier les paramètres actuels, connectez-vous en tant qu'administrateur et exécutez :

db.getLogComponents()

Les messages de journal incluent de nombreux composants. Il s'agit de fournir une catégorisation fonctionnelle des messages. Pour chacun des composants, vous pouvez définir une verbosité de journal différente. La liste actuelle des composants est :

ACCESS, COMMAND, CONTROL, FTD, GEO, INDEX, NETWORK, QUERY, REPL_HB, REPL, ROLLBACK, REPL, SHARDING, STORAGE, RECOVERY, JOURNAL, STORAGE, WRITE.

Pour plus de détails sur chacun des composants, consultez la documentation.

Capturer des requêtes - Database Profiler

MongoDB Database Profiler collecte des informations sur les opérations qui s'exécutent sur une instance mongod. Par défaut, le profileur ne collecte aucune donnée. Vous pouvez choisir de collecter toutes les opérations (valeur 2), ou celles qui prennent plus de temps que la valeur de slowms . Ce dernier est un paramètre d'instance qui peut être contrôlé via le fichier de configuration mongodb. Pour vérifier le niveau actuel :

db.getProfilingLevel()

Pour capturer toutes les requêtes définies :

db.setProfilingLevel(2)

Dans le fichier de configuration, vous pouvez définir :

profile = <0/1/2>
slowms = <value>

Ce paramètre sera appliqué sur une seule instance et ne se propagera pas sur un jeu de répliques ou un cluster partagé. Vous devez donc répéter cette commande sur tous les nœuds si vous souhaitez capturer toutes les activités. Le profilage de la base de données peut avoir un impact sur les performances de la base de données. N'activez cette option qu'après mûre réflexion.

Puis pour lister les 10 plus récents :

db.system.profile.find().limit(10).sort(
{ ts : -1 }
).pretty()

Pour tout lister :

db.system.profile.find( { op:
{ $ne : 'command' }
} ).pretty()

Et pour répertorier une collection spécifique :

db.system.profile.find(
{ ns : 'mydb.test' }
).pretty()

Journalisation MongoDB

L'emplacement du journal MongoDB est défini dans le paramètre logpath de votre configuration, et il s'agit généralement de /var/log/mongodb/mongod.log. Vous pouvez trouver le fichier de configuration MongoDB sur /etc/mongod.conf.

Voici un exemple de données :

2018-07-01T23:09:27.101+0000 I ASIO     [NetworkInterfaceASIO-Replication-0] Connecting to node1:27017
2018-07-01T23:09:27.102+0000 I ASIO     [NetworkInterfaceASIO-Replication-0] Failed to connect to node1:27017 - HostUnreachable: Connection refused
2018-07-01T23:09:27.102+0000 I ASIO     [NetworkInterfaceASIO-Replication-0] Dropping all pooled connections to node1:27017 due to failed operation on a connection
2018-07-01T23:09:27.102+0000 I REPL_HB  [replexec-2] Error in heartbeat (requestId: 21589) to node1:27017, response status: HostUnreachable: Connection refused
2018-07-01T23:09:27.102+0000 I ASIO     [NetworkInterfaceASIO-Replication-0] Connecting to node1:27017

Vous pouvez modifier la verbosité du journal du composant en définissant (exemple de requête) :

db.setLogLevel(2, "query")

Le fichier journal peut être important, vous pouvez donc l'effacer avant le profilage. Depuis la console de ligne de commande MongoDB, entrez :

db.runCommand({ logRotate : 1 });

Vérification des paramètres du système d'exploitation

Limites de mémoire

Pour voir les limites associées à votre connexion, utilisez la commande ulimit -a. Les seuils et paramètres suivants sont particulièrement importants pour les déploiements mongod et mongos :

-f (file size): unlimited
-t (cpu time): unlimited
-v (virtual memory): unlimited
-n (open files): 64000
-m (memory size): unlimited [1]
-u (processes/threads): 32000

La nouvelle version du script de démarrage mongod (/etc/init.d/mongod) a les paramètres par défaut intégrés dans l'option de démarrage :

start()
{
  # Make sure the default pidfile directory exists
  if [ ! -d $PIDDIR ]; then
    install -d -m 0755 -o $MONGO_USER -g $MONGO_GROUP $PIDDIR
  fi

  # Make sure the pidfile does not exist
  if [ -f "$PIDFILEPATH" ]; then
      echo "Error starting mongod. $PIDFILEPATH exists."
      RETVAL=1
      return
  fi

  # Recommended ulimit values for mongod or mongos
  # See http://docs.mongodb.org/manual/reference/ulimit/#recommended-settings
  #
  ulimit -f unlimited
  ulimit -t unlimited
  ulimit -v unlimited
  ulimit -n 64000
  ulimit -m unlimited
  ulimit -u 64000
  ulimit -l unlimited

  echo -n $"Starting mongod: "
  daemon --user "$MONGO_USER" --check $mongod "$NUMACTL $mongod $OPTIONS >/dev/null 2>&1"
  RETVAL=$?
  echo
  [ $RETVAL -eq 0 ] && touch /var/lock/subsys/mongod
}

Le rôle du sous-système de gestion de la mémoire également appelé gestionnaire de mémoire virtuelle est de gérer l'allocation de la mémoire physique (RAM) pour l'ensemble du noyau et des programmes utilisateur. Ceci est contrôlé par les paramètres vm.*. Il y en a deux que vous devriez considérer en premier lieu afin d'ajuster les performances de MongoDB - vm.dirty_ratio et vm.dirty_background_ratio .

vm.dirty_ratio est la quantité maximale absolue de mémoire système pouvant être remplie de pages modifiées avant que tout ne soit validé sur le disque. Lorsque le système arrive à ce stade, toutes les nouvelles E/S se bloquent jusqu'à ce que les pages modifiées aient été écrites sur le disque. C'est souvent la source de longues pauses d'E/S. La valeur par défaut est 30, ce qui est généralement trop élevé. vm.dirty_background_ratio est le pourcentage de mémoire système qui peut être rempli de pages "sales" - pages de mémoire qui doivent encore être écrites sur le disque. Le bon début est de partir de 10 et de mesurer les performances. Pour un environnement à faible mémoire, 20 est un bon début. Un paramètre recommandé pour les taux de modification sur les serveurs de base de données à grande mémoire est vm.dirty_ratio =15 et vm.dirty_background_ratio =5 ou éventuellement moins.

Pour vérifier le rapport sale, procédez comme suit :

sysctl -a | grep dirty

Vous pouvez le définir en ajoutant les lignes suivantes à "/etc/sysctl.conf":

Échange

Sur les serveurs où MongoDB est le seul service en cours d'exécution, il est recommandé de définir vm.swapiness =1. Le paramètre par défaut est défini sur 60, ce qui n'est pas approprié pour un système de base de données.

vi /etc/sysctl.conf
vm.swappiness = 1

Grandes pages transparentes

Si vous exécutez votre MongoDB sur RedHat, assurez-vous que Transparent Huge Pages est désactivé.
Cela peut être vérifié par la commande :

cat /proc/sys/vm/nr_hugepages 
0

0 signifie que les grandes pages transparentes sont désactivées.

Options du système de fichiers

ext4 rw,seclabel,noatime,data=ordered 0 0

NUMA (accès mémoire non uniforme)

MongoDB ne prend pas en charge NUMA, désactivez-le dans le BIOS.

Pile réseau

net.core.somaxconn = 4096
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_time = 120
net.ipv4.tcp_max_syn_backlog = 4096

Démon NTP

Pour installer le démon du serveur de temps NTP, utilisez l'une des commandes système suivantes.

#Red Hat
sudo yum install ntp
#Debian
sudo apt-get install ntp

Vous pouvez trouver plus de détails sur les performances du système d'exploitation pour MongoDB dans un autre blog.

Expliquer le plan

Semblable à d'autres systèmes de base de données populaires, MongoDB fournit une fonction d'explication qui révèle comment une opération de base de données a été exécutée. Les résultats d'explication affichent les plans de requête sous la forme d'une arborescence d'étapes. Chaque étape transmet ses événements (c'est-à-dire les documents ou les clés d'index) au nœud parent. Les nœuds feuilles accèdent à la collection ou aux index. Vous pouvez ajouter EXPLAIN('executionStats') à une requête.

db.inventory.find( {
     status: "A",
     $or: [ { qty: { $lt: 30 } }, { item: /^p/ } ]
} ).explain('executionStats');
or append it to the collection:
db.inventory.explain('executionStats').find( {
     status: "A",
     $or: [ { qty: { $lt: 30 } }, { item: /^p/ } ]
} );

Les clés dont vous devez surveiller les valeurs dans la sortie de l'exécution de la commande ci-dessus :

  • totalKeysExamined :nombre total d'entrées d'index analysées pour renvoyer la requête.
  • totalDocsExamined :nombre total de documents numérisés pour trouver les résultats.
  • executionTimeMillis :temps total en millisecondes requis pour la sélection du plan de requête et l'exécution de la requête.

Mesurer les performances du décalage de réplication

Le décalage de réplication est un délai entre une opération sur le primaire et l'application de cette opération de l'oplog au secondaire. En d'autres termes, il définit la distance entre le nœud secondaire et le nœud principal, qui, dans le meilleur des cas, devrait être aussi proche que possible de 0.

Le processus de réplication peut être affecté pour plusieurs raisons. L'un des principaux problèmes pourrait être que les membres secondaires manquent de capacité de serveur. Opérations d'écriture volumineuses sur le membre principal, empêchant les membres secondaires de relire les oplogs ou création d'index sur le membre principal.

Pour vérifier le décalage de réplication actuel, exécutez-le dans un shell MongoDB :

db.getReplicationInfo()
db.getReplicationInfo() 
{
    "logSizeMB" : 2157.1845703125,
    "usedMB" : 0.05,
    "timeDiff" : 4787,
    "timeDiffHours" : 1.33,
    "tFirst" : "Sun Jul 01 2018 21:40:32 GMT+0000 (UTC)",
    "tLast" : "Sun Jul 01 2018 23:00:19 GMT+0000 (UTC)",
    "now" : "Sun Jul 01 2018 23:00:26 GMT+0000 (UTC)"

La sortie de l'état de la réplication peut être utilisée pour évaluer l'état actuel de la réplication et déterminer s'il existe un retard de réplication involontaire.

rs.printSlaveReplicationInfo()

Il montre le délai entre les membres secondaires par rapport au primaire.

rs.status()

Il montre les détails détaillés pour la réplication. Nous pouvons collecter suffisamment d'informations sur la réplication en utilisant ces commandes. Espérons que ces conseils donnent un aperçu rapide de la façon d'examiner les performances de MongoDB. Faites-nous savoir si nous avons oublié quelque chose.