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 |
|
|
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.
NotaO 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
-
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.
NotaAcesse 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.
Conecte-se à instância ECS. Para mais informações, consulte Create and manage an ECS instance by using the ECS console (express version).
-
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 8Modifique 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.
NotaAcesse 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.
-
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 8000Modifique 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.
NotaAcesse 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 erroMongoWaitQueueFullExceptionque impede o teste de atingir o limite alvo de conexões.
-
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 |
|
|
|
|
|
|
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 |
|
|
|
|
|
|
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 |
|
|
|
|
|
|
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 |
|
|
|
|
|
|
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 |
|
|
|
|
|
|
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.
























