Todos os produtos
Search
Central de documentação

ApsaraDB for MongoDB:Teste de estresse do número máximo de conexões em uma instância de conjunto de réplicas

Última atualização: Aug 20, 2026

Este tópico descreve como executar um teste de estresse para verificar o número máximo de conexões em várias instâncias de conjunto de réplicas do ApsaraDB for MongoDB com diferentes especificações. O teste acessa as instâncias do ApsaraDB for MongoDB a partir de uma instância do Elastic Compute Service (ECS).

Ambiente de teste

Crie uma instância ECS e uma instância do ApsaraDB for MongoDB. Para mais informações, consulte Create a replica set instance e Create an ECS instance.

A tabela a seguir descreve as configurações da instância ECS e da instância do ApsaraDB for MongoDB usadas no teste.

Item de configuração

Instância ECS

Instância do ApsaraDB for MongoDB com discos em nuvem

Instância do ApsaraDB for MongoDB com discos locais

Região e zona

Beijing Zone H

Beijing Zone H

Beijing Zone H

Tipo de rede

Virtual Private Cloud (VPC)

VPC

VPC

Categoria da instância

c6e, família de instâncias otimizadas para computação com desempenho aprimorado

Uso geral e dedicada

Uso geral e dedicada

Tipo de instância

ecs.c6e.2xlarge

Três tipos de instância disponíveis. Para mais informações, consulte Resultados do teste.

Dois tipos de instância disponíveis. Para mais informações, consulte Resultados do teste.

Tipo de armazenamento

Discos Enterprise SSD (ESSD) AutoPL

ESSDs

SSDs locais

Versão da imagem ou do mecanismo

Alibaba Cloud Linux 3.2104 LTS 64 bits

4.19.91-26.al7.x86_64

3.10.0-327.ali2017.alios7.x86_64

Versão do kernel

N/A

  • Versão principal: MongoDB 4.4

  • Linha de base da versão secundária: 4.4.28

  • Versão principal: MongoDB 4.2

  • Linha de base da versão secundária: 4.2.23

  • A instância do ApsaraDB for MongoDB usada no teste adota a arquitetura de três nós, composta por um nó primário, um nó secundário e um nó oculto.

  • A instância ECS e a instância do ApsaraDB for MongoDB usadas no teste estão implantadas na mesma zona e região, com tempo médio de ida e volta (RTT) de 0,103 ms.

Ferramenta de teste

  • O teste utiliza a ferramenta de código aberto Yahoo Cloud Serving Benchmark (YCSB) 0.17.0.

    Nota

    O YCSB é uma ferramenta Java que avalia o desempenho de diversos tipos de bancos de dados. Para mais informações sobre como instalar e usar o YCSB, consulte YCSB.

  • Um programa personalizado de teste de estresse de conexões também é utilizado. Para mais informações, consulte Additional information about a stress test for 96.000 connections.

Método de teste

  1. Adicione o primary private IP address da instância ECS à lista de permissões da instância do ApsaraDB for MongoDB. Para mais informações, consulte Modify a whitelist.

    Nota

    Acesse o console do ECS e visualize o Primary Private IP Address da instância ECS na seção Configuration Information da página Instance Details.

  2. Conecte-se à instância ECS. Para mais informações, consulte Create and manage an ECS instance by using the ECS console (express version).

  3. Use a ferramenta YCSB para carregar os dados de teste.

    ./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

    Modifique as seguintes configurações:

    • recordcount=1000000: quantidade total de dados carregados na instância do ApsaraDB for MongoDB.

    • mongodb.url="mongodb://test:**@dds-bp13e84d11**.mongodb.rds.aliyuncs.com:3717/admin": string de conexão da instância do ApsaraDB for MongoDB. Neste teste, a conta do banco de dados é test e o banco de dados é admin.

      Nota

      Acesse o console do ApsaraDB for MongoDB. Na página Database Connection, visualize a string de conexão na seção Internal Connections - VPC.

    • threads 8: número de threads simultâneas no cliente usado no teste.

  4. Execute o comando a seguir para realizar o teste de estresse de desempenho:

    ./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

    Modifique as seguintes configurações:

    • recordcount=1000000: volume total de dados carregados na instância do ApsaraDB for MongoDB.

    • operationcount=5000000: quantidade total de operações de leitura e escrita.

    • insertproportion=0: proporção de operações de carga.

    • readproportion=50: proporção de operações de leitura.

    • updateproportion=50: proporção de operações de atualização.

    • mongodb.url="mongodb://test:**@dds-bp13e84d11**.mongodb.rds.aliyuncs.com:3717/admin": string de conexão da instância do ApsaraDB for MongoDB. Neste teste, a conta do banco de dados é test e o banco de dados é admin.

      Nota
      • Acesse o console do ApsaraDB for MongoDB. Na página Database Connection, verifique a string de conexão na seção Internal Connections - VPC.

      • Especifique o parâmetro maxPoolSize. Caso contrário, o valor padrão de 100 será aplicado, resultando no erro MongoWaitQueueFullException que impede o teste de atingir o limite alvo de conexões.

  5. Visualize as informações de monitoramento da instância do ApsaraDB for MongoDB usada no teste. Para mais detalhes, consulte Node monitoring (previously basic monitoring).

    Na aba node monitoring, selecione o intervalo de tempo do teste para visualizar as métricas de CPU Utilization, Memory Usage, QPS, Connections e Connection Usage da instância.

Informações adicionais sobre o teste de estresse para 96.000 conexões

O YCSB depende do ambiente Java, e a Java Virtual Machine (JVM) tem um limite máximo para o tamanho do heap. Ao executar um teste com alta concorrência (threads > 20.000), ocorre um erro de Cannot allocate memory conforme o exemplo abaixo, e o teste é interrompido.

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)

Mesmo após aumentar o valor do parâmetro JAVA_OPTS, o erro persiste. Para resolver esse problema, use um programa personalizado de teste de estresse de conexões. Esse programa gera ciclicamente várias threads, e cada thread cria um MongoClient. Após realizar uma consulta, o MongoClient mantém as conexões ativas por um período determinado sem liberá-las.

Uma única máquina que executa o cliente de teste de estresse tem um número limitado de portas. Portanto, ela não consegue atender aos requisitos de um teste de estresse de conexões (até 96.000 conexões) para uma especificação de 32 núcleos e 128 GB de memória. Nesse cenário, execute o mesmo programa de teste em múltiplas máquinas.

Execute o comando Bash a seguir para consultar o intervalo atual de portas de uma máquina:

sysctl net.ipv4.ip_local_port_range

Exemplo de resultado:

net.ipv4.ip_local_port_range = 40000    65535

Execute o comando abaixo para expandir o intervalo de portas da máquina e, em seguida, realize o teste de estresse de conexões:

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

Resultados do teste

Instância com ESSDs

Instância dedicada com 4 núcleos e 8 GB de memória

Número máximo de conexões: 8.000

QPS

Connections

Connection utilization

CPU utilization

Memory usage

image.png

image.png

image.png

image.png

image.png

Nota

Devido à granularidade de amostragem no nível de minuto da visualização de monitoramento do nó, o gráfico não exibe o pico de 8.000 conexões. Confirme esse pico usando um monitoramento mais granular ou verificando o subdocumento connections na saída do 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
}

Instância dedicada com 32 núcleos e 128 GB de memória

Número máximo de conexões: 96.000

QPS

Connections

Connection utilization

CPU utilization

Memory usage

image.png

image.png

image.png

image.png

image.png

Nota

A ferramenta usada no teste com 96.000 conexões difere daquela usada nos testes com 8.000 e 16.000 conexões. Por isso, há discrepâncias nas capturas de tela de monitoramento anteriores relacionadas a QPS, utilização de CPU e uso de memória.

Instância de uso geral com 8 núcleos e 32 GB de memória

Número máximo de conexões: 16.000

QPS

Connections

Connection utilization

CPU utilization

Memory usage

image.png

image.png

image.png

image.png

image.png

Instâncias com discos locais

Instância de uso geral com 16 núcleos e 64 GB de memória

Número máximo de conexões: 32.000

QPS

Connections

Connection utilization

CPU utilization

Memory usage

image.png

image.png

image.png

image.png

image.png

Nota

Se você definir uma granularidade de coleta no nível de minuto na aba Node Monitoring, o número de conexões em determinados momentos não será monitorado para uma instância de uso geral com 16 núcleos e 64 GB de memória. Isso ocorre devido a timeouts nos comandos de coleta causados pela utilização de 100% da CPU. Nessas situações, surgem vales nos gráficos de nível de minuto, mas o número real de conexões nesses momentos permanece em 32.000.

Instância dedicada com 2 núcleos e 16 GB de memória

Número máximo de conexões: 8.000

QPS

Connections

Connection utilization

CPU utilization

Memory usage

image.png

image.png

image.png

image.png

image.png

Resumo

  • As instâncias de conjunto de réplicas do ApsaraDB for MongoDB com diferentes especificações e tipos de armazenamento atingem o número máximo de conexões correspondente às suas respectivas especificações.

  • Ao atingir o limite máximo de conexões, o ApsaraDB for MongoDB rejeita novas tentativas de conexão. As requisições passam a apresentar alta latência ou ficam travadas na aplicação devido à falha no estabelecimento das conexões.

  • Um volume maior de conexões simultâneas consome mais recursos, como CPU e memória. Recomendamos ajustar a quantidade de conexões da sua instância de acordo com as necessidades do seu negócio.