Neste artigo vamos discutir o sysbench, o padrão real para benchmarking do MySQL. Vamos dar uma olhada no básico de uso do sysbench e como podemos usar o sysbench para aprender sobre o MySQL e o segundo é o aspecto mais importante para nós. Praticamente usaremos o sysbench como uma ferramenta para gerar tráfego sobre o qual sabemos muito, pois o sysbench armazenará algumas informações sobre o tráfego gerado a cada segundo.
Teste MySQL do SysBench
Sysbench é uma ferramenta de benchmark multi-thread baseada em luaJIT, é o padrão real para benchmarks do MySQL, ele precisa ser capaz de se conectar ao banco de dados.
Instalação do Sysbench
Primeiro, precisamos instalar o sysbench, estou instalando o sysbench em outro servidor para que possamos testar o real impacto da carga em nosso servidor MySQL.
curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bashyum -y install sysbench
Isso está definido, é muito fácil instalar o sysbench, é melhor permitir que o sysbench interaja com o MySQL Server no nível do firewall, como este é um ambiente de teste, desativei o firewall em ambos os hosts para evitar quaisquer dificuldades.
Ambiente pronto para SysBench:
Para este teste, estou criando o banco de dados sbtest e o usuário sbtest_user e concederei todos os PRIVILÉGIOS ao sbtest_user no banco de dados sbtest.
usando raiz;
mysql> cria banco de dados sbtestmysql> cria usuário sbtest_user identificado por 'password';mysql> concede todos em sbtest.* para `sbtest_user`@`%`;mysql> mostra concessões para sbtest_user;+------- -------------------------------------------------- +| Concessões para [email protected]% |+--------------------------------------------------- ------------------+| GRANT USAGE ON *.* TO `sbtest_user`@`%` || GRANT ALL PRIVILEGES ON `sbtest`.* TO `sbtest_user`@`%` |+------------------------------- ---------------+
Desempenho do MySQL usando SysBench
Configuração do comparativo de mercado:
A etapa de preparação do sysbench cria as tabelas com os dados que serão usados no benchmark. Neste exemplo estamos executando o comando prepare. Existem alguns parâmetros com o MySQL no início, esses serão os parâmetros de conexão. Os outros parâmetros são parâmetros do teste oltp_read_write.lua e estamos especificando o próprio teste que é oltp_read_write.lua e que estamos executando o comando prepare. A opção que começa com MySQL está especificando a conexão MySQL, o nome do host e a porta para se conectar, o nome de usuário e a senha para se conectar e o esquema padrão para a conexão. As tabelas e os parâmetros table_size são propriedades do teste oltp_read_write.lua.
Isso significa que a etapa de preparação criará 16 tabelas com 10.000 regras em cada uma delas. O próximo passo é executar o benchmark.
Para executar normalmente são passados todos os parâmetros que passarão para o preparado e alguns adicionais que revisamos agora, estes são específicos para a execução real do benchmark. A "HORA" O parâmetro especifica o limite de tempo para a execução do benchmark, zero significa tempo ilimitado, o benchmark será executado até pressionarmos control+c. É assim que usaremos o sysbench no laboratório e é assim que as pessoas normalmente o usam no aprendizado e não em uma configuração de benchmarking.
Queremos apenas liberar o tráfego em algo que examinaremos e podemos pará-lo com control+c assim que terminarmos o exame.
O "intervalo-relatório" os parâmetros especificam com que frequência o sysbench imprimiu as estatísticas. Normalmente, isso é definido como 1, como em nosso exemplo, que faz o sysbench imprimir a linha a cada segundo. Mesmo em configurações de benchmarking este parâmetro é amplamente usado porque imagine se tivermos um benchmark de uma hora e só tivermos estatísticas agregadas no final, isso não diz nada sobre a distribuição dos dados como o desempenho do servidor ao longo do tempo . O "tópico" A opção especifica o número de threads de cliente ou conexões MySQL a serem usadas no sysbench. O número de threads do cliente também afetará o número de threads do servidor que podem ser usados. A "taxa" O parâmetro especifica a taxa de chegada das transações do sysbench como uma forma de realmente atender à carga causada pelo benchmark. Se as transações podem prosseguir, elas são enfileiradas, novamente, isso é algo que normalmente é usado nesse tipo de configuração, o que vamos usar agora em um tipo de configuração de aprendizado.
Do host do sysbench:
Prepare um conjunto de dados:
Na máquina virtual de benchmarking, vamos executar o comando sysbench prepare para criar um banco de dados para nossos benchmarks.
Aqui podemos ver que estamos usando o sbtest_user como nome de usuário, a senha é password e estamos nos conectando ao DB 192.168.66.5 como servidor de banco de dados.
sysbench \--db-driver=mysql \--mysql-user=sbtest_user \--mysql_password=senha \--mysql-db=sbtest \--mysql-host=192.168.66.5 \--mysql-port =3306 \--tables=16 \--table-size=10000 \/usr/share/sysbench/oltp_read_write.lua preparesysbench 1.0.20 (usando o pacote LuaJIT 2.1.0-beta2)Criando a tabela 'sbtest1'...Inserindo 10.000 registros em 'sbtest1'Criando um índice secundário em 'sbtest1'......Criando tabela 'sbtest16'...Inserindo 10.000 registros em 'sbtest16'Criando um índice secundário em 'sbtest16'..
Você tem o banco de dados sbtest aqui, vamos alterar o esquema padrão para o banco de dados sbtest, verifique quais tabelas temos.
Especificamos que o benchmark deve criar dezesseis tabelas e criou 16 tabelas, podemos ver aqui
mysql> mostra tabelas;+------------------+| Tables_in_sbtest +------------------+| sbtest1 || sbtest2 |...| sbtest16 |+------------------+16 linhas no conjunto (0,01 seg)
Vamos verificar alguns registros de uma tabela.
mysql> selecione * de sbtest1 limite 6;
vamos fazer um benchmark. Este benchmark terá uma linha de saída para cada segundo porque definimos rapport o intervalo é igual a um e tem quatro threads de cliente porque definimos threads iguais a quatro.
--events=N limite para o número total de eventos [0]--time=N limite para o tempo total de execução em segundos [10]
As duas configurações acima (eventos e tempo) controlam por quanto tempo o SysBench deve continuar em execução. Ele pode executar um certo número de consultas ou pode continuar em execução por um tempo predefinido.
No host do sysbench:
sysbench \--db-driver=mysql \--mysql-user=sbtest_user \--mysql_password=senha \--mysql-db=sbtest \--mysql-host=192.168.66.5 \--mysql-port =3306 \--tables=16 \--table-size=10000 \--threads=4 \--time=0 \--events=0 \--report-interval=1 \ /usr/share/sysbench/ oltp_read_write.lua runWARNING:Ambos os limites de evento e tempo estão desabilitados, executando um testsysbench 1.0.20 sem fim (usando o pacote LuaJIT 2.1.0-beta2)Executando o teste com as seguintes opções:Número de threads:4Reporta resultados intermediários a cada 1 segundo(s) ) Inicializando o gerador de números aleatórios do tempo atualIniciando threads de trabalho...Threads iniciados![ 1s ] thds:4 tps:62,79 qps:1320,63 (r/w/o:933,91/257,15/129,57) lat (ms,95%):80,03 err/s:0,00 reconn/s:0,00[ 2s ] thds:4 tps:77,01 qps:1530,26 (r/w/o:1065,18/312,05/153,03) lat (ms,95%):61,08 err/s:0,00 reconn /s:0,00[ 3s ] thds:4 tps:74,03 qps:1463,67 (r/w/o:1025,47/289,13/149,07) lat (ms,95%):70,55 err/s:0,00 reconn/s:0,00[ 4s ] thds:4 tps:69,99 qps:1414. 84 (r/w/o:991,89/282,97/139,98) lat (ms,95%):65,65 err/s:0,00 reconn/s:0,00[ 5s ] thds:4 tps:74,02 qps:1488,34 (r/w/ o:1048,24/292,07/148,03) lat (ms,95%):74,46 err/s:0,00 reconn/s:0,00[ 6s ] thds:4 tps:72,99 qps:1444,89 (r/w/o:1003,92/294,98/ 145,99) lat (ms,95%):70,55 err/s:0,00 reconn/s:0,00[7s] thds:4 tps:63,00 qps:1271,04 (r/w/o:890,03/255,01/126,00) lat (ms, 95%):87,56 err/s:0,00 reconn/s:0,00[ 8s ] thds:4 tps:72,99 qps:1439,82 (r/w/o:1008,87/284,96/145,98) lat (ms,95%):73,13 err /s:0,00 reconn/s:0,00[ 9s ] thds:4 tps:74,00 qps:1488,01 (r/w/o:1038,01/302,00/148,00) lat (ms,95%):73,13 err/s:0,00 reconn/ s:0,00
para que possamos ver que está fazendo cerca de 70 80 transações por segundo na minha máquina, o que se traduz em aproximadamente mais de mil consultas por segundo. Isso está sendo executado no VirtualBox em um laptop.
A partir dessas consultas, podemos ver quantas delas são leituras, quantas delas são escritas, quantas delas são outras qual é a latência do percentil 95 para a transação (r/w/o:1038.01/302.00/148.00), quanto quantos erros por segundo (err/s:0.00) temos e quantas conexões por segundo (reconn/s:0.00) temos. Como especificamos o tempo igual a zero, isso será executado até pressionarmos ctrl+c.
Vamos verificar a lista de processos de exibição no host do banco de dados.
mysql> mostra lista de processos;+----+-----------------+------------------ --+--------+---------+-------+-------------------- --------+--------------------------------------+| ID | Usuário | Anfitrião | banco de dados | Comando | Hora | Estado | Informações |+----+-----------------+--------------------+--- -----+---------+-------+-------------------------- --+--------------------------------------+| 5 | event_scheduler | localhost | NULO | Daemon | 23200 | Esperando na fila vazia | NULL || 11 | raiz | localhost | NULO | Dormir | 18438 | | NULL || 19 | raiz | localhost | sbtest | Consulta | 0 | começando | show processlist || 23 | raiz | localhost | NULO | Dormir | 4098 | | NULL || 30 | sbtest_user | 192.168.66.6:37298 | sbtest | Dormir | 0 | | NULL || 31 | sbtest_user | 192.168.66.6:37300 | sbtest | Executar | 0 | aguardando confirmação do manipulador | COMMIT || 32 | sbtest_user | 192.168.66.6:37302 | sbtest | Dormir | 0 | | NULL || 33 | sbtest_user | 192.168.66.6:37304 | sbtest | Executar | 0 | Abrindo mesas | SELECT c FROM sbtest13 WHERE id=4978 |+----+-----------------+----------------- ---+--------+---------+------+--------- ---------+--------------------------------------+
8 linhas em conjunto (0,00 seg)
O servidor de banco de dados estava praticamente sempre ocupado. Vi que o tempo de execução nunca muda de zero praticamente, e foi muito fácil pegar o servidor de banco de dados em ação como quando está rodando “SELECT c FROM sbtest13 WHERE id=4978”. E definitivamente, temos quatro conexões da máquina de benchmarking
Por padrão, o SysBench tentará executar consultas o mais rápido possível. Para simular um tráfego mais lento, esta opção pode ser usada. Você pode definir aqui quantas transações devem ser executadas por segundo.
--rate=N taxa média de transações. 0 para taxa ilimitada [0]No host do sysbench
[[email protected] ~]# sysbench \--db-driver=mysql \--mysql-user=sbtest_user \--mysql_password=senha \--mysql-db=sbtest \--mysql-host=192.168.66.5 \--mysql-port=3306 \--tables=16 \--table-size=10000 \--threads=4 \--time=0 \--events=0 \--report-interval=1 \--rate=40 \/usr/share/sysbench/oltp_read_write.lua runWARNING:Ambos os limites de evento e tempo estão desabilitados, executando um testsysbench 1.0.20 infinito (usando o pacote LuaJIT 2.1.0-beta2)Executando o teste com o seguinte opções:Número de encadeamentos:4Taxa de transação de destino:40/sRelatar resultados intermediários a cada 1 segundo(s) Inicializando o gerador de números aleatórios da hora atualInicializando encadeamentos de trabalho...Encadeamentos iniciados![ 1s ] thds:4 tps:42,87 qps:858,43 (r /s/s:600,20/171,49/86,74) lat (ms,95%):73,13 err/s:0,00 reconn/s:0,00[ 1s ] comprimento da fila:0, simultaneidade:1[ 2s ] thds:4 tps:41,01 qps:857,25 (r/w/o:609,17/164,05/84,02) lat (ms,95%):101,13 err/s:0,00 reconn/s:0,00[ 2s ] comprimento da fila:0, simultaneidade:3[ 3s ] thds :4 tps:57,01 qps:1119,29 (r/s/o:778,20/228,06/113,03) lat (ms,95%):73,13 err/s:0,00 reconn/s:0,00[ 3s ] comprimento da fila:0, simultaneidade:2... [ 15s ] thds:4 tps:0,00 qps:0,00 (r/w/o:0,00/0,00/0,00) lat (ms,95%):0,00 err/s:0,00 reconn/s:0,00[ 15s ] comprimento da fila:145, simultaneidade:4[ 16s ] thds:4 tps:0,00 qps:0,00 (r/w/o:0,00/0,00/0,00) lat (ms,95%):0,00 err/s:0,00 reconn/s:0,00[ 16s ] comprimento da fila:179, simultaneidade:4
Portanto, o novo parâmetro aqui é –rate é igual a 40 o que significa que teremos duas linhas por segundo duas linhas de saída e não uma. Como definimos a taxa de chegada dos eventos de benchmarking para 40 por segundo, veremos o TPS atual.
Não é garantido que seja 40/segundo, mas a chegada garante que, em média, fazemos cerca de 40 transações por segundo e podemos monitorar o comprimento da fila e a simultaneidade na segunda linha. Se fizermos uma pequena lista de processos, é muito mais fácil pegar o banco de dados em um estado em que algumas conexões estão apenas esperando aqui.
Enquanto uma sessão está ocupada, você pode ver que a transação por segundo é zero (tps:0.00 ).
mysql> mostra lista de processos;+----+-----------------+------------------ --+--------+---------+-------+-------------------- ----+--------------------------------------------- -------------------------------------------------- -------+| ID | Usuário | Anfitrião | banco de dados | Comando | Hora | Estado | Informações |+----+---+-----+--- -----+---------+-------+------------------------+- -------------------------------------------------- -------------------------------------------------- -+| 5 | event_scheduler | localhost | NULO | Daemon | 19162 | Esperando na fila vazia | NULL || 8 | raiz | localhost | NULO | Consulta | 0 | começando | mostrar lista de processos | || 21 | sbtest_user | 192.168.66.6:49060 | sbtest | Executar | 33 | atualização | UPDATE sbtest8 SET k=k+1 WHERE id=5005 || 22 | sbtest_user | 192.168.66.6:49062 | sbtest | Executar | 22 | atualização | UPDATE sbtest14 SET c='54592761471-89397085016-24424731626-29460127219-18466786462-73074657089-48925 | 23 | sbtest_user | 192.168.66.6:49064 | sbtest | Executar | 21 | atualização | UPDATE sbtest10 SET c='68520795048-46094139936-88850487689-12482054639-29231339380-71050139550-93403 || 24 | sbtest_user | 192.168.66.6:49066 | sbtest | Executar | 31 | atualização | DELETE FROM sbtest14 WHERE id=4994 |+----+-----------------+------------------ --+--------+---------+-------+-------------------- ----+--------------------------------------------- -------------------------------------------------- -------+10 linhas no conjunto (0,00 seg)
Podemos ver que isso está dormindo por alguns segundos, isso era praticamente impossível no cenário anterior obter algo assim.
Tráfego intenso de gravação com relatório final:
Vamos executar uma carga de trabalho pesada de gravação (mas não somente gravação) e, por exemplo, o desempenho do subsistema de E/S de teste, como mencionei time=300 então o benchmark será executado por 300 segundos e nos dará um relatório final para analisá-lo.
[[email protected] ~]# sysbench \--db-driver=mysql \--mysql-user=sbtest_user \--mysql_password=senha \--mysql-db=sbtest \--mysql-host=192.168.66.5 \--mysql-port=3306 \--tables=16 \--table-size=10000 \--threads=8 \--time=300 \--events=0 \--report-interval=1 \--rate=40 \/usr/share/sysbench/oltp_read_write.lua runsysbench 1.0.20 (usando o pacote LuaJIT 2.1.0-beta2)Executando o teste com as seguintes opções:Number of threads:8Target transaction rate:40/secReport resultados intermediários a cada 1 segundo(s) Inicializando o gerador de números aleatórios do tempo atualIniciando threads de trabalho...Threads iniciados![ 1s ] thds:8 tps:39.87 qps:810.27 (r/w/o:570.08/159.46/80.73) lat ( ms,95%):82,96 err/s:0,00 reconn/s:0,00[ 1s ] comprimento da fila:0, simultaneidade:1[ 2s ] thds:8 tps:43,02 qps:847,39 (r/w/o:590,27/172,08 /85,04) lat (ms,95%):125,52 err/s:0,00 reconn/s:0,00[ 2s ] comprimento da fila:0, simultaneidade:0...[ 350s ] thds:8 tps:0,00 qps:0,00 (r /w/o:0,00/0,00/0,00) lat (ms,95%):0,00 err/s :0,00 Reconn/s:0.00 [350S] Comprimento da fila:6545, Concorrência:1SQL Estatísticas:Consultas realizadas:Leia:78624 Escreva:22385 Outros:11205 Total:112214 Transações:5589 (15.94 por segundos). Sec.) Erros ignorados:27 (0,08 por seg.) Reconecta -se:0 (0,00 por segundos) Estatísticas gerais:Tempo total:350.6412s Número total de eventos:5589Latência (MS):Min:12.45 AVG:74639.59 Max:213244.02 95th percentil: 100.000,00 soma: 417160677.24Justiça dos segmentos: eventos (méd./stddev): 698,6250/196,36 tempo de execução (média/stddev): 52145.0847/15557.93
ANÁLISE DO RELATÓRIO:
Isso é bastante útil para verificar se o relatório final fornecerá apenas médias. Os resultados intermediários permitirão acompanhar o desempenho segundo a segundo. O relatório final pode ser parecido com o acima, você encontrará aqui informações sobre consultas executadas, transações executadas, quantos erros aconteceram, alguma perda de conexão aconteceu, qual foi a taxa de transferência e o tempo total decorrido. Você também pode verificar as métricas de latência e a distribuição de consultas entre os encadeamentos.
