Escolar Documentos
Profissional Documentos
Cultura Documentos
por
por
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
vi
LISTA DE FIGURAS
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
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.
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.
xi
1 INTRODUÇÃ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.
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.
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.
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
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.
15
análise e o ajuste de desempenho, seja concluído naturalmente e muitas vezes sem a intervenção do
administrador.
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
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.
17
1.3 Metodologia
Para o cumprimento das etapas e objetivos do TTC (Trabalho de Técnico-Científico) estão
descritas a seguir:
• 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;
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.
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.
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.
20
o Sistema Operacional: memória virtual, disco de swap, entre outros; e
• Ajuste do Servidor:
• Ajuste de Aplicações:
o Transações; e
o Cursores.
21
• Somente testando a aplicação completa você pode ver como o cache de cada parte se
comporta; e
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:
• 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.
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;
• 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.
• 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 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).
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):
• MyISAM;
• MERGE;
• ISAM; e
• HEAP.
• InnoDB; e
• BDB ou BerkeleyDB.
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.
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;
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).
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).
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).
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).
É 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).
29
Tabela 2. Variáveis de Ambiente Tabela InnoDB
Variável Descrição
innodb_file_per_table 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.
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.
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.
Segue alguns exemplos de variáveis de sistema (MySQL, 2011) com algumas sugestões de
ajustes:
• 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;
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.
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).
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.
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):
35
Figura 3. mysqlslap: terminal com o comando de execução da ferramenta
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.
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).
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.
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 iniciou-
se 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).
38
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.
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.
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.
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
d. Current innodb_buffer_pool_size = 8 M
e. Depending on how much space your innodb indexes take up it may be safe
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.
43
3 DESENVOLVIMENTO
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.
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;
• Portabilidade;
• Tipagem dinâmica;
• 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).
• 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.
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
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.
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.
46
• Viabilidade para reinicializar o MySQL automaticamente após o ajuste das variáveis,
sem a interferência manual do usuário;
• 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.
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.
48
Figura 12. Tela inicial.
49
Figura 13. Seleção para o tipo de simulação.
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.
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.
52
Figura 17. Tela de simulação.
53
Figura 18. Seleção para os resultados da simulação.
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.
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.
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.
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.
59
Figura 26. Alteração da variável Read_Buffer_Size.
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.
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.
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.
GUEDES, G. T. A. UML2: Guia de Consulta Rápida. São Paulo: Ed. Novatec, 2005.
PRONI, Ricardo Portilho. “SQL Magazine. MySQL Performance Diagnostics & Tuning”.
Grajaú/RJ: DevMedia, 2010.
64
APÊNDICES
65
A PROJETO
• 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.
66
• RF03: O sistema permite o ajuste das variáveis de configurações do MySQL Server;
• 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;
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).
68
Tabela 4. Matriz Requisito Funcional e Diagrama de Casos de Uso.
Requisitos Diagramas de Casos de Uso
Funcionais UC01 UC02 UC03 UC04 UC05 UC06
RF01 X
RF02 X
RF03 X
RF04 X
RF05 X
RF06 X
RF07 X
RF08 X
RF09 X
1. Cenário Principal:
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.
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
1. Cenário Principal:
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.
71
A.2.1.3 UC03. Altera Variáveis do MySQL
• Descrição: permite alterar as variáveis de configuração do MySQL Server
1. Cenário Principal:
1.1 Seleciona a variável para alteração, se estiver com problema ou não, conforme
Figura 32;
72
Alterar
1. Cenário Principal:
73
Figura 33. Visualiza Variáveis de Runtime.
1. Cenário Principal:
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;
75
1. Cenário Principal:
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;
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;
76
Figura 35. Inicia a Simulação.
Sim Não
77
Figura 37. Resultados Obtidos na simulação.
78
Figura 38. Diagrama de Componentes.
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
80
ANEXOS
81
I ANEXO A
83
sort_buffer.
Sort_range Número de ordenações que foram feitas com limites.
Sort_rows Número de registros ordenados.
Sort_scan Número de ordenações que foram feitas lendo a tabela.
ssl_xxx Variáveis usadas por SSL; Ainda não desenvolvido.
Table_locks_immediate Número de vezes que um travamento de tabela foi obtido de
maneira automática.
Table_locks_waited 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
Threads_cached Número de threads no cache de threads.
Threads_connected Número de conexões atuais abertas.
Threads_created Número de threads criadas para lidar com conexões.
Threads_running Número de threads que não estão dormindo.
Uptime Quantos segundos o servidor está funcionando.
Fonte: MySQL (2011)
84