Modelo de TCC para o Curso de Ciência da Computação da UNIVALI

UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SIMULADOR DE ANÁLISE DE DESEMPENHO PARA BANCO DE DADOS
MYSQL
Área de Banco de Dados
por
Gustavo Ferreira de Araujo Silva
Adriana Gomes Alves, M. Eng.
Orientadora
Itajaí (SC), Julho de 2012
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SIMULADOR DE ANÁLISE DE DESEMPENHO PARA BANCO DE DADOS
MYSQL
Área de Banco de Dados
por
Gustavo Ferreira de Araujo Silva
Relatório apresentado à Banca Examinadora do
Trabalho de Conclusão do Curso de Ciência da
Computação para análise e aprovação.
Orientadora: Adriana Gomes Alves, M. Eng.
2
Itajaí (SC), Julho de 2012
3
SUMÁRIO
LISTA DE ABREVIATURAS............................................................... vi
LISTA DE FIGURAS............................................................................ vii
LISTA DE TABELAS............................................................................ ix
RESUMO.................................................................................................. x
ABSTRACT.............................................................................................xi
1 INTRODUÇÃO...................................................................................12
1.1 PROBLEMATIZAÇÃO.................................................................................... 15
1.1.1 Formulação do Problema...............................................................................15
1.1.2 Solução Proposta............................................................................................ 16
1.2 OBJETIVOS.......................................................................................................17
1.2.1 Objetivo Geral................................................................................................ 17
1.2.2 Objetivos Específicos......................................................................................17
1.3 METODOLOGIA............................................................................................. 18
1.4 ESTRUTURA DO TRABALHO...................................................................... 18
2 FUNDAMENTAÇÃO TEÓRICA..................................................... 20
2.1 AVALIAÇÃO E ANÁLISE DE DESEMPENHO...........................................20
2.2 BANCO DE DADOS MYSQL.......................................................................... 22
2.2.1 Arquitetura do MySQL................................................................................. 24
2.2.2 Tipo de Tabelas ou Ferramentas de Armazenagem....................................26
2.3 ANÁLISE E AJUSTE DE DESEMPENHO DO MYSQL..............................31
2.3.1 Configuração de Parâmetros.........................................................................31
2.3.2 Instruções SQL............................................................................................... 32
2.4 FERRAMENTAS PARA ANÁLISE DE DESEMPENHO............................ 34
2.4.1 Mysqlslap – Cliente de Emulação de Carga................................................ 35
2.4.2 Mysqladmin.................................................................................................... 37
2.4.3 phpMyAdmin..................................................................................................38
2.4.4 Innotop – Monitor em tempo real das conexões..........................................40
2.4.5 Tuning Primer................................................................................................ 41
2.4.6 Resultado das Ferramentas Avaliadas......................................................... 43
3 DESENVOLVIMENTO..................................................................... 44
3.1 IMPLEMENTAÇÃO.........................................................................................44
3.2 APRESENTAÇÃO DA FERRAMENTA........................................................ 47
3.3 VALIDAÇÕES DA FERRAMENTA...............................................................58
CONCLUSÃO........................................................................................ 62
REFERÊNCIAS BIBLIOGRÁFICAS................................................. 63
A PROJETO...........................................................................................66
iv
A.1 REQUISITOS.................................................................................................... 66
A.1.1 Requisitos Funcionais.....................................................................................66
A.1.2 Requisitos Não Funcionais.............................................................................67
A.2 DIAGRAMA DE CASOS DE USO..................................................................68
A.2.1 Análise e Ajuste de Desempenho...................................................................68
A.2.2 DIAGRAMA DE COMPONENTES............................................................ 78
A.2.3 DIAGRAMA DE IMPLANTAÇÃO.............................................................79
v
LISTA DE ABREVIATURAS
AJAX
ANSI
BD
DBA
ISO
PHP
PHP
SGBD
SQL
TNST
TST
TTC
UML
UNIVALI
Asynchronous Javascript and XML
American National Standards Institute
Banco de Dados
Data Base Administrator
International Organization for Standardization
PHP: Hypertext Preprocessor
PHP: Hypertext Preprocessor
Sistema Gerenciador de Banco de Dados
Structured Query Language
Tabelas Não Seguras com Transação
Tabelas Seguras com Transação
Trabalho de Técnico-Científico
Unified Modeling Language
Universidade do Vale do Itajaí
vi
LISTA DE FIGURAS
Figura 1. Arquitetura conceitual do MySQL: Camadas Básicas.......................................................22
Figura 1. Arquitetura conceitual do MySQL: Camadas Básicas........25
Figura 2. my.cnf: arquivo de configuração do MySQL........................32
Figura 3. mysqlslap: terminal com o comando de execução da
ferramenta.................................................................................................36
Figura 4. mysqlslap: resultado obtido do comando referente à Figura
3 36
Figura 5. mysqladmin: ferramenta de administração do MySQL......37
Figura 6. phpMyAdmin: tela com as Variáveis de Runtime do
MySQL.39
Figura 7. phpMyAdmin: tela com as Variáveis de Configuração do
MySQL.40
Figura 8. Innotop: monitor de transações e status do servidor MySQL
41
Figura 9. Tuning Primer: script para monitoração das variéveis de
execução do servidor MySQL.................................................................41
Figura 10. Tuning Primer: resultado do módulo
MAX_CONNECTIONS...........................................................................42
Figura 11. Tela de login do simulador....................................................48
Figura 12. Tela inicial..............................................................................49
Figura 13. Seleção para o tipo de simulação..........................................50
Figura 14. Seleção dos parâmetros para execução do simulador........50
Figura 15. Confirmação para início da simulação................................51
Figura 16. Tela com etapas do processo de criação do ambiente........52
Figura 17. Tela de simulação...................................................................53
Figura 18. Seleção para os resultados da simulação.............................54
Figura 19. Relatório com as simulações da base de dados selecionada.
54
Figura 20. Visualização e Alteração das variáveis de configuração....55
Figura 21. Tela para alteração da variável de configuração do
MySQL.56
vii
Figura 22. Tela para visualização das variáveis de execução/status....57
Figura 23. Tela para visualização dos processos, com opção de matar
processo.....................................................................................................57
Figura 24. Validação do ambiente..........................................................58
Figura 25. Lista de processos gerados aleatoriamente..........................59
Figura 26. Alteração da variável Read_Buffer_Size.............................60
Figura 27. Resultado simulação..............................................................60
Figura 28. Diagrama de Casos de Uso: Análise e Ajuste de
Desempenho..............................................................................................68
Figura 29. Efetua autenticação no MySQL Server...............................70
Figura 30. Tela inicial com informações do servidor............................70
Figura 31. Visualiza Variáveis de Configuração do Sistema............71
Figura 32. Altera Variáveis do MySQL.................................................73
Figura 33. Visualiza Variáveis de Runtime...........................................74
Figura 34. Analisa Processos em Execução............................................75
Figura 35. Inicia a Simulação..................................................................77
Figura 36. Telas para opções do início da Simulação...........................77
Figura 37. Resultados Obtidos na simulação.........................................78
Figura 38. Diagrama de Componentes...................................................79
Figura 39. Diagrama de Implantação: Configuração Física................80
viii
LISTA DE TABELAS
Tabela 1. Variáveis de Ambiente Tabela MyISAM..............................27
Tabela 2. Variáveis de Ambiente Tabela InnoDB.................................30
Tabela 3. Comparativo das ferramentas para análise de desempenho
do MySQL.................................................................................................43
Tabela 4. Matriz Requisito Funcional e Diagrama de Casos de Uso...69
Tabela 5. Variáveis de Status do servidor MySQL...............................82
ix
RESUMO
ARAUJO SILVA, Gustavo Ferreira de. Simulador de Análise de Desempenho para Banco de
Dados MySQL. Itajaí, 2011. 82 f. Trabalho de Conclusão de Curso (Graduação em Ciência da
Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí,
Itajaí, 2011.
O MySQL é um Sistema Gerenciador de Banco de Dados (SGBD) relacional de código aberto
(Open Source) e licença livre para uso da comunidade. Sua linguagem de banco de dados é a SQL
(Structured Query Language) a qual segue os padrões e normas técnicas estabelecidas e controladas
pela ANSI (American National Standards Institute) em sociedade com a ISO (Internacional
Organization for Standardization) e a IEC (International Electrotechnical Commission). Um SGBD
fornece ao DBA (Data Base Administrator) o total controle dos dados e estrutura de uma base de
dados. Para o DBA, além da manipulação e controle destes dados e definição da estrutura do
SGBD, outra função importante é o ajuste de desempenho onde muitas vezes é executado de forma
manual. A análise de desempenho é focada em 05 (cinco) níveis de ajuste para melhora no
desempenho: i) otimização do esquema de banco de dados, ii) ajuste das opções do servidor, iii)
ajuste nas configurações do banco de dados, iv) seleção e ajuste de hardware e v) ajuste na forma de
armazenamento dos dados. Existem diversas ferramentas livre e de código aberto para
administração do MySQL, mas nenhuma executa de forma automatizada a análise e ajuste de
parâmetros para melhora no seu desempenho. Este Trabalho Técnico-Científico de Conclusão de
Curso (TTC) visou desenvolver funcionalidades para análise e ajuste nos parâmetros de
configuração do MySQL e implementou um simulador para análise e ajuste de parâmetros visando
melhoria de desempenho do SGBD MySQL. O resultado obtido com esta ferramenta é contribuir
com a comunidade que utiliza o MySQL como SGBD e permitir que novas funcionalidades sejam
implementadas em trabalhos futuros.
Palavras-chave: Banco de Dados. Desempenho. MySQL.
x
ABSTRACT
MySQL is a DBMS (Data Base Manager System) relational open source and free licensed to use it
of community. It's databases language is the SQL (Structured Query Language) which one follows
the standard and technical rules established and controlled by ANSI (American National Standards
Institute) jointed with the ISO (Internacional Organization for Standardization) and the IEC
(International Electrotechnical Commission). A DBMS gives to the DBA (Data Base Administrator)
the total control of the data and structure of a database. To the DBA, beyond manipulation and
control of those datas and structures definitions of DBMS another important function is the control
performance where many times is made of by hand. The performance analysis is focused on 05
(five) tuning levels to get the better performance. i) optimization of the databases schema, ii) tuning
server options, iii) tuning databases configurations, iv) hardware selection and tuning and v)
adjustment of the data storage. There are many tools and open source to MySQL administration but
no one can be executed by the automatized way analysis and tuning parameter to get a better
performance. TCC aims to develop functionalities to analysis and possible tunings on MySQL
configuration parameters and will be implemented in the form of a simulator. The wish result for
this tool is to contribute for the community who uses the MySQL as DBMS and permit for
improvements and new functionalities are implemented for the future works.
Keywords: Database. Performance. MySQL.
xi
1 INTRODUÇÃO
A Análise e Ajuste de Desempenho dos SGBD (Sistemas Gerenciadores de Banco de
Dados) visa melhorar seu funcionamento, sendo o tempo a principal métrica, reduzindo custos. Ela
também ajuda a antecipar, prever e eliminar problemas de paradas no seu funcionamento decorrente
de erros em suas variáveis de configuração e de execução, além de outros pontos de análise e
avaliação de ajuste.
Segundo Schwartz et al (2009), avaliação e análise de desempenho são duas práticas
essenciais para encontrar gargalos. Elas são relacionadas, mas não são as mesmas. A avaliação de
desempenho mede o desempenho do sistema, permitindo determinar sua capacidade. Também
mostra quais mudanças são importantes para o bom funcionamento de um SGBD e quais não são,
ou mostra como a aplicação executa com dados diferentes de configuração.
Schwartz et al (2009) comenta também que, a análise de desempenho ajuda a encontrar onde
a aplicação gasta mais tempo de processamento ou consome mais recursos como, por exemplo, a
utilização da rede. Em outras palavras, a avaliação de desempenho responde à pergunta “Quão bem
isso executa?” e análise de desempenho responde à pergunta “Por que isso executa dessa maneira?”.
Lima (2003) explica que, antes de tudo, é importante ressaltar que não há muito que
melhorar em um servidor se o projeto do banco ou sistema não for bem feito, como, por exemplo,
tabelas que não observam as formas normais de funcionamento, falta de índices para colunas
importantes, consultas mal-elaboradas, dimensionamento incorreto de local e espaço para os dados,
entre outros. Mesmo que isso não aconteça, a otimização será difícil se os recursos de equipamento
forem limitados. O mesmo autor conclui que, uma boa análise e um bom projeto de dados,
conseqüência de um levantamento realista, são elementos básicos para a plena atividade de um
SGBD. Providências como a especificação acertada de tabelas, tipos de dados bem-dimensionados,
criação de índices a partir de um apanhado geral das colunas que participam de junções, consultas
usadas com mais freqüência – tudo isso facilita os ajustes que normalmente devem ser feitos ao
longo do tempo em virtude do uso e dos processos diários. Cabe ao Administrador de Banco de
Dados (DBA, Data Base Administrator), identificar os pontos vulneráveis e causadores de gargalos
em sua base.
Schwartz et al (2009) comenta que com o aumento da utilização de bancos de dados de
código aberto, nas mais diversas áreas e níveis, surge cada vez mais a necessidade do controle e
ajuste de desempenho e a otimização destes bancos de dados. Esta necessidade existe porque as
bases de dados com Sistema Gerenciador de Banco de Dados (SGBD) estão atingindo enormes
quantidades de registros e acessos simultâneos, gerando gargalos provenientes das configurações
nativas do SGBD que ainda não foram refinadas para tal situação. Schwartz et al (2009) completa
que estas configurações são padrões de instalação e, portanto não estão adequadas às necessidades
específicas de cada base de dados. Outra premissa a ser avaliada é a dúvida inerente à enorme
disponibilidade de versões lançadas em períodos cada vez menores, característica forte em SGBD.
Proni (2010) afirma que as empresas aguardam por versões mais estáveis para iniciarem o processo
de atualização de suas bases e do próprio SGBD, e esta expectativa da compatibilidade de versões é
considerada por muitos como um problema não menos importante.
Dentre os SGBDs encontra-se o MySQL. Sua versatilidade e facilidade de uso o tornaram
um dos bancos de dados mais usados com cerca de dez milhões de instalações ao redor do planeta.
Usam o MySQL a NASA; a Friendster; o Bradesco; a Nokia; a HP; a Sony; a Lufthansa e inúmeras
outras entidades das mais diversas origens e pessoas físicas de várias nacionalidades (MYSQL,
2011).
Proni (2010) afirma que, mesmo com as melhorias de escalabilidade apresentadas nos
Benchmarks 1, o MySQL não tem um bom desempenho com a configuração padrão. Além disso, é
um dos Bancos de Dados mais sensíveis a parâmetros do mercado, fazendo com que uma pequena
alteração no arquivo de inicialização traga benefício ou cause desastre na aplicação.
O MySQL, tem como as principais e mais conhecidas ferramentas para administração de
banco de dados, o MySQL Administrator, o qual faz parte do pacote MySQL GUI Tools,
distribuído gratuitamente pala própria MySQL e o PhpMyAdmin. O MySQL Administrator permite
a visualização e alteração das variáveis de configuração do banco de dados entre outras consultas,
como visualização de logs, estatísticas de acesso e uso de memória, variáveis de runtime, entre
outras. Ele é distribuído junto com o MySQL pela Oracle, a qual adquiriu a Sun, que por sua vez,
havia comprado a MySQL AB.
1
benchmark é o ato de executar um programa de computador, um conjunto de programas ou outras operações, a fim de
avaliar o desempenho relativo de um objeto, normalmente executando uma série de testes padrões e ensaios nele.
13
A outra ferramenta, PhpMyAdmin, entra como principal nesta lista, pois sua utilização se
propagou pelos sites de hospedagem onde roda pela web e também permite a visualização das
variáveis de configuração e de runtime, sendo que não há possibilidade de alterá-las de forma
intuitiva. Ambas ferramentas não realizam análise e ajuste de desempenho do banco de forma
automatizada, tendo o administrador que avaliar a atual situação e determinar quais ajustes deverão
ser efetuados para a melhora do desempenho.
Outras ferramentas encontradas no mercado, segundo Proni (2010), também merecem
atenção no quesito avaliação e análise de desempenho do MySQL. Uma delas é a nTop, no qual seu
único foco é o monitoramento do tráfego da rede, sendo um importante ponto de avaliação e não
deve ser negligenciado pelos administradores. E por último, a ferramenta mysqlreport, que
transforma os valores retornados pelo comando SHOW STATUS do MySQL em um relatório,
contendo, por exemplo, a quantidade de queries separadas por tipo (SELECT, INSERT, UPDATE),
uso de cache para as consultas, número de conexões ao servidor, etc.
Dentro deste contexto, este trabalho de conclusão de Curso de Ciência da Computação
propõe uma ferramenta para simular a análise em um banco de dados e obter resultados sobre seu
desempenho com as principais métricas da ferramenta de armazenagem InnoDB e propor e efetuar
ajustes na configuração do MySQL.
O foco da simulação da análise é a monitoração e a configuração do engine InnoDB, pois
mesmo não sendo padrão no MySQL, é o mais utilizado no mercado. Isto porque o engine InnoDB
funciona mais rápido que o MyISAM quando há modificações constantes nos dados, uma vez que
este tipo de armazenagem usa a proteção por registros (row locking) e não a proteção por tabelas
(table locking) como o faz o MyISAM. Contudo, em várias situações InnoDB é mais lento que
MyISAM, devido ao fato, por exemplo, que InnoDB funciona com transações. A armazenagem
padrão do MySQL é o MyISAM. Outro ponto é a restrição de chaves estrangeiras (foreign key
constraints) e as transações. Estes recursos estão disponíveis apenas no InnoDB.
A ferramenta permitirá ao administrador do banco de dados, efetuar simulações em uma
base de dados paralela, a qual será definida de acordo com suas necessidades e com os resultados
obtidos, possa detectar problemas na má configuração das variáveis em sua base real.
14
Com o simulador, o administrador poderá paralelamente analisar sua base de dados criando
outra base com a mesma estrutura, podendo sobrecarregar o funcionamento para ajustes das novas
necessidades, sem correr o risco com a base de produção.
Algumas funções desenvolvidas no projeto. São elas: (i) criar um ambiente para utilização
do simulador, com base de dados, contendo tabelas e registros, executando funções no qual
sobrecarregue o funcionamento do sistema, de acordo com a necessidade e definições do
administrador, (ii) monitorar as variáveis de runtime do engine do InnoDB, realizando análise de
seu funcionamento, sugerindo a nova configuração, contando também com a ajuda de estatísticas
geradas como seu funcionamento e (iii) monitorar processos em execução, no qual se detecta muitas
vezes pontos importantes de gargalos, por exemplo, consultas que levam mais tempo para serem
concluídas.
Este trabalho de TTC tem como foco o emprego de técnicas avançadas em Banco de Dados
no que diz respeito à Análise e Ajuste de Desempenho do MySQL e sua utilização visa prover uma
ferramenta que contemple principalmente a configuração do engine ou storage engine InnoDB, de
acordo com os resultados obtidos na análise.
1.1 PROBLEMATIZAÇÃO
1.1.1
Formulação do Problema
Muitas vezes os DBAs são surpreendidos com uma queda no desempenho em determinada
base de dados. Há diversos níveis a serem avaliados e com isso muito tempo é despendido para tal
função e quase sempre uma equipe é destinada para vasculhar e identificar os gargalos que afetam o
desempenho da base de dados, deixando-a instável e lenta.
Esta prática de identificar os gargalos eleva os custos da administração do banco, pois outras
funções poderiam estar sendo desenvolvidas com a finalidade de melhorar ou ampliar as reais
funcionalidades do banco de dados. A ocorrência do mau funcionamento de um banco de dados
também cria o descontentamento dos usuários finais que utilizam a base para desempenhar seus
trabalhos, podendo tornar negativo os negócios da empresa.
Quando se trata de bancos comerciais, vários aplicativos embutidos no próprio SGBD
(Sistema Gerenciador de Banco de Dados) ou mesmo aqueles desenvolvidos por outras empresas de
cunho comercial, fazem com que todo o ciclo de gerenciamento de um SGBD, incluindo avaliação,
15
análise e o ajuste de desempenho, seja concluído naturalmente e muitas vezes sem a intervenção do
administrador.
Quando se deseja efetuar a análise de um ambiente em funcionamento, os administradores
geralmente executam ferramentas paralelas para a monitoração das principais métricas de detecção
de desempenho. Podemos citar algumas: problemas com a rede, erro na configuração das variáveis
do servidor MySQL, problemas com configuração dos equipamentos, ou seja, na parte física da
estrutura, ou como também com atualizações de versão, entre outras.
Em uma base em produção, quando há necessidade de se efetuar algum ajuste do ambiente
do banco de dados, os DBAs encontram grandes dificuldades de realizar as devidas correções nos
pontos de ajustes detectados. Uma parada em todo o sistema para uma manutenção de ajuste pode
acarretar em perda de dados, tempo e causar grandes transtornos para a empresa. Com a ferramenta
de simulação, o administrador poderá simular antes de iniciar um projeto de banco de dados ou até
mesmo com a base já em produção, porém com tempo programado para paradas e analisar qual a
verdadeira necessidade que seu ambiente terá. Poderá simular, dentro de uma estimativa de usuários
e queries, por exemplo, e configurar o banco de acordo com o resultado obtido.
1.1.2
Solução Proposta
Buscando auxiliar as atividades de avaliação, análise e ajuste de desempenho em banco de
dados MySQL, dentro do contexto apresentado, foi proposto o desenvolvimento uma aplicação que
efetue determinadas ações com o intuito de simular a execução de um ambiente acessando uma base
de dados em MySQL e efetuar de forma automatizada ou sugerir configurações para melhora de seu
funcionamento ou quando inicia-se o desenvolvimento de um novo projeto.
O foco do projeto é tornar a ferramenta capaz de monitorar o estado de um servidor MySQL,
analisando suas variáveis de execução (runtime) e relacionando-as com as variáveis de configuração
do SGBD MySQL, com foco na ferramenta de armazenamento InnoDB, extraindo dados para
formulação de possíveis ajustes. Quanto à automatização deste processo, o administrador poderá
interagir efetuando ou não os ajustes. Como exemplo, a variável de status ou runtime open_table
com uma quantidade maior em seu resultado em relação a variável de configuração, table_cache,
que determina a quantidade máxima de tabelas abertas no momento. Esta relação é uma das
possibilidades de analisar o funcionamento do MySQL.
16
O DBA poderá utilizá-la como apoio em um novo projeto para uma empresa, podendo
executar a ferramenta para simular uma possível carga com parâmetros estimados e avaliar qual a
melhor configuração para cada projeto, e assim, por exemplo, evitar a aquisição de novos
equipamentos, onde a real necessidade da empresa não é o investimento na aquisição de novas
tecnologias.
A ferramenta também auxiliará o DBA na configuração ideal para um novo projeto dentro
das características de acesso de determinada empresa.
1.2 OBJETIVOS
1.2.1
Objetivo Geral
Desenvolver uma ferramenta que simule, em uma base de dados MySQL, seu
funcionamento e apóie a análise para o ajuste de desempenho principalmente na configuração do
engine ou ferramenta de armazenagem, InnoDB.
1.2.2
Objetivos Específicos
•
Pesquisar e documentar conceitos de Análise e Ajuste de Desempenho do MySQL;
•
Realizar um levantamento de quais recursos a ferramenta de armazenagem InnoDB do
MySQL dispõe para efetuar análise e ajuste de desempenho;
•
Definir os requisitos a serem implementados na ferramenta;
•
Modelar a Ferramenta;
•
Implementar a Ferramenta;
•
Testar da Ferramenta; e
•
Documentar o desenvolvimento do trabalho de conclusão de curso.
17
1.3 Metodologia
Para o cumprimento das etapas e objetivos do TTC (Trabalho de Técnico-Científico) estão
descritas a seguir:
•
Redação da Pré-Proposta: documento ao qual foram descritos os principais objetivos e
etapas para conclusão do Curso de Ciência da Computação e posteriormente submetido à
aprovação por uma banca interna, que inclui: introdução, objetivo geral, objetivos
específicos, plano de pesquisa, atividades, recursos necessários, cronograma, orçamento
e referência bibliográfica;
•
Pesquisa Bibliográfica: o projeto (TTCI) iniciou com o levantamento de informações
técnicas com o intuito de formalizar a fundamentação teórica com ajuda de livros,
artigos, internet, programas para compartilhamento de arquivos e periódicos;
•
Revisão Bibliográfica: nesta etapa foi utilizada a pesquisa bibliográfica para construção
da fundamentação teórica. Etapa acompanhada com reuniões semanais com orientador e
entrega de relatórios quinzenais à coordenação do TTC;
•
Análise do Projeto: realizada análise e modelagem do sistema utilizando a UML para
desenvolvimento dos diagramas;
•
Implementação: neste tópico é apresentada toda a forma de desenvolvimento da
ferramenta, bem como as tecnologias empregadas na conclusão do simulador; e
•
Validação: os resultados e demonstração do funcionamento da ferramenta são
apresentados nesta seção, com um exemplo do resultado obtido após alteração da
configuração.
1.4 Estrutura do trabalho
A finalidade principal deste trabalho é levantar as funcionalidades existentes no banco de
dados MySQL para ajuste de desempenho, quanto a sua configuração, tendo como foco o engine ou
ferramenta de armazenamento InnoDB. Para tanto, foi desenvolvida uma ferramenta para simulação
em um ambiente especificamente para este fim.
Para início do desenvolvimento do trabalho, foi realizado um levantamento bibliográfico dos
principais assuntos que circundam a real função do projeto: levantamento de informações sobre o
18
MySQL e suas funcionalidades para ajuste de desempenho, estudo de ferramentas para
administração avaliando sua capacidade de efetuar análise e ajuste de desempenho. Esta revisão é
apresentada no Capítulo 2 – Fundamentação Teórica.
Seguindo com o levantamento dos requisitos funcionais e não-funcionais, diagramas UML
que compõe a etapa de projeto do sistema proposto.
Na seqüência é descrito no item Desenvolvimento, com os subitens Projeto, Implementação
Apresentação e Validação da ferramenta, todas as etapas para a conclusão do projeto.
19
2 FUNDAMENTAÇÃO TEÓRICA
Como pontos da fundamentação teórica desse trabalho técnico científico, são descritos 05
(cinco) tópicos: Conceitos de Avaliação e Análise de Desempenho, Banco de Dados MySQL,
Análise e Ajuste de Desempenho no MySQL, Ferramentas existentes para Análise e Ajuste de
Desempenho e Ferramenta de Armazenamento InnoDB.
2.1 AVALIAÇÃO E ANÁLISE DE DESEMPENHO
Em algum momento o administrador de banco de dados se vê obrigado a requerer mais
desempenho do banco de dados. Mais o que fazer para tentar melhorar? Uma consulta particular? O
Esquema ou hardware? A única maneira de saber é medir o que o sistema está fazendo e testar o
desempenho sob várias condições.
De acordo com Schwartz et al (2009), Avaliação e Análise de desempenho são duas práticas
essenciais para encontrar gargalos em bases de dados. Elas são relacionadas, mas não são as
mesmas. A avaliação mede o desempenho de um sistema e isso pode ajudar a determinar a
capacidade, mostra quais mudanças são importantes e quais não são, ou mostra como a aplicação
executa com dados diferentes.
Schwartz et al (2009) ainda comenta que, em contraste, a análise de desempenho ajuda a
encontrar onde a aplicação gasta mais tempo ou consome mais recursos. Em outras palavras,
avaliação de desempenho responde a pergunta “Quão bem isso executa?” e análise de desempenho
responde a pergunta “Por que isso executa desta maneira?”.
Para a realização de ajustes em um sistema de banco de dados, é necessário medir alguns
fatores, os quais são avaliados em conjunto ou individualmente. Estes fatores dividem-se em níveis
e seus componentes do banco de dados e, dependendo de seu estado atual, podem determinar a
situação de desempenho do sistema. O ajuste quando necessário pode ser efetuado separadamente
ou em conjunto com os níveis do banco de dados.
Os níveis e os componentes existentes de ajuste dividem-se em (SYBASE, 2004):
•
Ambiente de Hardware e Sistema Operacional:
o Rede: configuração, interfaces de rede, entre outros;
20
o Sistema Operacional: memória virtual, disco de swap, entre outros; e
o Hardware: controladoras de disco, barramentos, entre outros.
•
Ajuste do Servidor:
o Configurações de memória e cache;
o Métodos de acesso paralelo;
o Esquema de nível de bloqueio do servidor; e
o Espaço temporário do banco de dados, entre outros.
•
Ajuste de Aplicações:
o Normalização e Desnormalização de tabelas;
o Criação do Banco de Dados;
o Ajuste de Queries (SQL);
o Esquema de Lock (Bloqueio);
o Transações; e
o Cursores.
Schwartz etal (2009) completa que há duas estratégias primárias de avaliação de
desempenho: pode-se avaliar o desempenho da aplicação por inteiro ou apenas isolar algumas
partes. Essas duas estratégias são conhecidas como avaliação de desempenho full-stack (pilha
completa) e single-component (componente único), respectivamente. Há diversas razões para medir
a aplicação por inteira ou apenas o banco de dados:
•
Testar a aplicação inteira, incluindo o servidor web, o código da aplicação e o banco
de dados. Isso é útil porque não se deve importar com o desempenho do banco de
dados em particular e sim se importar com toda a aplicação;
•
O banco de dados nem sempre é o gargalo da aplicação, e uma avaliação de
desempenho full-stack pode revelar isso;
21
•
Somente testando a aplicação completa você pode ver como o cache de cada parte se
comporta; e
•
Avaliações de desempenho são boas somente à medida que refletem o
comportamento da aplicação atual, o que é difícil de fazer se o administrador estiver
testando somente parte dela.
Porém, nem sempre é necessário avaliar toda a aplicação, segundo Schwartz et al (2009).
Pode-se precisar somente de uma avaliação de desempenho do MySQL, pelo menos inicialmente.
Tal avaliação é útil para:
•
Comparar diferentes esquemas ou consultas;
•
Avaliar o desempenho de um problema específico que você vê na aplicação; e
•
Evitar uma longa avaliação em favor de uma mais curta que dê um “tempo de ciclo”
mais rápido para fazer e medir alterações.
Por este projeto focar nas configurações do MySQL, não se pode negar que a análise na
configuração das variáveis em um banco de dados é, na forma inicial ou mesmo na produção de um
projeto, de grande importância, pois nesta etapa tem-se a capacidade de reduzir ou eliminar os
problemas futuros dos demais pontos de gargalo.
2.2 BANCO DE DADOS MYSQL
Silberschatz e Korth (2006) definem um SGBD (Sistema Gerenciador de Banco de Dados)
como uma coleção de dados inter-relacionados e também de programas utilitários que são utilizados
para acesso e manipulação a estes dados. A principal função do SGBD é proporcionar um ambiente
conveniente e eficiente para recuperação e armazenamento das informações.
O SGBD MySQL é a ferramenta foco deste projeto, e para a qual será estudada o projeto da
análise e ajuste de desempenho. Um dos fatores motivadores desta escolha é sua forma de licença e
distribuição, pois MySQL é um SGBD livre e de código aberto, distribuído pela empresa Oracle, é
apoiado por uma comunidade grande e ativa de desenvolvedores (MYSQL, 2011).
22
O MySQL e demais produtos licenciados de acordo com o GNU (General Public), foi um
projeto que teve início em 1984, cujo principal objetivo era de garantir aos seus usuários, a
liberdade de compartilhar e alterar seus aplicativos, e assim tornando-os livres (LIMA, 2003).
A filosofia do software livre e/ou código aberto (Open Source) tem sido amplamente aderida
por pessoas físicas e empresas nos mais diversos segmentos, pelo simples fato de que, para sua
utilização não há necessidade de efetuar gastos com o pagamento de licenças de uso. Outras
características que tornam um software livre são as possibilidades de efetuar cópias, sua distribuição
e alteração.
Outros benefícios do software livre e/ou de código aberto é fazer com que haja a
possibilidade de pesquisar, estudar, mudar e aperfeiçoar os programas a fim de que eles sejam
adaptados à realidade de cada usuário (SOFTWARE LIVRE, 2011).
Outra vantagem no uso do software de código aberto é que as melhorias realizadas são
amplamente testadas e corrigidas pela comunidade que contribui com o seu desenvolvimento. Com
isso o usuário final tem a garantia de utilizar um software testado por diferentes pessoas em
máquinas nas mais diversas configurações, tendo assim uma garantia a mais da qualidade de suas
funcionalidades (SOFTWARE LIVRE, 2011).
Algumas vantagens também são citadas por Lima (2003) quanto à utilização de ferramentas
de código aberto:
•
Redução dos custos de utilização da ferramenta (geralmente custos baixos ou até mesmo
nenhum), na aquisição, na implantação e manutenção. Além disso, tem-se a liberdade ao
escolher o provedor de suporte;
•
Não há necessidade de administração das licenças;
•
O usuário final tem a liberdade de modificar, atualizar e corrigir o software, contratando
ou não um desenvolvedor para esse trabalho; e
•
Obtenção de uma vasta documentação de apoio na Internet, além de ter ao seu dispor
fóruns de discussão e a comunidade criada especialmente para manter o
desenvolvimento do software, com pacotes de correções, dicas, entre outros.
Em face a essas características, optou-se por realizar o projeto focando num SGBD de código
aberto por haver certa facilidade na obtenção das informações sobre como se atingir resultados
23
positivos no ajuste de desempenho, pela grande quantidade de contribuições da comunidade que
utiliza-o.
2.2.1
Arquitetura do MySQL
O MySQL é um servidor multi-threaded, que atende a vários usuários ao mesmo tempo,
para isso são criados múltiplos processos de execução em um único processo. Suas tarefas são
executadas em back-end, isto é, não são controladas pelo usuário.
Quanto a sua distribuição, o MySQL reúne diversos programas e bibliotecas de cliente
(client), ferramentas administrativas e API’S e muitos outros programas desenvolvidos e
disponibilizados por colaboradores e parceiros (LIMA, 2003).
Para um melhor entendimentos de como o MySQL provê suas funcionalidades, inteface e
gerenciamento é necessário primeiro conhecer sua estrutura de componentes e como é a sua ligação.
O MySQL é um gerenciador construído em múltiplas camadas, como visto na Figura 1, que
podem ser classificadas basicamente em (LIMA, 2003):
•
Camada de Aplicação;
•
Camada Lógica; e
•
Camada Física.
Camada de Aplicação
Camada Lógica
Camada Física
24
Figura 1. Arquitetura conceitual do MySQL: Camadas Básicas
Fonte: Adaptado de Lima (2003)
Na camada de aplicação é representada a interface de usuário, que é a forma com que o
servidor MySQL interage com seus usuários. Esta camada pode ser dividida conceitualmente em 03
(três) componentes:
•
Interface de Consulta: são as instruções DML (Data Manipulation Language) que é um
subconjunto da SQL (Structured Query Language) usada para selecionar e manipular
dados;
•
Cliente: pessoas ou programas que utilizam a interface do servidor MySQL; e
•
Interface de Administrador: representa os utilitários utilizados para administração do
servidor MySQL.
Na camada lógica têm-se as funcionalidades que são desenvolvidas pela Oracle, e por outras
empresas que colaboram com novas funcionalidades e/ou novos padrões, na qual subdivide-se em:
•
Processador de Consultas;
•
Gerenciamento de Transações; e
•
Gerenciamento de Recuperação.
E por último, a terceira camada que corresponde a forma como o MySQL mantém o
armazenamento físico dos dados em arquivos. Além dos dados, dicionários, índices, históricos
(logs), estatísticas e todo o controle dos recursos de memória são controlados pela camada física
(LIMA, 2003). Ela á composta por:
•
Gerenciador de Recursos;
•
Gerenciador de Buffers; e
•
Gerenciador de Armazenamento.
25
A arquitetura do MySQL é pouco diferente da dos outros servidores de banco de dados e é
útil para uma grande variedade de objetivos. MySQL é flexível para trabalhar bem em ambientes
muito exigentes, como aplicações web. Ao mesmo tempo, MySQL pode potencializar aplicações
embutidas, depósitos de dados, indexação de conteúdo e software de distribuições, sistemas
redundantes altamente disponíveis, processamento de transação on-line e muito mais (SCHWARTZ
et al, 2009).
2.2.2
Tipo de Tabelas ou Ferramentas de Armazenagem
Um BD (Banco de Dados) é composto de vários elementos onde cada um tem seu papel
fundamental em toda sua estrutura. Mas a tabela ou ferramenta de armazenagem é considerada de
maior importância neste contexto, pois sua função (guardar os dados) é o ponto chave da existência
de um BD. As tabelas são objetos bidimensionais que representam uma classe de objetos. Sua
estrutura é formada de linhas que são os registros, os quais se referem às ocorrências desses objetos
no mundo real, e as colunas ou campos, que são os seus atributos (MYSQL, 2011).
O MySQL suporta dois tipos diferentes de conjunto de tabelas: Tabelas Seguras com
Transação (TST) e Tabelas Não Seguras com Transação (TNST). Os tipos de tabelas são (MySQL,
2011):
Algumas tabelas do tipo TNST:
•
MyISAM;
•
MERGE;
•
ISAM; e
•
HEAP.
Algumas tabelas do tipo TST:
•
InnoDB; e
•
BDB ou BerkeleyDB.
Neste momento é importante descrever sobre os tipos de tabelas do MySQL, devido a
relação existente com os parâmetros de configuração e variáveis runtime. No item 2.3 do trabalho
esta relação é mostrada com mais detalhamento.
26
2.2.2.1 Tabelas MyISAM
A tabela padrão do MySQL é a MyISAM e seu desenvolvimento foi baseado no código das
tabelas ISAM. Fisicamente dividem-se em dois (02) arquivos com extensões .MYI (MYIndex) e
.MYD (MYData). O arquivo de extensão .MYI é utilizado para armazenamento dos índices e o
arquivo de extensão .MYD armazena os dados.
Na Tabela 1 são apresentadas algumas variáveis de configuração de ambiente que o MySQL
reserva para utilização da tabela MyISAM.
Tabela 1. Variáveis de Ambiente Tabela MyISAM
Variável
myisam_sort_buffer_size
Descrição
O buffer que é alocado ao ordenar o índice quando estiver
fazendo um REPAIR ou estiver criando índices com CREATE
INDEX ou ALTER TABLE
myisam_max_extra_sort_file_size É usado principalmente para forçar que longas chaves de
caracteres em tabelas grandes usem o método de cache de
chaves mais lenta para criar o índice.
myisam_repair_threads
Se este valor é maior que um, durante o processo reparo por
ordenação os índices de tabelas MyISAM serão criados em
paralelo - cada índice em sua própria thread.
myisam_max_sort_file_size
O tamanho máximo do arquivo temporário que é permitido ao
MySQL usar enquanto recria os índices (durante REPAIR,
ALTER TABLE ou LOAD DATA INFILE). Se o tamanho do
arquivo for maior que isto, o índice será criado através do
cache de chaves (que é mais lento).
Fonte: MySQL (2011)
2.2.2.2 Tabelas MERGE
Uma tabela do tipo MERGE é composta de outras tabelas do tipo MyISAM com a mesma
estrutura e que podem ser usadas como uma só. Isso quer dizer que, quando se criam tabelas do tipo
MERGE toda a sua coleção de tabelas deverá ser criada com informações de colunas e índices
idênticos. Este tipo não permite fundir tabelas que tenham sua estrutura diferente com as outras. Um
exemplo de sua utilização é quando há necessidade de inserir dados com meses diferentes em
arquivos separados (MySQL, 2011).
Com a estratégia de utilização deste tipo de tabela, algumas vantagens se tornam de grande
importância para o desempenho do Banco de Dados (MySQL, 2011):
27
•
Facilidade de gerenciamento de uma enorme quantidade de tabelas;
•
Maior velocidade de acesso, pois o seu conjunto de tabelas poderá estar alocado em
vários discos;
•
Tornar as pesquisas mais eficientes, pois permite que de acordo com uma consulta
desejada, se execute em apenas um dos pedaços da tabela;
•
As reparações tornam-se mais eficientes; e
•
Permite a compactação de pedaços da tabela, evitando assim desperdício de espaço,
entre outras.
Sua estrutura física é dividida em arquivos com extensão .FRM (contém a estrutura da
tabela) e do arquivo com extensão .MRG (contém a lista das tabelas MyISAM) (MySQL, 2011).
2.2.2.3 Tabelas ISAM
As tabelas do tipo ISAM tornaram-se obsoletas e tendem a desaparecer a partir da versão 5.0
do MySQL. A tabela MyISAM tornou-se o tipo que substituiu a ISAM e seus dados deverão ser
migrados antes que sua distribuição seja realmente cancelada. Os pontos chaves que levaram a esta
substituição é que as tabelas ISAM não são portáveis entre plataformas, não podem lidar com
tabelas maiores de 4 (quatro) GB (Gigabyte), suportam apenas compactação de prefixo em strings,
seu limite de chaves é menor, e outros (MySQL, 2011).
2.2.2.4 Tabelas HEAP
As tabelas HEAP utilizam índices hash e são armazenadas diretamente na memória. Isto as
torna muito mais rápidas, mas por outro lado menos confiáveis, pois se alguma falha ocorrer no
MySQL, os dados serão perdidos. Hash são tipos de tabelas onde sua estrutura é formada por array
e o acesso aos objetos é efetuado diretamente pelo índice calculado pela função hash que é o
retorno do índice informado pela chave. Por isso sua utilização será mais útil quando for aplicada
em tabelas temporárias. Outro cuidado que deve ser avaliado, quando for utilizar tabelas do tipo
HEAP, é que em uma instrução CREATE a variável MAX_ROWS deverá ser especificada,
evitando assim a utilização completa da memória acidentalmente (MySQL, 2011).
2.2.2.5 Tabelas BDB ou BerkeleyDB
28
As tabelas BDB ou BerkeleyDB contêm mecanismos de armazenamento transacional
podendo ter mais chance de sobrevivência a falhas e também são capazes de realizar operações
commit e rollback (MySQL, 2011).
2.2.2.6 Tabelas InnoDB
Segundo MySQL (2011), InnoDB é o tipo de tabela que provê um mecanismo de
armazenamento seguro de transações com commit (comando SQL onde confirma determinada
transação), rollback (comando SQL que desfaz toda a execução de uma transação) e recuperação
em caso de falhas. Este tipo de tabela faz bloqueio em nível de registro e também fornece leituras
sem bloqueios. Estes recursos, fazem com que haja um aumento do desempenho e a concorrência
de multiusuários. InnoDB foi desenvolvido para obter o máximo de desempenho ao processar um
grande volume de dados. Há relatos de sites que utilizam InnoDB em base com mais de 1
TeraBytes de dados, processando uma carga média de 800 inserções/atualizações por segundo
(MYSQL, 2011).
Na Tabela 2 são apresentadas algumas variáveis de configuração de ambiente que o MySQL
reserva para utilização da tabela InnoDB.
As principais características da InnoDB são: permite chaves estrangeiras, bloqueios a nível
de linha, versionamento múltiplo, agrupamento pela chave primária, todos os índices contém as
colunas
da
chave
primária,
cache
otimizado,
índices
descompactados
e
bloqueio
AUTO_INCREMENT.
É considerado um tipo de tabela lenta, pois seus dados são armazenados diretamente no
disco, não deixando em cache de escrita da RAM. Lento, porém proporcionalmente seguro (VTNC,
2011).
A tabela ou ferramenta de armazenagem InnoDB é considerada a tabela mais segura e
suporta transações e quatro níveis de isolamento de transação (SCHWARTZ et al, 2009). Com isso
considera-se, que, por ser mais utilizada, sofre mais oscilações com relação a desempenho, sendo
então escolhida como foco de estudo deste projeto.
29
Tabela 2. Variáveis de Ambiente Tabela InnoDB
Variável
innodb_file_per_table
Descrição
Esta opção faz com que o InnoDB armazene cada tabela
criada em seu próprio arquivo .ibd.
innodb_data_home_dir
É o caminho do diretório para todos os arquivos de dados
InnoDB.
innodb_data_file_path
Caminho para os arquivos de dados individuais e os seus
tamanhos.
innodb_mirrored_log_groups
Número de cópias idênticas de grupos de log mantidos para o
banco de dados.
innodb_log_group_home_dir
Caminho do diretório de arquivos de log do InnoDB.
innodb_log_files_in_group
Número de arquivos de log no grupo de log.
innodb_log_file_size
Tamanho de cada arquivo de log em um grupo de logs em
megabytes.
innodb_log_buffer_size
O tamanho do buffer que o InnoDB utiliza para escrever o
log em arquivos no disco.
innodb_flush_log_at_trx_commit
Normalmente é atribuído 1, significando que em um commit
de uma transação o log é descarregado para o disco e as
modificações feitas pela transação se tornam permanentes,
sobrevivendo a uma falha no banco de dados.
innodb_log_arch_dir
O diretório onde arquivos de log totalmente escritos seriam
escritos se usarmos arquivamento de log.
innodb_log_archive
Atualmente este valor deve ser definido com 0. Como a
recuperação ai partir de um backup deve ser feito pelo
MySQL usando os seus próprios arquivos de log, não há
nenhuma necessidade de se arquivos os arquivos de log do
InnoDB.
innodb_buffer_pool_size
O tamanho do buffer de memória que o InnoDB usa para
armazenar dados e índices de suas tabelas. Quanto maior for
este valor, menor será a necessidade de E/S (Entrada/Saída)
de disco para acessar dados na tabela.
innodb_buffer_pool_awe_mem_mb Tamanho da área de buffer em Mb (Megabyte), se estiver
localizado na memória AWE (Address Windowing
Extension) do Windows.
innodb_additional_mem_pool_size Tamanho do pool da memória que o InnoDB utiliza para
armazenar informações de dicionário de dados e outras
estruturas de dados internas
innodb_file_io_threads
Número de threads de E/S de arquivos no InnoDB.
innodb_lock_wait_timeout
Tempo limite em segundos que uma transação InnoDB pode
esperar por uma trava antes de fazer um rollback
innodb_force_recovery
Realiza dump de tabelas em um banco de dados corrompido.
Fonte: MySQL, 2011
30
2.3 ANÁLISE E AJUSTE DE DESEMPENHO DO MYSQL
Como foi visto na Seção 2.1, para se obter um bom resultado no ajuste de um SGBD deve-se
primeiramente realizar uma boa avaliação e análise, detectando os gargalos e definir estratégias,
para efetuar os ajustes quando necessário.
Em um ambiente de banco de dados, tem-se 03 (três) níveis que devem ser analisados de
forma independente ou em conjunto, tornando o ajuste no banco de dados mais refinado. Este
projeto visa desenvolver a ferramenta de simulação para análise e orientação no ajuste de
desempenho focado no segundo nível, que envolve o ajuste dos parâmetros de configuração, sendo
neste caso, da ferramenta de armazenagem InnoDB, distribuída com o MySQL. Completando este
nível de ajuste, temos também o ajuste de ambiente de hardware e sistema operacional e o ajuste na
aplicação.
2.3.1
Configuração de Parâmetros
Inicialmente, deve-se conhecer a forma como a configuração do MySQL Server é iniciada
na sua carga. No diretório raiz da instalação existe o arquivo my.cnf que é utilizado para incluir ou
alterar as configurações utilizadas na carga do sistema. Este arquivo contém variáveis de ambiente
com valores de inicialização, que podem ser alterados conforme dimensionamento do ambiente em
que o MySQL Server se encontra instalado.
O MySQL fornece no mesmo diretório, 05 (cinco) arquivos modelo de configuração, que
podem ser renomeados para my.cnf, conforme a disponibilidade de memória da máquina. São eles
(LIMA, 2003):
•
My-innodb-heavy-4G.cnf: para uso com tabelas InnoDB em sistemas com 4 GB de
memória ou mais;
•
My-huge.cnf: para sistemas com 1GB de memória ou mais;
•
My-large.cnf: para sistemas na faixa de 512 MB de memória;
•
My-medium.cnf: para sistemas entre 64 e 128 MB de memória; e
•
My-small.cnf: para sistemas com até 64 MB de memória.
31
Estes arquivos com configurações já pré-definidas foram projetados para serem distribuídos
na instalação do SGBD, tornando o trabalho de configuração o mais simples possível, mesmo que
não haja maiores dificuldades para isso, é somente um facilitador.
Na Figura 2 é mostrado um exemplo do arquivo de configuração do MySQL.
Figura 2. my.cnf: arquivo de configuração do MySQL
2.3.2
Instruções SQL
Algumas instruções SQL no MySQL Server servem para extrair informações de
configuração e estado de sua execução.
2.3.2.1 Instrução SHOW STATUS
A instrução SHOW STATUS fornece informações de status do servidor MySQL. Pode ser
executada em um aplicativo para administração do banco e que permita execuções de comandos
SQL, como por exemplo, o MySQL Query ou simplesmente com a interface de modo texto do
aplicativo mysql.exe, localizado no diretório \mysql\bin, utilizado para interação com o servidor
MySQL (MYSQL, 2011).
32
Na Tabela 5 dos anexos existe a listagem completa das variáveis de status e uma breve
descrição de seu significado. Algumas variáveis permitem análises de seus valores, confrontando-as
com as variáveis de configuração do servidor MySQL, e portando, novos ajustes poderão ser
efetuados pelo administrador do banco de dados.
2.3.2.2 Instrução SHOW VARIABLES
A instrução SHOW VARIABLES extrai informações das variáveis de configuração do MySQL
Server. Estas variáveis estão, de alguma forma, relacionadas com as de status, pois dependendo de
seus valores, será necessário alguma alteração na configuração do MySQL.
Segue alguns exemplos de variáveis de sistema (MySQL, 2011) com algumas sugestões de
ajustes:
•
Tmp_table_size: se uma tabela temporária em memória exceder este tamanho, o MySQL
irá convertê-la automaticamente para uma tabela MyISAM. Sugere-se aumentar o valor
de tmp_table_size caso seja realizada várias consultas GROUP BY avançadas e tiver
muita memória;
•
Thread_cache_size: quantas threads devem ser mantidas em cache para reutilização.
Quando um cliente desconecta, as threads dos clientes são colocadas na cache se não
existir mais de thread_cache_size threads que antes. Todas novas threads serão obtidas
primeiramente do cache, e só quando o cache estiver vazio uma nova thread é criada.
Esta variável pode ser aumentada para melhorar o desempenho se você tiver várias
conexões novas;
•
Sort_buffer: cada thread que precisar fazer uma ordenação aloca um buffer deste
tamanho. Sugere-se aumentar este valor para operações ORDER BY ou GROUP BY
tornando mais rápidas;
•
Slow_launch_time: se a criação de threads demorar mais que este valor (em segundos),
o contador Slow_launch_threads será incrementado;
•
Query_alloc_block_size: tamanho dos blocos de alocação de memória que são alocados
para objetos criados durante a análise e execução da consulta. Se houver problemas com
fragmentação de memória pode ajudar o incremento desta configuração;
33
•
Read_rnd_buffer_ae: ao ler registros na ordem depois de uma ordenação, os registros
são lidos através deste buffer para evitar pesquisas em disco. Pode melhorar bastante o
ORDER BY se configurado com um valor alto. Como esta é uma variável específica da
thread, não se pode defini-la globalmente, mas apenas alterá-la ao executar alguma
consulta específica grande; e
•
Read_buffer_size: cada thread que faz uma leitura seqüencial aloca um buffer deste
tamanho para cada tabela lida. Se houver várias leituras seqüenciais, este valor pode ser
aumentado.
Independente do tamanho de memória dimensionada para execução em um ambiente, o
MySQL “não sabe” quanto o computador possui. A configuração que o MySQL deve usar de
memória faz parte dos procedimentos de ajuste de desempenho (LIMA, 2003).
Na Seção 2.3.1 deste trabalho foi visto a forma como o MySQL configura os parâmetros de
carga e os arquivos de configuração pré-definidos dependendo da memória dimensionada no
servidor. Independente do arquivo modelo utilizado, será necessário adaptá-lo às particularidades de
cada computador, além de disco e memória, também a quantidade de clientes que podem acessá-lo.
O MySQL utiliza buffers e caches para acesso à arquivos em disco e que podem ser
compartilhados por outros processos (processos globais), ou também alocado para um processo
específico e fechado logo após sua conclusão. Pode-se definir cache como um local utilizado para
armazenagem de dados num curto espaço de tempo e buffer como uma área temporária para
armazenamento de dados em memória, aumentando a velocidade de operações de entrada e/ou
saída, reduzindo acesso a disco (LIMA 2003).
2.4 FERRAMENTAS PARA ANÁLISE DE DESEMPENHO
O MySQL dispõe de inúmeras ferramentas para apoio aos administradores de banco de
dados para obter um melhor desempenho de seu sistema e identificar possíveis problemas.
Nesta Seção são apresentadas algumas ferramentas para administração do MySQL com o
intuito de avaliar, além das funcionalidades básicas, também a existência de algum método de
análise e/ou ajuste de desempenho. São elas: Mysqlslap, Mysqladmin, phpMyAdmin, Innotop e
Tuning Primer.
34
Este estágio do projeto pretende identificar e estudar a execução de diversas ferramentas, na
intenção de obter como é realizado o desempenho para banco de dados, em que nível é atuado e
extrair idéias para o desenvolvimento do projeto final.
2.4.1 Mysqlslap – Cliente de Emulação de Carga
A ferramenta Mysqlslap é definida como um Cliente de Emulação de Carga e foi projetada
para emular em um servidor MySQL e informar o tempo de cada etapa. A ferramenta, que é
distribuída junto a instalação do MySQL, funciona como se vários clientes acessassem o servidor,
executando tarefas pré-determinadas (MYSQL, 2011).
Um exemplo pode ser visto na Figura 3, para execução da ferramenta via terminal. Nesta
execução, além dos outros parâmetros padrões, pode-se citar como mais importante (MySQL,
2011):
•
--auto-generate-sql: gera instruções SQL automaticamente quando não são
fornecidos em arquivos;
•
--concurrency=XXXX: o número de clientes para simular quando da emissão da
instrução SELECT;
•
--number-of-queries=XXXX: limite de cada cliente para sobrecarga em número de
consultas;
•
--number-char-cols=XXXX: o número de colunas VARCHAR para usar se - autogenerate-sql for especificado; e
•
--number-int-cols=XXXX: o número de colunas INT para usar se - auto-generate-sql
for especificado.
35
Figura 3. mysqlslap: terminal com o comando de execução da ferramenta
Na execução da ferramenta, com os parâmetros padrões mencionados, pode-se obter
(mostrado na Figura 4) o resultado final:
Figura 4. mysqlslap: resultado obtido do comando referente à Figura 3
Todas as consultas foram executadas e obteve-se um total de 13.658 segundos, onde 100
clientes concorreram na execução, numa média de 10 consultas por cliente.
Desta forma, a ferramenta mysqlslap permite e auxilia o administrador, em conjunto de
alguma ferramenta destinada a análise de desempenho, a obter o provável local onde deve atacar
para solucionar o problema causador da lentidão de um sistema, por exemplo.
36
2.4.2 Mysqladmin
A ferramenta ou cliente mysqladmin, é distribuída junto a instalação do MySQL, e sua
função é realizar operações administrativas via comandos no terminal. Algumas de suas funções
permitem verificar a configuração do servidor e do status atual, criar e apagar bases de dados e
outras (MYSQL, 2011).
Também é uma ferramenta aliada do administrador quando há necessidade de monitorar
algumas variáveis de configuração e execução de um servidor. No exemplo da Figura 5, pode-se
notar a execução de um comando acessando o MySQL, e a cada 5 segundos (-i5), monitorar todas
as variáveis de status do InnoDB.
Quando se utiliza em conjunto as ferramentas mysqlslap e mysqladmin, ou seja, em dois
terminais, há condição de efetuar uma carga desejada ao banco de dados e em outra tela de terminal,
monitorar as variáveis que se deseja.
Figura 5. mysqladmin: ferramenta de administração do MySQL
37
Somente o uso destas duas ferramentas, não garante ao administrador uma exatidão na
obtenção dos resultados desejados, devido à limitação e a inexistência de automação das tarefas
para ajuste. Talvez isso leve um tempo muito elevado para identificar e obter alguma anomalia na
configuração e execução do MySQL.
O trabalho proposto visa identificar e desenvolver a união das principais funcionalidades
encontradas nestas ferramentas e servirá de ajuda para o desenvolvimento prático.
2.4.3 phpMyAdmin
O phpMyAdmin é uma ferramenta livre e de código aberto desenvolvida com a linguagem
PHP e sua principal função é administrar o banco de dados MySQL. Seu desenvolvimento iniciouse em 1998 por Tobias Ratschiller, onde denominou de: “The phpMyAdmin Project”
(PHPMYADMIN, 2011).
Com esta ferramenta o usuário tem condição de criar e excluir banco de dados, tabelas,
definição de índices, chaves primárias e estrangeiras, executar comandos SQL, inserir e excluir
registros, e outras funcionalidades. Por se tratar de uma ferramenta desenvolvida em PHP (que é
uma linguagem livre), ela também se torna livre permitindo ao usuário final alteração e com isso
ampliar suas melhorias de acordo com suas necessidades (PHPMYADMIN, 2011).
Além das funcionalidades básicas para administração de banco de dados, o phpMyAdmin
permite a visualização das variáveis de runtime do MySQL. Estas informações são mostradas de
forma estatística, como mostra a Figura 6, onde o usuário poderá ver a quantidade e percentual em
que os comandos do MySQL foram executados, tráfego na rede do servidor MySQL em quantidade
de bytes do total recebido e enviado e a média por hora, as conexões abortadas e que tiveram falhas,
entre outras informações (PHPMYADMIN, 2011).
38
Figura 6. phpMyAdmin: tela com as Variáveis de Runtime do MySQL.
As variáveis de configuração do servidor MySQL podem ser visualizadas como mostra a
Figura 7. O phpMyAdmin não permite a alteração destas variáveis em tempo de execução
(PHPMYADMIN, 2011).
39
Figura 7. phpMyAdmin: tela com as Variáveis de Configuração do MySQL.
Além destas funcionalidades, o administrador tem condição de visualizar se há algum
usuário executando comandos indesejados ou alguma rotina que esteja em execução por um tempo
maior ao permitido, e com isso matar o processo degradante (PHPMYADMIN, 2011).
2.4.4 Innotop – Monitor em tempo real das conexões
Innotop é uma ferramenta para o MySQL InnoDB desenvolvida para monitoração de
transações / status do servidor. Cada um de seus modos mostra um aspecto diferente do que está
acontecendo no servidor. Por exemplo, há um modo para monitorar a replicação, um para consultas
e outro para transações. Innotop tem muitos recursos para usuários avançados, mas se pode iniciar e
executá-lo com nenhuma configuração.
Na Figura 8 foi obtido o resultado básico de uma monitoração do servidor MySQL com 100
usuários concorrentes.
40
Figura 8. Innotop: monitor de transações e status do servidor MySQL
É uma ferramenta simples, porém muito interessante onde o administrador pode utilizar
quando há necessidade de monitorar, com tempo programado, o que está sendo executado no
servidor MySQL.
2.4.5 Tuning Primer
O Tuning Primer é um script para Linux que avalia o status do servidor MySQL e sugere
mudanças na configuração. A execução do Tuning Primer é simples e de fácil entendimento como
pode ser visto na Figura 9 (PRIMER, 2011).
Figura 9. Tuning Primer: script para monitoração das variéveis de execução do servidor MySQL.
41
Na execução mostrada na Figura 10 pode-se analisar o módulo MAX_CONNECTIONS,
onde são apresentadas quatro variáveis para análise. Neste caso o servidor está ajustado para no
máximo 151 conexões ativas e no momento só existe uma ativa.
O script calcula, na quarta variável, o quanto acima ou abaixo está o percentual da
quantidade de conexões ativas no momento da execução e apresenta um aviso de que pode ser
ajustado o max_connection e ainda indica quais as conseqüências e possíveis melhorias deste ajuste,
como segue: “poderia ajudar a evitar uma alocação excessiva de memória”.
Figura 10. Tuning Primer: resultado do módulo MAX_CONNECTIONS
Como exemplo, outra análise pode ser feita no módulo InnoDB Status. A execução
apresenta a sugestão: “Dependendo de quanto espaço nos índices innodb, pode ser seguro aumentar
este valor para até 2 / 3 da memória total do sistema”.
•
INNODB STATUS
a. Current InnoDB index space = 0 bytes
b. Current InnoDB data space = 0 bytes
c. Current InnoDB buffer pool free = 96 %
d. Current innodb_buffer_pool_size = 8 M
e. Depending on how much space your innodb indexes take up it may be safe
f. to increase this value to up to 2 / 3 of total system memory
42
A ferramenta é um complemento, bem como as outras já apresentadas, para auxílio aos
administradores na localização e ajuste das configurações do MySQL. A ferramenta é um script,
que permite ao usuário final, alterar o modo de execução conforme as necessidades.
2.4.6 Resultado das Ferramentas Avaliadas
O objetivo deste trabalho foi de desenvolver uma ferramenta para simulação com
funcionalidades para ajuste de desempenho do MySQL. Desta forma, foi realizada uma análise com
as ferramentas pesquisadas e alguns testes, permitindo comparar entre as mesmas com vistas a
verificar qual é a ferramenta para apoio ao desenvolvimento do trabalho. A Tabela 3 mostra os
resultados alcançados.
Tabela 3. Comparativo das ferramentas para análise de desempenho do MySQL
Características
Ferramenta livre e/ou
código aberto
Multi-Plataforma
Permite ajuste de
parâmetros para
melhora no
desempenho
Depende de
ferramentas
comerciais para
alteração/compilação
Informa a necessidade
de ajuste do esquema
de banco de dados
Informa a necessidade
de ajuste nos
parâmetros de
configuração do banco
de dados
Informa a necessidade
de ajuste de hardware
Código bem
comentado e de fácil
compreensão
Ferramentas Avaliadas
Mysqlslap phpMyAdmin MyMonitor Innotop
Tuning Primer
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Não
Não
Não
Não
Sim
Não
Não
Não
Não
Não
Não
Não
Não
Não
Não
Não
Não
Não
Não
Não
Sim
Sim
Não
Não
Não
Não
Não
Sim
Sim
Sim
Sim
Sim
43
3 DESENVOLVIMENTO
Neste capítulo é demonstrado de forma geral a implementação da ferramenta. O projeto
encontra-se no Apêndice A.
3.1 IMPLEMENTAÇÃO
O ambiente para o simulador proposto foi escolhido e projetado para rodar com tecnologias
voltadas para web, facilitando a execução de forma remota e por contar com todas as ferramentas
livres para o administrador, empresa ou simplesmente de forma acadêmica.
Para o desenvolvimento da ferramenta foi utilizado como linguagem de programação o PHP,
e como complementação, o uso da técnica de programação ou conjunto de tecnologias com
denominação AJAX.
O PHP (acrônimo recursivo para “PHP: Hypertext Processor”) é uma linguagem
interpretada livre e utilizada para gerar conteúdo dinâmico da web. A linguagem surgiu em meados
de 1994, como um pacote de programas CGI criados por Rasmus Lerdorf, com o nome Personal
Home Page Tools, para substituir um conjunto de scripts Perl que ele usava no desenvolvimento de
sua página pessoal (WIKIPÉDIA PHP, 2012).
Trata-se de uma linguagem modularizada, o que a torna ideal para instalação e uso em
servidores web. Algumas de suas características:
•
Velocidade e robustez;
•
Estruturado e orientado a objetos;
•
Portabilidade;
•
Tipagem dinâmica;
•
Sintaxe similar a C/C++ e o Perl; e
•
Open source.
O AJAX (acrônimo em língua inglesa de Asynchronous Javascript and XML, que em
português significa “Javascript e XML Assíncronos”), teve grande importância na dinamização da
apresentação das telas e resultados obtidos na simulação. AJAX não é uma tecnologia, e sim um
conjunto de tecnologias conhecidas, trabalhando juntas, cada uma fazendo sua parte, oferecendo
novas funcionalidades (WIKIPÉDIA AJAX, 2012).
O ambiente de desenvolvimento e execução da ferramenta foi configurado utilizando uma
máquina instalada com sistema operacional Linux, distribuição Ubuntu versão 11.10. Esta escolha
foi motivada pela facilidade e sintonia do conjunto LAMP, ou seja, Linux, Apache, MySQL e PHP.
Dentre outras facilidades, destacam-se a segurança, a instalação automatizada pela Central
de Programas do Ubuntu e o Gerenciador de Pacotes Synaptic e principalmente a atualização das
versões ou correções automáticas dos pacotes que complementam o conjunto LAMP. Atualmente o
ambiente de trabalho e pacotes está atualizado e todo seu desenvolvimento foi nas versões:
•
MySQL Server e Client: 6.1.62;
•
PHP: 5.3.6-13; e
•
Apache: 2.2.20
Como se trata de uma ferramenta com tecnologias para desenvolvimento em ambiente web,
as telas foram escritas utilizando HTML 5 e CSS 3, ajudando também com velocidade de
desenvolvimento e na sua execução.
Em todo o processo de escrita da ferramenta, foi utilizado o editor BlueFish 2.0.3 e para
navegação o Firefox 12.0, que conta com um conjunto de opções para o desenvolvedor, como por
exemplo, o depurador de erros embutido por padrão no navegador. A característica principal de se
utilizar o Firefox é que na instalação do Ubuntu, este já é instalado com os demais pacotes o que
permite mantê-lo atualizado mais nova e prover a condição de execução das últimas versões das
linguagens de programação.
Outras ferramentas para auxílio na fase de desenvolvimento foram importantes para a
conclusão do projeto. São elas:
45
•
MySQL Administrator: permite gerenciamento de todo o servidor do banco de
dados, com acesso ao schema das bases, variáveis, configurações, etc.; e
•
MySQL Query Browser: ferramenta utilizada para execução e visualização dos
registros resultantes das simulações.
Ao iniciar uma base de dados nova, a ferramenta gera aleatoriamente cláusulas SQL, que
são utilizadas para executar a simulação e também para garantir que uma nova simulação seja
executada de forma idêntica; Por isso, estas funções são gravadas em uma tabela específica. A cada
simulação em uma base de dados que já sofreu no mínimo uma execução, ocorre a repetição destes
comandos.
As tabelas contendo os dados aleatórios populados na primeira execução da simulação e que
também sofrem alterações no decorrer da execução, são novamente carregados com os dados
originais da criação do ambiente, ou seja, toda a estrutura da base de dados é redefinida de acordo
com a original, o que garante a qualidade dos resultados obtidos.
O módulo das simulações foi desenvolvido utilizando laços, no qual sua função é fazer
chamadas às cláusulas SQL, utilizadas para obtenção dos resultados e apuração dos tempos de
execução. Em cada chamada utilizada, o MySQL recebe esta solicitação e inicia seu processamento.
Neste momento com o auxílio do AJAX, uma nova solicitação/chamada é enviada ao MySQL,
acontecendo com que o próprio SGBD utilizado faça a execução e controle das threads, evitando
este detalhamento via linguagem e programação, o que após várias tentativas e estudos, ficou
inviável. Esta execução ou chamada da próxima cláusula SQL, não depende do término da anterior,
e assim por diante. Desta forma, pode-se simular diversas chamadas em paralelo ao MySQL,
procurando sobrecarregar o SGBD e avaliar seu desempenho.
O simulador para análise e ajuste do banco de dados do MySQL projetado e desenvolvido,
por fim, é uma ferramenta de fácil compreensão e execução, porém conta com diversas tecnologias
mescladas, tornando-o razoavelmente complexo para um usuário iniciante. Finalizando, vale
mencionar e ressaltar a ocorrência de alguns riscos no decorrer de todo o trabalho, os quais são
descritos no item 3.2.1.
Alguns riscos no decorrer do projeto no TTCI foram levados em consideração e
mencionados em capítulos anteriores, bem como as prováveis soluções mapeadas, como seguem:
46
•
Viabilidade para reinicializar o MySQL automaticamente após o ajuste das variáveis,
sem a interferência manual do usuário;
Solução: sugerir após as modificações finalizar o simulador e reinicializar o MySQL por
linha de comando.
•
Utilização de threads para as chamadas das cláusulas SQL com as linguagens utilizadas
Solução: após estudos e a procura de diversas soluções para o uso de threads no PHP ou
Javascript, chegou-se a conclusão que mesmo não estando no lado da linguagem esta
técnica para a simulação de vários usuários, concorrendo com um mesmo banco de
dados, optou-se em considerar a própria execução do MySQL que interpreta e divide as
solicitações com cada uma sendo execuções paralelas. Isso tudo unido com a
técnica/tecnologia do AJAX, facilitou e demonstrou os resultados desejados na forma
dinâmica.
Ambos os riscos foram apresentados e de fato aconteceram no desenvolvimento da
ferramenta. As soluções mapeadas foram utilizadas para a conclusão do projeto.
3.2 APRESENTAÇÃO DA FERRAMENTA
Neste item é apresentada a execução do Simulador desenvolvido, conforme projeto
apresentado nos itens anteriores.
Quando o simulador é carregado, uma tela de login é apresentada para que o usuário faça o
acesso ao servidor MySQL, utilizando para isso, um usuário que tenha as permissões de
administrador, ou seja, usuário com permissão root. Na Figura 11, temos, como exemplo, o usuário
acessando com o usuário root padrão da instalação do MySQL.
Esta fase é importante, pois para os processos da ferramenta serem executados de forma
correta, dependem do acesso às tabelas de configuração e informações de schema do banco de
dados MySQL.
47
Figura 11. Tela de login do simulador.
Após a efetivação da conexão com o banco de dados, a tela inicial do simulador é
apresentada, conforme Figura 12, com opções organizadas em um menu único e uma tela com
informações iniciais do ambiente que está rodando, como usuário logado, versões do MySQL
(servidor e cliente), bem como o local onde se encontra a estrutura física (localhost ou endereço IP),
versão do Apache (servidor web) e da linguagem utilizada, o PHP.
48
Figura 12. Tela inicial.
O administrador inicia a execução da ferramenta selecionando, preferencialmente, a opção
Simulador do menu. Esta opção leva ao início das seleções para opção e parâmetros do simulador.
Na primeira tela, conforme Figura 13, pode optar por iniciar um ambiente novo ou em uma base de
dados existente no qual já passou por uma simulação.
Quando é selecionada a primeira opção, uma tela com os principais parâmetros é
apresentada, como mostra a Figura 14, permitindo configurar a base nova de acordo com suas
necessidades. O administrador deve informar nome da base de dados, prefixo e quantidade das
tabelas, quantidade de colunas, quantidade de registros por tabela e a quantidade de instruções, que
é internamente a quantidade de iterações utilizada no laço de execução.
49
Figura 13. Seleção para o tipo de simulação.
Figura 14. Seleção dos parâmetros para execução do simulador.
50
A segunda opção é a possibilidade de escolher por uma base de dados existente, com
simulações já realizadas. Na primeira situação, quando já houve uma simulação, o simulador recria
todo o ambiente conforme a primeira execução e executa sempre a mesma seqüência de instruções
SQL com mesmos dados, conforme item 3.2 Após todas as parametrizações efetuadas, a Figura 15
é apresentada para garantir o instante para o início da simulação. Permite assim que o usuário possa
voltar ao início das seleções para refazer os parâmetros.
Figura 15. Confirmação para início da simulação.
Com a confirmação para início da simulação, a próxima tela, demonstrada na Figura 16, é
apresentada para informar ao administrador a criação do ambiente, ou seja, as tabelas, população
dos dados, dos processos e tabelas auxiliares para a efetiva execução. Quando é iniciado um novo
ambiente para a ferramenta, existe um tempo dedicado para definição das tabelas auxiliares,
utilizadas para gravar as chamadas/funções SQL e os resultados obtidos das simulações. Isso é
importante, pois a cada nova execução ocorre a redefinição dos parâmetros para execução de uma
nova simulação que outrora já obteve resultados.
51
Figura 16. Tela com etapas do processo de criação do ambiente
Após todo o ambiente ser criado, o administrador clica no botão iniciar e a tela com as
informações da simulação é apresentada conforme demonstrado na Figura 17. Esta tela está dividida
em quatro partes distintas. A primeira, à esquerda na parte de cima, apresenta em uma textarea
sempre a última instrução SQL executada. Estas instruções são geradas aleatoriamente e guardadas
em uma tabela onde são sempre executadas quando existe a necessidade de se repetir uma nova
simulação. Assim que o AJAX retorna com a conclusão o administrador visualiza seu retorno. No
mesmo lado, mais abaixo, é apresentada uma tela com os processos do MySQL que estão ativos ou
inativos atualmente.
Completando a tela da simulação, o usuário pode acompanhar as principais variáveis de
configuração localizadas no lado direito e acima. A descrição de cada variável permite que após a
conclusão da simulação seja visualizada sua função e possível orientação para ajuste do ambiente.
52
Figura 17. Tela de simulação.
Completando o término da simulação, o administrador tem a possibilidade de visualizar os
tempos apurados em cada instrução executada. Além deste acesso, o sistema conta também com
uma opção no menu, conforme Figura 18 para acesso ao relatório de resultados. Permite visualizar
todos os bancos que passaram por uma simulação. A tela do relatório mostrado na Figura 19,
mostra os processos concluídos, onde ao posicionar o ponteiro no número seqüencial a instrução
SQL é apresentada; nas próximas colunas são apresentados os tempos de cada instrução por
simulação para a avaliação geral da melhora ou não do desempenho.
53
Figura 18. Seleção para os resultados da simulação.
Figura 19. Relatório com as simulações da base de dados selecionada.
54
O administrador conta com a opção de visualizar e alterar as variáveis de configuração do
MySQL. O sistema controla se cada variável que se deseja alterar pode ser no nível sessão ou
global. Quando alterado em sessão, esta alteração ficará valendo apenas para a base de dados atual.
Quando ocorre globalmente, valerá a alteração para todas as bases e usuários ativos.
Figura 20. Visualização e Alteração das variáveis de configuração.
Conforme mostra a tela na Figura 20, existe um botão ao lado de cada variável apresentada,
o que leva a abrir uma caixa para entrar com o novo valor correspondente a variável selecionada,
como mostrado na Figura 21. No instante da alteração, os erros ou efetivações provenientes do tipo
de alteração são mostrados para melhor entendimento do administrador.
55
Figura 21. Tela para alteração da variável de configuração do MySQL.
Além das alterações e visualizações das variáveis de configuração MySQL, a ferramenta
também está preparada para permitir a visualização das variáveis de execução ou também
conhecido, de status. Na Figura 22 é apresentado um exemplo em que todas as variáveis são
visualizadas, porém nesta parte do sistema nenhuma ação é permitida para o usuário. Cabe a cada
um analisar seus valores.
Também se pode ter acesso aos processos que estão em execução no servidor MySQL. A
tela para os processos, no exemplo da Figura 23, deixa como condição a quem esteja usando a
ferramenta, de matar o processo que previamente foi analisado e detectou-se que seu tempo de
execução está elevado, decorrente de alguma cláusula SQL apresentando problemas.
56
Figura 22. Tela para visualização das variáveis de execução/status.
Figura 23. Tela para visualização dos processos, com opção de matar processo.
57
3.3 VALIDAÇÕES DA FERRAMENTA
Para realizar a validação da ferramenta para simulação do MySQL, foi criada uma base de
dados configurada de acordo com a Figura 24, ou seja, o nome da base de dados escolhido para o
teste foi, VALIDADB, prefixo escolhido para as tabelas foi “sim_”, com duas tabelas contendo
cada uma vinte colunas e cem registros de dados. Para a iteração da simulação, foram criadas
quinhentas instruções SQL, de forma aleatória, conforme demonstra a Figura 25.
Figura 24. Validação do ambiente.
58
Figura 25. Lista de processos gerados aleatoriamente.
O teste se repetiu por três vezes, com o intuito de ter-se uma quantidade de dados para poder
iniciar o ajuste de uma variável, como exemplo, para apurar seus resultados e demonstrar a sua
execução. A variável escolhida e alterada foi a READ_BUFFER_SIZE, no qual foi passado do
valor padrão 131072 para 8200, conforme Figura 26. Após a alteração e ao executar a simulação
pela quarta vez com a alteração da variável acima, temos como resultado a Figura 27, que mostra
como foi prejudicado o tempo dos processos.
O
tempo
dos
processos
é
mostrado
no
formato
0.00000,
ou
“segundo(s).milisegundo(s)”, facilitando assim ao sistema extrair os cálculos das totalizações.
59
seja,
Figura 26. Alteração da variável Read_Buffer_Size.
Figura 27. Resultado simulação.
60
A cada simulação, o sistema tem por padrão, preparar o mesmo ambiente da execução
anterior. Isso faz com que os mesmos dados e cláusulas SQL sejam repetidos para uma melhor
qualidade dos resultados.
Mesmo apresentando-se um simples teste, com poucos registros, percebe-se o quão é
importante a influência dos ajustes que o banco de dados pode sofrer. Cabe cada administrador a
análise de forma mais profunda para extrair o melhor de seu desempenho.
O ajuste de desempenho em banco de dados não termina em uma simples configuração de
variável. Existem várias formas, de se obter os melhores resultados desejados da operação de um
banco ou servidor, e esta é uma delas e complementar as demais.
61
CONCLUSÃO
Inicialmente a ideia proposta foi o desenvolvimento de uma ferramenta para análise e ajuste
de desempenho para o MySQL sem o direcionamento de efetuar simulações. Logo uma nova ideia
foi levantada e optou-se por desenvolver as funcionalidades em uma ferramenta para simulação,
tornando sua execução mais intuitiva e com opção de identificar problemas antes mesmo de uma
base de dados entrar em funcionamento.
O tema proposto no projeto veio ao encontro das necessidades do desenvolvimento de uma
ferramenta para simular processos, com o intuito de gerar e obter dados para auxílio na análise e
ajuste de desempenho em banco de dados MySQL.
As funcionalidades propostas são direcionadas para a configuração de variáveis de sistema
juntamente com análise das variáveis de runtime. Mesmo sendo apenas uma das formas de medir e
ajustar desempenho em bancos de dados, considera-se de grande importância devido sua
abrangência em todos os outros métodos. Lembrando que as configurações um banco de dados são
apenas uma das formas de análise e ajuste para aumento de desempenho em um banco de dados.
Após a análise de algumas ferramentas para desempenho do MySQL, tornou-se mais visível
o que deveria ser proposto como funcionalidades do simulador. O Simulador, por suas
características de código aberto, pode permitir que melhorias sejam efetuadas e posteriormente
divulgadas à comunidade que adota a filosofia do código livre ou até mesmo para uso didático.
Outra característica é que para o desenvolvimento a linguagem utilizada também é livre.
Nos testes apresentados na seção de validação, tem-se uma melhor visão do funcionamento
da ferramenta para a simulação e como se pode obter melhoras significativas com os ajustes das
variáveis de configuração em um banco de dados.
A conclusão do projeto foi um desafio pelo desejo de colocar em prática as funcionalidades
modeladas. Também é almejado que as funções sejam melhoradas e ampliadas em todos os níveis
de otimização do MySQL, em trabalhos futuros.
Para trabalhos futuros, como sugestão, é desenvolver mecanismos de inteligência para
sugerir e ajustar de forma automatizada as variáveis de configuração.
REFERÊNCIAS BIBLIOGRÁFICAS
DUBOIS, P. MySQL administrator’s guide. MySQL USA: Press, 2004.
GUEDES, G. T. A. UML2: Guia de Consulta Rápida. São Paulo: Ed. Novatec, 2005.
INNOTOP. Manual do Usuário Innotop. <http://www.xaprb.com/blog/2006/07/02/innotopmysql-innodb-monitor/>. Acesso em: 24 set. 2011.
LIMA, Adilson da Silva. “MySQL Server. Soluções para Desenvolvedores e Administradores de
Bancos de Dados”. São Paulo: Ed. Érica, 2003.
MySQL. MySQL 5.5 Reference Manual. 04 abr. 2011. MySQL.
http://dev.mysql.com/doc/refman/5.5/en/index.html Acessado em: 04 abr. 2011.
Disponível em:
ORACLE. Oracle Brazil. Disponível em <http://www.oracle.com/br>. Acesso em: 19 set. 2011.
PHPMYADMIN. The phpMyAdmin Project. Disponível em: < http://www.phpmyadmin.net/>.
Acesso em: 2 out. 2011.
PRIMER, Tuning. MySQL Tuning Primer Script. Disponível em <https://launchpad.net/mysqltuning-primer>. Acesso em 3 out 2011.
PRONI, Ricardo Portilho. “SQL Magazine. MySQL Performance Diagnostics & Tuning”.
Grajaú/RJ: DevMedia, 2010.
ROSA, Jonas. “Desenvolvimento de uma Ferramenta para Análise de Ajuste de Desempenho do
Banco de Dados Oracle”. Itajaí, 2005. 88 f. Trabalho de Conclusão de Curso (Graduação em
Ciência da Computação) - Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do
Vale do Itajaí, Itajaí, 2005.
SCHWARTZ, Baron; et al. “Alto Desempenho em MySQL”. Rio de Janeiro: Alta Books, 2009.
SILBERSCHATZ, Abraham; KORTH, Henry F. “Sistemas de Banco de Dados”. São Paulo:
Makron Books, 2006.
SOFTWARE LIVRE. Comitê técnico de implementação de software livre no Governo Federal.
Disponível em <http://www.softwarelivre.gov.br>. Acesso em: 05 abr. 2011.
SYBASE. Performance e Tuning: Sybase Adaptive Server Enterprise. Modulo 1: Conceito de
Performance e Tuning. Develop IT Solutions, 2004.
VTNC. Velhas Tecnologias, Novos Conceitos. Disponível em <http://vtnc.org/52>. Acesso em: 15
set. 2011.
WIKIPÉDIA. Benchmark (Computação). Disponível em
<http://pt.wikipedia.org/wiki/Benchmark_(computa%C3%A7%C3%A3o)>. Acesso em: 05 set.
2011.
WIKIPÉDIA. AJAX (Programação). Disponível em
<http://pt.wikipedia.org/wiki/AJAX_(programa%C3%A7%C3%A3o)>. Acesso em: 23 mai. 2012.
WIKIPÉDIA. AJAX (Programação). Disponível em <http://pt.wikipedia.org/wiki/PHP>. Acesso
em: 23 mai. 2012.
64
APÊNDICES
65
A PROJETO
O projeto foi modelado com o objetivo de desenvolver a ferramenta (software) para
simulação da análise e ajuste de desempenho para o SGBD MySQL. Neste capítulo descrevem-se,
utilizando a UML (Unified Modeling Language, Linguagem de Modelagem Unificada) e a
prototipação da interface, as funcionalidades e dados necessários para o desenvolvimento da
ferramenta.
Os itens que compõem este capítulo são:
•
Listagem dos Requisitos Funcionais;
•
Listagem dos Requisitos Não Funcionais;
•
Diagrama de Casos de Uso;
•
Diagrama de Componentes; e
•
Diagrama de Implantação.
A.1 REQUISITOS
Os requisitos funcionais são definidos como listagem de funções e/ou atividades a qual a
ferramenta contempla para sua efetivação usada durante o desenvolvimento. Os requisitos não
funcionais relacionam características e/ou restrições que tangem todo o ambiente no qual a
ferramenta foi desenvolvida.
Neste item estão relacionados os requisitos funcionais e não funcionais para conhecimento
da ferramenta desenvolvida.
A.1.1 Requisitos Funcionais
•
RF01:
O sistema permite efetuar a autenticação ao MySQL Server;
•
RF02:
O sistema permite a visualização das variáveis de configuração do MySQL
Server;
66
•
RF03:
O sistema permite o ajuste das variáveis de configurações do MySQL Server;
•
RF04:
O sistema permite a visualização das principais variáveis de runtime
(execução) do MySQL Server;
•
RF05:
O sistema permite visualizar processos em execução no instante da
simulação;
•
RF06:
O sistema permite criar uma nova base de dados para simulação de acordo
com os parâmetros selecionados pelo administrador;
•
RF07:
O sistema permite popular tabelas de uma nova base de dados de acordo com
a quantidade informada pelo administrador;
•
RF08:
O sistema permite mostrar os resultados obtidos enquanto executa a
simulação; e
•
RF09:
O sistema permite disponibilizar uma área que contenha o relatório
proveniente das simulações, mantendo registros para consultas futuras.
A.1.2 Requisitos Não Funcionais
•
RNF01:
O SGBD foco da simulação da análise de desempenho é MySQL Server;
•
RNF02:
A linguagem utilizada é o PHP utilizando AJAX para dinamizar o processo,
evitando assim refresh dos módulos (DIVS);
•
RNF03:
Para execução do simulador é necessário estar rodando um servidor web
devido sua linguagem ser o PHP. Para este projeto foi utilizado o Apache2; e
•
RNF04:
Para desenvolvimento do projeto o Sistema Operacional Linux, distribuição
Ubuntu, foi utilizado como plataforma.
67
A.2 DIAGRAMA DE CASOS DE USO
O Diagrama de Casos de Uso é considerado o mais informal da UML, ocorrendo sua
utilização principalmente nas fases de levantamento e análise de requisitos de um sistema.
Representa os diversos cenários e responsabilidades do sistema (GUEDES, 2005).
A.2.1 Análise e Ajuste de Desempenho
Neste Diagrama de Casos de Uso estão descritas as funcionalidades propostas no projeto,
como mostra a Figura 28, fazendo referência aos Requisitos Funcionais relacionando-os na Tabela
4.
Figura 28. Diagrama de Casos de Uso: Análise e Ajuste de Desempenho.
68
Tabela 4. Matriz Requisito Funcional e Diagrama de Casos de Uso.
Requisitos
Funcionais
RF01
RF02
RF03
RF04
RF05
RF06
RF07
RF08
RF09
A.2.1.1
UC01
X
UC02
Diagramas de Casos de Uso
UC03
UC04
UC05
UC06
X
X
X
X
X
X
X
X
UC01. Efetua autenticação no MySQL Server
•
Descrição: efetuar autenticação no MySQL Server como administrador, permitindo
acesso a todas as funcionalidades do banco de dados.
•
Requisitos Funcionais atendidos: RF01
•
Pré-condições: o MySQL Server deve estar configurado corretamente para acesso
•
Pós-condições: acesso as funcionalidades do servidor
1. Cenário Principal:
1.1. O administrador inicia o Simulador;
1.2. Informa o usuário e senha, conforme Figura 29;
1.3. Seleciona botão OK; e
1.4. Efetua autenticação e mostra informações do servidor, conforme Figura 30.
2. Cenário Alternativo:
2.1. Caso o administrador não informe os dados corretamente para acesso ao MySQL, o
sistema volta ao passo 1.1 do cenário principal.
69
Figura 29. Efetua autenticação no MySQL Server.
Figura 30. Tela inicial com informações do servidor.
70
A.2.1.2 UC02. Visualiza Variáveis de Configuração do Sistema
•
Descrição: permite a visualização das variáveis de configuração do MySQL Server
•
Requisitos Funcionais atendidos: RF02
•
Pré-condições: sucesso na autenticação do MySQL Server
•
Pós-condições: variáveis de configuração foram visualizadas
1. Cenário Principal:
1.1. Acessa a opção Mostrar variáveis de sistema do MySQL;
1.2. Visualiza as variáveis de sistema do MySQL conforme Figura 31.
2. Cenário Alternativo:
2.1. No passo 1.2, caso o administrador opte por alterar alguma variável da base de
dados em simulação, executa o UC03 do item 3.2.1.3.
Figura 31. Visualiza Variáveis de Configuração do Sistema.
71
A.2.1.3 UC03. Altera Variáveis do MySQL
•
Descrição: permite alterar as variáveis de configuração do MySQL Server
•
Requisitos Funcionais atendidos: RF03
•
Pré-condições: base de dados simulada
•
Pós-condições: reinicializar o MySQL Server de forma manual, devido alterações no
arquivo de configuração do MySQL, conforme sugerido na alteração da variável
1. Cenário Principal:
1.1 Seleciona a variável para alteração, se estiver com problema ou não, conforme
Figura 32;
1.2 Abre a tela para alteração do valor da variável;
1.3 Altera o valor da variável e confirma;
1.4 Retorna à tela inicial do Simulador; e
1.5 Informa ao administrador a necessidade de reinicializar o MySQL por linha de
comando, aviso de efetivação da alteração ou quando não existe a possibilidade de
ateração.
72
Alterar
Figura 32. Altera Variáveis do MySQL.
A.2.1.4 UC04. Visualiza Variáveis de Runtime (Execução)
•
Descrição: permite visualizar as variáveis de runtime (execução) do MySQL Server em
modo dinâmico
•
Requisitos Funcionais atendidos: RF04
•
Pré-condições: uma base de dados foi selecionada
•
Pós-condições: variáveis de execução foram visualizadas
1. Cenário Principal:
1.1 Acessa a opção Mostrar informações de runtime (execução) do MySQL;
1.2 Visualiza as variáveis de runtime (execução) do MySQL, conforme Figura 33;
1.3 Permite verificar a existência de problema com alguma variável.
73
Figura 33. Visualiza Variáveis de Runtime.
A.2.1.5 UC05. Analisa Processos em Execução
•
Descrição: o sistema monitora os processos em execução e permite ao administrador
tomar a ação de matar o processo caso seu tempo de execução seja elevado do MySQL
Server
•
Requisitos Funcionais atendidos: RF05
•
Pré-condições: uma base de dados foi selecionada
•
Pós-condições: processos em execução foram listados
1. Cenário Principal:
1.1 Seleciona a opção Mostrar os processos;
1.2 Visualiza os processos, conforme Figura 34;
1.3 O sistema mostra o tempo e o processo que está sendo executado.
2. Cenário Alternativo:
74
2.1 Se houver algum com problema, permite ao administrador matar o processo que
esteja degradando o funcionamento da base de dados;
2.2 O administrador fecha a tela após efetivação da solução.
Figura 34. Analisa Processos em Execução.
A.2.1.6 UC06. Inicia a Simulação
•
Descrição: executa um simulador de processos para auxiliar na obtenção de dados e
informações pertinentes a análise e ajuste do MySQL Server, conforme Figura 35.
Executará concorrência de acesso em uma base de dados, efetuando inserções,
atualizações e eliminações e consultas, com o propósito de sobrecarregar o
funcionamento e assim garantir os resultados. Os resultados são guardados e uma tabela
para que posteriormente possa ser analisado todas as demais simulações.
•
Requisitos Funcionais atendidos: RF06, RF07, RF08 e RF09
•
Pré-condições: uma base de dados foi selecionada
•
Pós-condições: disponibilizar o resultado histórico das simulações de uma mesma base
de dados.
75
1. Cenário Principal:
1.1 Seleciona a base de dados já criada anteriormente para a simulação, conforme
Figura 36;
1.2 O sistema refaz toda a estrutura inicial para a nova simulação, com isso a cada
simulação os dados serão os mesmos e as cláusulas SQL serão executadas
seqüencialmente para todas as execuções;
1.3 Inicia a Simulação;
1.4 Monitora os resultados obtidos dinamicamente; e
1.5 Finaliza a simulação e gera as informações obtidas, conforme Figura 37.
2. Cenário Alternativo:
2.1 No passo 1.1, o DBA pode optar por criar uma base nova. Para isso, informa os
parâmetros solicitados pelo simulador, conforme Figura 36;
2.2 Inicia a população dos registros de forma automática conforme parâmetros
informados pelo administrador; e
2.3 Executa as etapas a partir do item 1.2 do Cenário Principal do UC06.
76
Figura 35. Inicia a Simulação.
Sim
Figura 36. Telas para opções do início da Simulação.
77
Não
Figura 37. Resultados Obtidos na simulação.
A.2.2 DIAGRAMA DE COMPONENTES
O diagrama de componentes está relacionado à estrutura de desenvolvimento de uma
aplicação. Alguns exemplos como módulos de código-fonte, bibliotecas, formulários, módulos
executáveis, entre outros formam este diagrama (GUEDES, 2005).
A.2.2.1
Configuração do Ambiente
O Diagrama de Componentes da Figura 38 mostra as ferramentas necessárias para a
execução do simulador.
78
Figura 38. Diagrama de Componentes.
A.2.3 DIAGRAMA DE IMPLANTAÇÃO
Para representação física de um ambiente é utilizado o Diagrama de Implantação. Podem ser
representados servidores, estações, topologia e protocolos de comunicação e qualquer outro aparato
físico para demonstrar a distribuição física (GUEDES, 2005).
A.2.3.1
Configuração Física
A Figura 39 mostra um exemplo de como o simulador pode ser executado; no servidor onde
o MySQL está instalado ou até mesmo em uma estação local ou remota interligada à rede.
79
- Simulador
- Simulador
Figura 39. Diagrama de Implantação: Configuração Física.
80
ANEXOS
81
I ANEXO A
Tabela 5. Variáveis de Status do servidor MySQL
Variável
Aborted_clients
Aborted_connects
Bytes_received
Bytes_sent
Com_xxx
Connections
Created_tmp_disk_tables
Created_tmp_tables
Created_tmp_files
Delayed_insert_threads
Delayed_writes
Delayed_errors
Flush_commands
Handler_delete
Handler_read_first
Handler_read_key
Handler_read_next
Handler_read_prev
Handler_read_rnd
Handler_read_rnd_next
Descrição
Número de conexões abortadas porque o cliente morreu sem
fechar a conexão corretamente
Número de tentativas que falharam ao tentar a conexão ao
servidor MySQL
Número de bytes recebidos por todos os clientes
Número de bytes enviados para todos os clientes
Número de vezes que os comandos xxx foram executados
Número de tentativas de conexão ao servidor MySQL
Número de tabelas temporárias implícitas em disco criadas
durante a execução de instruções
Número de tabelas temporárias implícitas na memória
criadas durante execuções de instruções
Quantos arquivos temporários o mysqld criou
Número de threads para tratamento de INSERT DELAYED
que estão em uso
Número de registros escritos com INSERT DELAYED
Número de registros escritos com INSERT DELAYED onde
algum erro ocorreu (provavelmente duplicate key)
Número de comandos FLUSH executados
Número de vezes que um registro foi apagado da tabela
Número de vezes que a primeira entrada foi lida de um
índice. Se este valor for alto, sugere que o servidor está
fazendo várias leituras de índices, por exemplo, SELECT
col1 FROM foo, assumindo que col1 é indexado.
Número de requisições para ler um registro baseado em uma
chave. Se este valor for alto, é uma boa indicação que suas
pesquisas e tabelas estão indexadas corretamente.
Número de requisições para ler o próximo registro na ordem
da chave. Este valor será aumentado o usuário consultar uma
coluna de índice com uma faixa restrita. Ele também
aumentará se forem feitas busca nos índices
Número de requisições ao registro anterior na ordem da
chave. Ele é principalmente usado para otimizar ORDER BY
... DESC.
Número de requisições para ler um registro baseado em uma
posição fixa. O valor será alto se você estiver executando
várias pesquisas que exigem ordenação do resultado.
Número de requisições para ler o próximo registro no
arquivo de dados. Será alto se você estiver fazendo várias
buscas na tabela. Geralmente sugere que suas tabelas não
Handler_rollback
Handler_update
Handler_write
Key_blocks_used
Key_read_requests
Key_reads
Key_write_requests
Key_writes
Max_used_connections
Not_flushed_key_blocks
Not_flushed_delayed_rows
Open_tables
Open_files
Open_streams
Opened_tables
Rpl_status
Select_full_join
Select_full_range_join
Select_range
Select_scan
Select_range_check
Questions
Slave_open_temp_tables
Slave_running
Slow_launch_threads
Slow_queries
Sort_merge_passes
estão corretamente indexadas ou que suas pesquisas não
foram escritas para tirar vantagem dos índices existentes.
Números de comandos ROLLBACK internos.
Número de requisições para atualizar um registro em uma
tabela.
Número de requisições para inserir um registro em uma
tabela.
O número de blocos utilizados no cache das chaves.
O número de requisições para ler um bloco de chaves do
cache.
O número de leituras físicas de blocos de chaves do disco.
O número de requisições para gravar um bloco de chaves no
cache.
O número de escritas físicas de um bloco de chaves para o
disco.
O número máximo de conexões simultâneas que foram
usadas.
Blocos de chaves no cache de chaves que foi alterado, mas
ainda não foi descarregado para o disco.
Número de registros esperando para serem escritos em filas
INSERT DELAY.
Número de tabelas abertas.
Número de arquivos abertos.
Número de fluxos abertos (usado principalmente para logs).
Número de tabelas que foram abertas.
Status de replicação segura. (Ainda não está em uso).
Número de joins sem chaves (Se for 0, você deve conferir
com cuidado o índice de suas tabelas).
Número de joins onde foram usadas pesquisas segmentadas
na tabela de referência.
Número de joins onde foram usadas faixas da primeira
tabela. (Normalmente não é crítica mesmo se o valor estiver
alto.)
Número de joins onde é realizada uma busca completa na
primeira tabela.
Número de joins sem chaves onde o uso de chave foi
conferido após cada registro (Se for 0, o índice de suas
tabelas deve ser conferido com cuidado)
Número de consultas enviadas para o servidor.
Número de tabelas temporárias atualmente abertas pela
thread slave.
É ON se este slave está conectado a um master.
Número de threads que levaram mais tempo do que
slow_lauch_time para serem criadas.
Número de consultas que levaram mais tempo que
long_query_time segundos.
Número de infusões feitas pelo algoritmo de ordenação. Se
este valor for alto você deve considerar o aumento de
83
Sort_range
Sort_rows
Sort_scan
ssl_xxx
Table_locks_immediate
Table_locks_waited
Threads_cached
Threads_connected
Threads_created
Threads_running
Uptime
sort_buffer.
Número de ordenações que foram feitas com limites.
Número de registros ordenados.
Número de ordenações que foram feitas lendo a tabela.
Variáveis usadas por SSL; Ainda não desenvolvido.
Número de vezes que um travamento de tabela foi obtido de
maneira automática.
Número de vezes que um bloqueio de tabela não pôde ser
obtido imediatamente e foi preciso esperar. Se o valor for
alto, e o usuário tiver problemas de desempenho, suas
consultas devem ser otimizadas e depois dividir sua tabela ou
tabelas ou usar replicação. Disponível a partir da versão
3.23.33
Número de threads no cache de threads.
Número de conexões atuais abertas.
Número de threads criadas para lidar com conexões.
Número de threads que não estão dormindo.
Quantos segundos o servidor está funcionando.
Fonte: MySQL (2011)
84