UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 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

2 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

3 Itajaí (SC), Julho de

4 SUMÁRIO LISTA DE ABREVIATURAS... vi LISTA DE FIGURAS... vii LISTA DE TABELAS... ix RESUMO... x ABSTRACT...xi 1 INTRODUÇÃO PROBLEMATIZAÇÃO Formulação do Problema Solução Proposta OBJETIVOS Objetivo Geral Objetivos Específicos METODOLOGIA ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA AVALIAÇÃO E ANÁLISE DE DESEMPENHO BANCO DE DADOS MYSQL Arquitetura do MySQL Tipo de Tabelas ou Ferramentas de Armazenagem ANÁLISE E AJUSTE DE DESEMPENHO DO MYSQL Configuração de Parâmetros Instruções SQL FERRAMENTAS PARA ANÁLISE DE DESEMPENHO Mysqlslap Cliente de Emulação de Carga Mysqladmin phpmyadmin Innotop Monitor em tempo real das conexões Tuning Primer Resultado das Ferramentas Avaliadas DESENVOLVIMENTO IMPLEMENTAÇÃO APRESENTAÇÃO DA FERRAMENTA VALIDAÇÕES DA FERRAMENTA...58 CONCLUSÃO REFERÊNCIAS BIBLIOGRÁFICAS A PROJETO...66 iv

5 A.1 REQUISITOS 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 A.2.3 DIAGRAMA DE IMPLANTAÇÃO...79 v

6 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

7 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

8 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

9 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

10 RESUMO ARAUJO SILVA, Gustavo Ferreira de. Simulador de Análise de Desempenho para Banco de Dados MySQL. Itajaí, 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í, 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

11 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

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

13 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

14 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

15 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 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

16 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 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

17 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 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 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

18 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

19 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

20 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

21 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

22 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

23 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

24 positivos no ajuste de desempenho, pela grande quantidade de contribuições da comunidade que utiliza-o 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

25 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

26 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) 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

27 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) 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

28 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) 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) 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) Tabelas BDB ou BerkeleyDB 28

29 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) 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

30 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,

31 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 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

32 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 Instruções SQL Algumas instruções SQL no MySQL Server servem para extrair informações de configuração e estado de sua execução 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

33 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 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

34 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 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

35 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 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

36 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 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

37 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

38 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 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

39 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

40 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) 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

41 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 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

42 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

43 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 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

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

45 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 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: ; PHP: ; e Apache: 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 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

46 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 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

47 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

48 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

49 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

50 Figura 13. Seleção para o tipo de simulação. Figura 14. Seleção dos parâmetros para execução do simulador. 50

51 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

52 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

53 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

54 Figura 18. Seleção para os resultados da simulação. Figura 19. Relatório com as simulações da base de dados selecionada. 54

55 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

56 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

57 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

58 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

59 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 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 , ou segundo(s).milisegundo(s), facilitando assim ao sistema extrair os cálculos das totalizações. 59 seja,

60 Figura 26. Alteração da variável Read_Buffer_Size. Figura 27. Resultado simulação. 60

61 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

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

63 REFERÊNCIAS BIBLIOGRÁFICAS DUBOIS, P. MySQL administrator s guide. MySQL USA: Press, GUEDES, G. T. A. UML2: Guia de Consulta Rápida. São Paulo: Ed. Novatec, INNOTOP. Manual do Usuário Innotop. < Acesso em: 24 set LIMA, Adilson da Silva. MySQL Server. Soluções para Desenvolvedores e Administradores de Bancos de Dados. São Paulo: Ed. Érica, MySQL. MySQL 5.5 Reference Manual. 04 abr MySQL. Acessado em: 04 abr Disponível em: ORACLE. Oracle Brazil. Disponível em < Acesso em: 19 set PHPMYADMIN. The phpmyadmin Project. Disponível em: < Acesso em: 2 out PRIMER, Tuning. MySQL Tuning Primer Script. Disponível em < Acesso em 3 out PRONI, Ricardo Portilho. SQL Magazine. MySQL Performance Diagnostics & Tuning. Grajaú/RJ: DevMedia, ROSA, Jonas. Desenvolvimento de uma Ferramenta para Análise de Ajuste de Desempenho do Banco de Dados Oracle. Itajaí, 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í, SCHWARTZ, Baron; et al. Alto Desempenho em MySQL. Rio de Janeiro: Alta Books, SILBERSCHATZ, Abraham; KORTH, Henry F. Sistemas de Banco de Dados. São Paulo: Makron Books, SOFTWARE LIVRE. Comitê técnico de implementação de software livre no Governo Federal. Disponível em < Acesso em: 05 abr SYBASE. Performance e Tuning: Sybase Adaptive Server Enterprise. Modulo 1: Conceito de Performance e Tuning. Develop IT Solutions, VTNC. Velhas Tecnologias, Novos Conceitos. Disponível em < Acesso em: 15 set WIKIPÉDIA. Benchmark (Computação). Disponível em < Acesso em: 05 set

64 WIKIPÉDIA. AJAX (Programação). Disponível em < Acesso em: 23 mai WIKIPÉDIA. AJAX (Programação). Disponível em < Acesso em: 23 mai

65 APÊNDICES 65

66 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

67 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

68 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

69 Tabela 4. Matriz Requisito Funcional e Diagrama de Casos de Uso. Requisitos Funcionais RF01 RF02 RF03 RF04 RF05 RF06 RF07 RF08 RF09 A 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 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

70 Figura 29. Efetua autenticação no MySQL Server. Figura 30. Tela inicial com informações do servidor. 70

71 A 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 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 Figura 31. Visualiza Variáveis de Configuração do Sistema. 71

72 A 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

73 Alterar Figura 32. Altera Variáveis do MySQL. A 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

74 Figura 33. Visualiza Variáveis de Runtime. A 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

75 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 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

76 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 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

77 Figura 35. Inicia a Simulação. Sim Figura 36. Telas para opções do início da Simulação. 77 Não