Tous les produits
Search
Centre de documentation

ApsaraDB for MongoDB:Test de charge du nombre maximal de connexions sur une instance en cluster de réplication

Dernière mise à jour :Aug 20, 2026

Cette rubrique explique comment tester le nombre maximal de connexions sur plusieurs instances en cluster de réplication ApsaraDB for MongoDB de différentes spécifications. Le test consiste à accéder aux instances ApsaraDB for MongoDB depuis une instance Elastic Compute Service (ECS).

Environnement de test

Créez une instance ECS et une instance ApsaraDB for MongoDB. Pour plus d'informations, consultez les rubriques Créer une instance en cluster de réplication et Créer une instance ECS.

Le tableau suivant présente la configuration de l'instance ECS et des instances ApsaraDB for MongoDB utilisées pour le test.

Élément de configuration

Instance ECS

Instance ApsaraDB for MongoDB utilisant des disques cloud

Instance ApsaraDB for MongoDB utilisant des disques locaux

Région et zone

Zone H de Pékin

Zone H de Pékin

Zone H de Pékin

Type de réseau

Virtual Private Cloud (VPC)

VPC

VPC

Catégorie d'instance

c6e, famille d'instances optimisées pour le calcul avec performances améliorées

Généraliste et dédiée

Généraliste et dédiée

Type d'instance

ecs.c6e.2xlarge

Trois types d'instance disponibles. Pour plus d'informations, consultez la section Résultats du test.

Deux types d'instance disponibles. Pour plus d'informations, consultez la section Résultats du test.

Type de stockage

Disques ESSD AutoPL (Enterprise SSD)

Disques ESSD

SSD locaux

Image ou version du moteur

Alibaba Cloud Linux 3.2104 LTS 64 bits

4.19.91-26.al7.x86_64

3.10.0-327.ali2017.alios7.x86_64

Version du noyau

N/A

  • Version majeure : MongoDB 4.4

  • Référence de la version mineure : 4.4.28

  • Version majeure : MongoDB 4.2

  • Référence de la version mineure : 4.2.23

  • L'instance ApsaraDB for MongoDB utilisée pour le test repose sur une architecture à trois nœuds composée d'un nœud principal, d'un nœud secondaire et d'un nœud masqué.

  • L'instance ECS et l'instance ApsaraDB for MongoDB utilisées pour le test sont déployées dans la même zone de la même région, avec un temps aller-retour moyen (RTT) de 0 103 ms.

Outil de test

  • Le test utilise l'outil open source Yahoo Cloud Serving Benchmark (YCSB) 0.17.0.

    Remarque

    YCSB est un outil Java permettant d'évaluer les performances de plusieurs types de bases de données. Pour plus d'informations sur l'installation et l'utilisation de YCSB, consultez la page YCSB.

  • Le test utilise également un programme personnalisé de test de charge des connexions. Pour plus d'informations, consultez la section Informations complémentaires sur un test de charge de 96 000 connexions.

Méthode de test

  1. Ajoutez l'primary private IP address de l'instance ECS à la liste d'autorisation de l'instance ApsaraDB for MongoDB. Pour plus d'informations, consultez la rubrique Modifier une liste d'autorisation.

    Remarque

    Connectez-vous à la console ECS et consultez l'Primary Private IP Address de l'instance ECS dans la section Configuration Information de la page Instance Details.

  2. Connectez-vous à l'instance ECS. Pour plus d'informations, consultez la rubrique Créer et gérer une instance ECS à l'aide de la console ECS (version express).

  3. Chargez les données de test à l'aide de l'outil YCSB.

    ./bin/ycsb.sh load mongodb -s -p workload=site.ycsb.workloads.CoreWorkload -p recordcount=10000000 -p mongodb.url="mongodb://test:****@dds-bp13e84d11****.mongodb.rds.aliyuncs.com:3717/admin" -p table=test -threads 8

    Modifiez les paramètres suivants :

    • recordcount=1000000 : quantité totale de données chargées dans l'instance ApsaraDB for MongoDB.

    • mongodb.url="mongodb://test:**@dds-bp13e84d11**.mongodb.rds.aliyuncs.com:3717/admin" : chaîne de connexion de l'instance ApsaraDB for MongoDB. Lors du test, le compte de base de données est test et la base de données est admin.

      Remarque

      Connectez-vous à la console ApsaraDB for MongoDB. Sur la page Database Connection, consultez la chaîne de connexion dans la section Internal Connections - VPC.

    • threads 8 : nombre de threads simultanés sur le client utilisé pour le test.

  4. Exécutez la commande suivante pour lancer le test de charge des performances :

    ./bin/ycsb.sh run mongodb -s -p workload=site.ycsb.workloads.CoreWorkload -p recordcount=10000000 -p operationcount=5000000 -p readproportion=50 -p updateproportion=50 -p requestdistribution=zipfian -p mongodb.url="mongodb://test:****@dds-bp13e84d11****.mongodb.rds.aliyuncs.com:3717/admin?maxPoolSize=8000" -p table=test -threads 8000

    Modifiez les paramètres suivants :

    • recordcount=1000000 : quantité totale de données chargées dans l'instance ApsaraDB for MongoDB.

    • operationcount=5000000 : nombre total d'opérations de lecture et d'écriture.

    • insertproportion=0 : ratio des opérations de chargement.

    • readproportion=50 : ratio des opérations de lecture.

    • updateproportion=50 : ratio des opérations de mise à jour.

    • mongodb.url="mongodb://test:**@dds-bp13e84d11**.mongodb.rds.aliyuncs.com:3717/admin" : chaîne de connexion de l'instance ApsaraDB for MongoDB. Lors du test, le compte de base de données est test et la base de données est admin.

      Remarque
      • Connectez-vous à la console ApsaraDB for MongoDB. Sur la page Database Connection, consultez la chaîne de connexion dans la section Internal Connections - VPC.

      • Spécifiez le paramètre maxPoolSize. Sinon, la valeur par défaut de 100 est utilisée, ce qui provoque une erreur MongoWaitQueueFullException empêchant le test d'atteindre la limite de connexions cible.

  5. Consultez les informations de surveillance de l'instance ApsaraDB for MongoDB utilisée pour le test. Pour plus d'informations, consultez la rubrique Surveillance des nœuds (anciennement surveillance de base).

    Dans l'onglet node monitoring, sélectionnez la plage horaire du test pour afficher les métriques CPU Utilization, Memory Usage, QPS, Connections et Connection Usage de l'instance.

Informations complémentaires sur un test de charge de 96 000 connexions

YCSB dépend de l'environnement Java, et la machine virtuelle Java (JVM) impose une limite maximale de taille du tas. Lorsque vous exécutez un test avec une concurrence élevée (threads > 20 000), une erreur Cannot allocate memory se produit, comme illustré dans l'exemple suivant, et le test s'arrête.

OpenJDK 64-Bit Server VM warning: Attempt to protect stack guard pages failed.
OpenJDK 64-Bit Server VM warning: DBWrapper: report latency for each error is false and specific error codes to track for latency are: []INFO: os rrno=12)
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 12288 bytes for committing reserved memory.
OpenJDK 64-Bit Server VM warning: Attempt to protect stack guard pages failed.
# An error report file with more information is saved as:
# /root/ycsb-0.17.0/hs_err_pid101727.log
DBWrapper: report latency for each error is false and specific error codes to track for latency are: []
OpenJDK 64-Bit Server VM warning: Attempt to protect stack guard pages failed.
DBWrapper: report latency for each error is false and specific error codes to track for latency are: []OpenJDK 64-Bit Server VM warning: Attempt to protect stack guard pages failed.
OpenJDK 64-Bit Server VM warning: DBWrapper: report latency for each error is false and specific error codes to track for latency are: []INFO: os rrno=12)
[thread 140023352145472 also had an error]
OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00007f59ba0a2000, 12288, 0) failed; error='Cannot allocate memory' (errno=12)

L'erreur persiste même après augmentation de la valeur du paramètre JAVA_OPTS. Pour résoudre ce problème, utilisez un programme personnalisé de test de charge des connexions. Ce programme génère cycliquement plusieurs threads. Chaque thread crée un MongoClient. Après avoir effectué une requête, le MongoClient maintient les connexions pendant un certain temps sans les libérer.

Une seule machine exécutant un client de test de charge dispose d'un nombre limité de ports. Elle ne peut donc pas satisfaire aux exigences du test de charge des connexions (jusqu'à 96 000 connexions) avec une spécification de 32 cœurs et 128 Go de mémoire. Dans ce cas, vous devez exécuter le même programme de test de charge sur plusieurs machines.

Exécutez la commande Bash suivante pour interroger la plage de ports actuelle d'une machine :

sysctl net.ipv4.ip_local_port_range

Exemple de résultat :

net.ipv4.ip_local_port_range = 40000    65535

Exécutez la commande suivante pour étendre la plage de ports d'une machine, puis lancez le test de charge des connexions :

sudo sysctl -w net.ipv4.ip_local_port_range="10240 65535"

Résultats du test

Instance utilisant des disques ESSD

Instance dédiée disposant de 4 cœurs et de 8 Go de mémoire

Nombre maximal de connexions : 8 000

QPS

Connections

Connection utilization

CPU utilization

Memory usage

image.png

image.png

image.png

image.png

image.png

Remarque

En raison de la granularité d'échantillonnage au niveau de la minute de la vue de surveillance des nœuds, le graphique n'affiche pas le pic de 8 000 connexions. Vous pouvez confirmer ce pic en utilisant une surveillance plus granulaire ou en vérifiant le sous-document connections dans la sortie serverStatus.

mgset-xxx:PRIMARY> db.serverStatus().connections
{
        "current" : 7854,
        "available" : 146,
        "totalCreated" : 7857,
        "internal_current" : 27,
        "internal_available" : 7973,
        "internal_totalCreated" : 7029,
        "active" : 9,
        "exhaustIsMaster" : 4,
        "exhaustHello" : 2,
        "awaitingTopologyChanges" : 6
}

Instance dédiée disposant de 32 cœurs et de 128 Go de mémoire

Nombre maximal de connexions : 96 000

QPS

Connections

Connection utilization

CPU utilization

Memory usage

image.png

image.png

image.png

image.png

image.png

Remarque

L'outil utilisé pour le test lorsque le nombre maximal de connexions est de 96 000 diffère de ceux utilisés pour les tests avec des nombres maximaux de connexions de 8 000 et 16 000. Par conséquent, les captures d'écran de surveillance précédentes relatives aux QPS, à l'utilisation du CPU et à l'utilisation de la mémoire présentent des divergences.

Instance généraliste disposant de 8 cœurs et de 32 Go de mémoire

Nombre maximal de connexions : 16 000

QPS

Connections

Connection utilization

CPU utilization

Memory usage

image.png

image.png

image.png

image.png

image.png

Instances utilisant des disques locaux

Instance généraliste disposant de 16 cœurs et de 64 Go de mémoire

Nombre maximal de connexions : 32 000

QPS

Connections

Connection utilization

CPU utilization

Memory usage

image.png

image.png

image.png

image.png

image.png

Remarque

Si vous spécifiez une granularité de collecte au niveau de la minute dans l'onglet Node Monitoring, le nombre de connexions à certains moments n'est pas surveillé pour une instance généraliste disposant de 16 cœurs et de 64 Go de mémoire, en raison des délais d'expiration des commandes de collecte causés par une utilisation du CPU à 100 %. Dans ce cas, des creux au niveau de la minute apparaissent, mais le nombre réel de connexions à ces moments reste de 32 000.

Instance dédiée disposant de 2 cœurs et de 16 Go de mémoire

Nombre maximal de connexions : 8 000

QPS

Connections

Connection utilization

CPU utilization

Memory usage

image.png

image.png

image.png

image.png

image.png

Résumé

  • Les instances en cluster de réplication ApsaraDB for MongoDB de différentes spécifications et types de stockage peuvent atteindre le nombre maximal de connexions correspondant à leurs spécifications.

  • Une fois le nombre maximal de connexions atteint, ApsaraDB for MongoDB rejette les connexions suivantes. Les requêtes subissent une latence élevée ou restent bloquées dans votre application en raison de l'échec d'établissement des connexions.

  • Un nombre plus élevé de connexions simultanées consomme davantage de ressources, telles que le CPU et la mémoire. Nous vous recommandons d'ajuster le nombre de connexions à votre instance en fonction de vos besoins métier.