Uma abordagem prática de tuning em banco de dados, usando PostgreSQL

Transcrição

1 Uma abordagem prática de tuning em banco de dados, usando PostgreSQL Marcelo Josué Telles Universidade Federal do Rio Grande do Sul Instituto de Informática Caixa Postal Porto Alegre RS Brasil RESUMO Os bancos de dados são usados para gerenciar grandes volumes de informações, que geralmente são acessadas por muitos usuários ao mesmo tempo. A maioria das operações nestes bancos de dados devem ser atendias no menor tempo possível. A necessidade de tempo neste caso é aumentada em função do volume de dados armazenado, quantidade de usuários acessando, hardware utilizado, sistema operacional etc. Para diminuir o tempo de processamento das operações uma alternativa adotada é a otimização do banco de dados. Neste trabalho é feita uma análise sobre a performance do sistema gerenciador de banco de dados (SGBD) PostgreSQL. São feitos testes em uma instalação padrão e em uma instalação dotada de técnicas de tuning. ABSTRACT The databases are used to manage large volumes of information, which are usually accessed by many users at the same time. Palavras-chave tuning em banco de dados, otimização do banco de dados PostgreSQL, melhorar performance no banco de dados PostgreSQL, banco de dados tuned, otimização no postgresql.conf. Keywords tuning in databases, optimization database PostgreSQL, improving performance in the database PostgreSQL, database tuned, optimization in postgresql.conf. 1. INTRODUÇÃO Os SGBD têm por princípio armazenar e disponibilizar informações de forma conveniente e eficiente [9]. Geralmente estas informações são acessadas por um número significativo de usuários. Tais acessos geram processamento ocasionando consumo de recursos de hardware e aumento no tempo de resposta. Por padrão os sistemas gerenciadores de bancos de dados possuem as seguintes características [5]: Most operations in these databases must be met in the shortest time possible. The need for time in this case is increased according to volume of data stored, number of users accessing, hardware, operating system, etc.. To reduce the processing time of an operation is the alternative adopted optimization of the database. Present paper gives an analysis of the performance management system Database (DBMS) PostgreSQL. They are made in a test installation standard and a facility for which the techniques of tuning. A - atômicidade: significa que uma sentença ou transação composta por n declarações deve ser completamente realizada ou completamente não realizada; C - consistência: significa que os dados devem respeitar as regras de integridade do SGBD; I - isolamento: significa que cada sentença é executada isoladamente, ou seja, apenas uma sentença é executada em determinado instante; D - durabilidade: significa que as sentenças realizadas devem permanecer, não podem ser perdidas; Estas propriedades garantem o funcionamento sem se preocupar com o tempo de processamento. Tomamos como exemplo a seguinte situação: uma sentença de muitas declarações, típica de importação, onde se deseja inserir na base de dados, informações em larga escala. Para preservar o princípio de isolamento, tal sentença seria totalmente executada, enquanto isso as outras operações ficariam em uma fila de espera. Desta forma a questão da velocidade na

2 realização das operações em um SGBD, assume vital importância. conseqüências na estabilidade do serviço do Banco de Dados [10]. Diante isso, podemos afirmar que uma exigência que os SGBD devem atender é velocidade. Nos SGBD os problemas relacionados a velocidade se dividem em[9]: Problemas no Sistema Operacional (sistema de arquivos, serviços concorrentes etc.); Problemas no hardware (barramento incompatível, recursos mal dimensionados e ou compartilhados etc.); Problemas na elaboração das consultas, tais como ausência de boa prática (uso dos limites inferiores e superiores) nas consultas, ausência de indíces, junções desnecessárias etc.); Problemas nos ajustes e configuração do SGBD; Neste trabalho investigamos problemas nos ajustes e configuração do SGBD. Quanto a configuração e ajustes do SGBD temos três níveis de parâmetros [9]: 1. Hardware. Neste nível de parâmetro temos ajustes de uso dos discos, uso de sistema de RAID, adição de memória física, upgrade do processador etc. 2. Parâmetros do Banco de Dados. Neste nível temos ajustes de quantidade de memória utilizada pelos buffers de transações, intervalos de acesso ao disco, quantidade de cache e logs etc. 3. Parâmetros de esquema e transações. Neste nível podemos segmentar tabelas maiores em relacionamentos menores de acordo com a necessidade da consulta. Alterando a configuração em qualquer um destes trêz níveis, estamos aplicando tune no SGBD. Neste trabalho o foco do tune se concentra no segundo nível. O trabalho está dividido na seguinte estrutura: A seção dois apresenta técnicas e trabalhos relacionados, a seção três descreve o ambiente, hardware e software utilizados nos testes. A seção quatro mostra os testes e resultados obtidos. A seção cinco apresenta as conclusões. 2. TÉCNICAS E TRABALHOS RELACIO- NADOS O conceito de tuning em SGBD, está relacionado a realização de uma ou mais tarefas no menor tempo possível. Diminuir o tempo de realização das tarefas sem que isso tenha Conforme pesquisas sobre comportamento dos SGBD [2], o gerenciamento dos buffers permite melhorar o desempenho de algumas tarefas típicas, tais como: consultas inserções, atualizações e exclusões. Uma dose de cutela é recomendada quando se efetua redimensionamentos dos recuros de hardware para o SGBD, pois como é descrito no trabalho [1] este tipo de técnica muitas vezes pode até ocasionar perda de desempenho. Atualmente alguns trabalhos buscam obter uma visão global das tarefas realizadas pelos SGBD, para identificar quais as exigências de processamento e outros recursos de hardware [6], devem ser alocadas a cada momento. Alguns SGBD comerciais estão dando mais atenção para a idéia de tuning automático, como no caso do Oracle 10g [4]. 3. AMBIENTE Nos testes foi adotado um hardware padrão para a época em questão. Trata-se de um hardware bem estável e em pleno funcionamento. O sistema operacional foi o Debian, obtido através do web site debian.org [3] e o PostgreSQL, do web site postgre.org [7]. Para manipulação do SGBD foi utilizada a ferramenta phppgadmin, pgadmin III e pgbench. 3.1 Hardware O seguinte hardware foi adotado para realização dos testes: Processador Intel Core TM 2 Quad Q GHz, 8MB Cache; Placa mãe Asus Maximus Formula chipset Intel X38; Placa de vídeo GeForce 9800GTX+ chipset nvidia; Memória Corsair Dominator, com 2GB; Disco Rígido com capacidade de 160GB, SATAII; 3.2 Sistema Operacional O Sistema operacional instalado no equipamento de teste foi o Debian GNU/Linux versão Foi utilizada a versão i386 de 32bit. O sistema de arquivos adotado foi o ext2fs. Neste sistema operacional além do PostgreSQL os seguintes seviços estavam instalados e em processamento: samba, apache2 e openssh. 3.3 Versão do PostgreSQL O banco de dados instalado foi o PostgreSQL versão bit. Em algumas bibliografias ele é camado de Postgres. Este SGBD é open-source, desenvolvido pelo professor Michael Stonebraker na Universidade da Califórnia em Berkeley nos Estados Unidos. O nome Postgres derivou do sistema de banco de dados relacional Ingres, que também foi desenvolvido por Stonebraker [9]. A primeira versão de

3 sistema gerenciador de banco de dados chamada Postgres foi vista no ano de TESTES 4.1 Instalação padrão O SGBD PostreSQL por padrão é instalado levando em consideração configurações básicas de hardware e software, dando prioridade para a compatibilidade e não a velocidade [8]. Diante disso, podemos alterar alguns parâmetros de configuração. Estes parâmetros podem variar de acordo com a versão do PostgreSQL. Neste artigo estaremos tratando de alguns parâmetros do PostgreSQL versão 8.3. A alteração dos parâmetros de configuração, é feita através de um arquivo. O nome do arquivo é postgresql.conf. Em uma instalação padrão usando o sistema operacional Debian este arquivo fica no seguinte local: /etc/postgresl/8.3/main/postgreslq.conf Além de modificações diretamente no arquivo também existem ferramentas gráficas para manipulação dos parâmetros de configuração, uma delas é a pgadmin III. O arquivo de configuração contêm basicamente o valor de alguns parâmetros e variáveis que são usadas pelo SGBD. A sintaxe que o arquivo postgresql.conf adota é bastante flexível. Basicamente é composta por: name = value onde name é o nome da variável ou parâmetro e value é o valor que desejamos lhe atribuir. 4.2 Instalação usando tuning De acordo com o manual do PostgreSQL temos os seguintes recursos para ajustar o funcionamento do PostgreSQL(não trataremos todos): temp buffers = 64MB Neste parâmetro podemos definir o número máximo de buffers temporários utilizados por cada sessão de banco de dados. O padrão é de 8MB. work mem = 4MB Neste parâmetro definimos a quantidade de memória para ser usada por operações internas de classificação antes de alternar para arquivos temporários em disco. O valor padrão de é de 1MB. Para uma consulta complexa ou ordenacão, onde várias operações são executadas em paralelo, cada uma terá permissão para usar tanta memória quanto este valor especificar. maintenance work mem = 512MB Neste parâmetro podemos especificar a quantidade máxima de memória a ser utilizado em operações de manutenção, tais como VACUUM, CREATE INDEX, AL- TER TABLE e ADD FOREIGN KEY. O valor padrão é 16MB. É aconselhado que este valor seja maior do que o valor de work mem. wal buffers = 2MB Neste parâmetro podemos definir o tamanho do cache para gravação do log de transações. Apenas precisamos aumentar este valor, caso as transações forem muito grandes, por padrão este parâmetro é configurado para 64kB. A alteração em qualquer um destes parâmetros apenas terá efeito após a devida alteração, gravação do arquivo de configuração e reinicialização do SGBD com o seguinte comando: # /etc/init.d/postgresql-8.3 restart listen addresses = Neste parâmetro indicamos se o SGBD será acessível pelos computadores da rede TCP/IP na qual o computador servidor do SGBD esta conectado. Caso usarmos todos os computadores da rede podem se comunicar com o SGBD. max connections = 300 Neste parâmetro podemos definir o número de conexões aceitas pelo servidor. Este parâmetro foi defindo em 300, para simular uma situação real mais exigente, por padrão este parâmetro vêm definido em 100. shared buffers = 512MB Neste parâmetro podemos definir a quantidade de memória que o SGBD irá utilizar. Note que as alterações aqui devem obedecer os limites impostos. Para este parâmetro temos um mínimo recomendado de 128kB ou 16kB por conexão, definido no pelo parâmetro max connections. Para a realização do teste foi feito um script que gerou uma base de dados com uma tabela chamada template. A tabela foi constituída por quatro colunas: CREATE TABLE template (id integer, nome character varying(50) NOT NULL, numero integer, datacadastro timestamp without time zone); O script ainda alimentou esta tabela com vinte mil registros. Foi feita a seguinte consulta: EXPLAIN ANALYZE select * from template ORDER BY numero Tal consulta foi adotada visando exigir processamento elevado do SGBD, uma vez que este tipo de consulta não é comum, pois o correto seria utilizar um limitador superior e inferior para a busca.

4 No primeiro teste utilizando a instalação padrão o seguinte resultado foi obtido: tempo de 49,485ms: Foram feitos mais sete testes utilizando a instalação padrão, e os resultados obtidos foram os seguintes: 49,162ms, 48,788ms, 48,658ms, 48,899ms, 48,810ms, 48,903ms e 48,936ms. Em seguida o arquivo postgreslq.conf foi configurado conforme descrito na subseção Instalação usando tuning. O primeiro resultado foi de 37,630ms. Foram feitos mais sete testes, e os resultados foram os seguintes: 37,774ms, 37,704ms, 37,636ms, 37,603ms, 37,559ms, 37,602ms e 37,630ms. A tabela 1 apresenta os dados do primeiro comparativo. Tablela 1: Primeiro comparativo Teste Padrão Tuning 1 49,485ms 37,630ms 2 49,162ms 37,774ms 3 48,788ms 37,704ms 4 48,658ms 37,636ms 5 48,899ms 37,603ms 6 48,810ms 37,559ms 7 48,903ms 37,602ms 8 48,936ms 37,630ms Figura 2: insert de um registro Teste de delete envolvendo 100 registros. EXPLAIN ANALYZE DELETE FROM public. template WHERE id < 100 A figura 3 mostra o gráfico da análise de performance para a operação de delete. A figura 1 mostra o gráfico da primeira análise dos tempos necessários para a realização do select com order by na intalação padrão e na instalação utilizando tune. Figura 3: delete de 100 registros Teste de update envolvendo 100 registros. EXPLAIN ANALYZE UPDATE public. template SET nome= teste WHERE id <200 A figura 4 apresenta o gráfico da análise de performance para operação de update. Figura 1: Primeira análise entre instalação padrão e instalação com tune Após os testes do select com order by, foram feitos outros testes. Teste de insert de apenas um registro. EXPLAIN ANALYZE INSERT INTO public. template ( id, nome, numero, datacadastro ) VALUES (20001, teste679932, , :11:45 ) A figura 2 mostra o gráfico da análise de performance para operação de insert. Figura 4: update em 100 registros

5 Foram feitos testes usando o software pgbench. Comando para criação das tabelas. #./pgbench -i -s10 comando para realização dos testes: #./pgbench -n -U userdba -h localhost -c 300 postgres A tabela 2 apresenta o número de transações por segundo(tps) obtidos nos testes do pgbench. Quanto maior o TPS, significa que mais transações por segundo o SGBD é capaz de realizar. Tablela 2: Comparativo utilizando pgbench Teste Padrão Tuning TPS 1097 TPS TPS 957 TPS TPS 994 TPS TPS 1055 TPS TPS 974 TPS A figura 5 mostra o gráfico da análise do teste utilizando o pgbench. Figura 5: Teste utilizando o pgbench Finalizando as análises sobre performance. O script de criação da tabela e insersão dos registros necessitou de 12,40 segundos para ser realizado na instalação padrão enquanto na instalação tuned o tempo necessário foi de 11,70 segundos, representando 5,65 % de redução no tempo para realização do script. Para o cálculo deste e dos demais percentuais foi tomado como base o tempo necessário para realização do script na instalação padrão. 5. CONCLUSÕES As modificações no arquivo postgresql.conf permite diminuição significativa nos tempos de processamento consumidos pelas consutas no SGBD. de 24 %. Nas operações de inserção o tempo sofreu muitas oscilações, na exclusão o ganho chegou a 10 % e alteração os ganhos chegaram a 33 %. Estas análises confirmam a necessidade de implementação de tuning dinâmico, como apresentado pelo pesquisador Milanés [6]. Como as operações variam, realizando gravação/leitura em disco e memória e realizando processamento comparando e ordenando valores, as modificações no arquivo postgresql.conf deveriam acompanhar as exigências de cada operação que é realizada no SGBD. Para futuros trabalhos, poderiamos realizar testes em um hardware com mais de 2GB de memória RAM, usando sistema operacional e SGBD de 64bit. Além disso um sistema de discos em RAID 0. Elaborar testes usando um hardware apenas para servidor do banco de dados. Não rodar Apache, Samba e ssh. 6. REFERÊNCIAS [1] J. L. M. Alessandro Pinto Carneiro and A. L. C. de Freitas. Tuning - técnicas de otimização de banco de dados um estudo comparativo: Mysql e postgresql. Monografia de conclusão de curso, [2] S. L. Anolan Yamilé Milanés and M. A. V. Salles. Estado da arte em auto-sintonia de sistema de bancos de dados relacionais. Monografia de conclusão de curso, [3] Debian. Acessado em novembro, [4] K. Dias, M, Ramacher, U. Shaft, V. Venkataramani, and G. Wood. Performance diagnosis and tuning in oracle. In Online Procs Biennial Conf. on Innovative Data Systems Research (CIDR), pages 84 94, [5] H. Garcia-Molina, J. D. Ullman, and J. Widom. Database Systems: The Complete Book. Prentice Hall, Upper Saddle River, New Jersey 07458, [6] A. Y. Milanés and S. Lifschitz. Design and implementation of a global self-tuning architecture. Brazilian Symposium on Database, [7] O. PostgreSQL. Acessado em outubro, [8] W. PostgreSQL. Acessado em outubro, [9] A. Silberschatz, H. F. Korth, and S. Sudarshan. Database System Concepts. McGraw-Hill, [10] web site PostgreSQL. Acessado em outubro, Em resumo os ganhos mais significativos foram nas operações de busca com ordenação em alguns testes chegando a 28 %, sendo que a média de ganho nos testes(tabela 1), foi