I. O documento discute tuning de banco de dados, que envolve o ajuste do SGBD para melhorar o desempenho e a utilização de recursos de forma eficiente. II. Foram realizados testes de desempenho comparando PostgreSQL e MySQL em diferentes sistemas operacionais e configurações. III. Os resultados mostraram que PostgreSQL teve melhor desempenho que MySQL em alguns casos, mas seu desempenho caiu com maior carga, indicando a necessidade de tuning para melhorar em ambientes com muitas conexões.

1. Banco de Dados
Equipe: Carlos Jorge Ribeiro
Felipe Caiuby
James Moreira
Professora: Celinia Cantalice
ESTUDO DE CASOS EM FERRAMENTAS QUE
UTILIZAM TUNING

2. Tuning
• Tuning diz respeito ao ajuste do SGBD para melhor
utilização dos recursos deste, provendo um uso eficaz e
eficiente do SGBD.
• Tuning requer conhecimento de:
– Desenvolvimento de Aplicações
– SGBD
– Sistema operacional
– Hardware
Portanto, é necessário monitorar e revisar o projeto físico de banco de dados
constantemente. Os objetivos da sintonia (ou tuning) são os seguintes: I. fazer com
que as aplicações sejam executadas mais rapidamente, II. diminuir o tempo de
resposta de consultas/transações e III. melhorar o desempenho geral das
transações.

3. Tuning
• Em Tuning, comumente serão utilizadas informações de
estatísticas de uso de HW:
– Utilização do processador
– Atividade de I/O
– Paginação
– Memória utilizada
– ...

4. Tuning
Critérios Adotados
De uma forma simplificada, existem alguns critérios principais
que podem ser adotados para identificar as consultas que devem
ser modificadas, são eles:
• monitorar as sessões ativas que estão sendo executadas no
banco de dados;
• separar as consultas que estão com execuções demoradas, •
dividi-las em grupos, como: prioridade, freqüência de execução e
fraco desempenho;
• implementar os ajustes reescrevendo as consultas que estão
com fraco desempenho. Cada banco de dados fornece suas
ferramentas específicas para capturar as consultas citadas nos
itens acima, porém a maneira mais eficiente e explícita é o
próprio uso feito pelo usuário final.

5. Tuning
Particionar Gargalos
– O sistema fica lento geralmente porquê há
algum(uns) componentes limitando a performance
como um todo. Agir nesta parte é o correto.
– Particionar permite reduzir a carga de um certo
componente do sistema.
– Lição: quando encontrar um gargalo, primeiro tente
agilizar o componente que causa o gargalo, se não
conseguir sucesso particione.

6. Tuning
Custos de inicialização são altos, custos de
execução são baixos
– Uma operação de leitura é cara para iniciar, mas
menos cara enquanto se lê. Portanto, tente fazer
leituras mais longas, colocando tabelas que sofrem
scan constantemente serem armazenadas de forma
contígua
– O mesmo raciocínio vale para abertura de conexões
com o SGBD, parsing de consultas muito usadas,
envio de mensagens na rede (tamanho das
mensagens)

7. Tuning
Coloque no servidor apenas o que diz respeito ao
servidor
– Saber fazer o load-balancing, permitindo não
sobrecarregar o servidor de banco de dados com
tarefas que poderiam estar em outras camadas.

8. Tuning
Esteja preparado para trade-offs
– Adição de índices
– Verificar as vantagens/desvantagens entre a compra
de mais recursos versus a agilidade que se irá obter
destas aquisições.

9. Tuning
Cinco fatores influem na performance:
– Workload (carga)
– Throughput (Vazão)
– Recursos
– Otimização
– Contenção

10. Tuning
• Workload
– Define a demanda do BD. Combina transações
online, batch jobs, consultas ad hoc, data
warehousing, consultas analíticas, e comandos
dirigidos ao SGBD
– Pode variar drasticamente de dia para dia, hora para
hora, minuto para minuto, segundo para segundo.
– Algumas vezes é previsível (Rodar a folha de
pagamento no final do mês), mas muitas vezes é
imprevisível
– Workload tem grande impacto na performance do
SGBD

11. Tuning
• Throughput
– Define a capacidade do hardware/software para
processar os dados
– É composto de velocidade de I/O, velocidade de
CPU, capacidades de paralelismo, e eficiência do
SO.
– Kernel do DB, espaço em disco, controladores de
cache, e microcode são exemplos dos recursos a
serem avaliados para computar throughput

12. Tuning
• Otimização
– Refere-se à análise das solicitações ao BD com
custo de query que geram diferentes planos de
acesso aos dados.
• Contenção
– Quando a demanda (workload) para uma recurso
particular é alta então contenção acontece.
– É a condição na qual dois ou mais componentes de
workload estão tentando usar um recurso em modo
conflitante.
– À medida que a contenção aumenta, o throughput
diminui.

13. Tuning
Padrões e Otimizações
Serão apresentados nesta seção os testes que serviram como base
para medir o desempenho do SGBD PostgreSQL em relação ao SGBD
MySQL, bem como um comparativo de seus desempenhos em
diferentes sistemas operacionais e sistemas de arquivos. A partir destes
comparativos foram desenvolvidas configurações de otimização para o
SGBD PostgreSQL e realizadas novas medições de desempenho com o
objetivo de demonstrar que o processo de otimização pode gerar
algumas melhorias significativas quando realizado corretamente.

14. Tuning
Tabela 1: Sistemas operacionais utilizados
Sistema Operacional Sistema de Arquivos
Windows XP Home SP2 NFTS
Linux Kernel 2.6.18 ReiserFS
Linux Kernel 2.6.18 Ext3
Partindo do objetivo de gerar testes de desempenho confiáveis e certificados,
foi escolhido o método TPC-C, a partir deste método foi desenvolvido um
conjunto de testes para serem executados nos diferentes sistemas
operacionais e sistemas de arquivos abordados no projeto. Primeiramente
foram configurados três sistemas operacionais distintos e estes sistemas estão
especificados na Tabela 1.

15. Tuning
Padrões e Otimizações
TPC-C (Transaction Processing Perfomance council) simula um ambiente de
computação completo, onde uma população de usuários
executa as transações contra um banco de dados. Nele são
avaliados quesitos como:
• A execução simultânea de vários tipos de transações
que abrangem uma amplitude de complexidade;
• Várias sessões de terminais on-line;
• Integridade da transação (propriedades ACID);
• Distribuição não uniforme de acesso a dados por meio
de chaves primárias e secundárias.

16. Tuning
Padrões e Otimizações
Como conjunto de testes para utilização do método TPC-C no software
BenchmarkSQL adotou-se as três configurações para transações
demonstradas na Tabela 2.
Tabela 2: Conjunto de testes para o método TPC-C e tamanho aproximado da
base de dados resultante
Nº de WareHouses Nº de Terminais Tamanho Decorrente
1 10 300MB
10 10 1GB
10 100 1GB

17. Tuning
Padrões e Otimizações
Resultados Obtidos Seguindo o conjunto de testes especificado, foi utilizado o
software BenchmarkSQL nos sistemas citados anteriormente, utilizando a
configuração padrão dos SGBDs PostgreSQL e MySQL. Os resultados destes
testes serão demonstrados a seguir.
Tabela 3: Resultados obtidos com as configurações padrão para execução de
1 warehouses e 10 terminais
WeareHouse 1 - Terminais 10
Sistema Operacional Configuração Nº Transação Média TPm Duração (min)
Windows - NTFS
PostgreSQL 13078 577,4698178 10
MySQL 19546 887,6759983 10
Linux - ReiserFS
PostgreSQL 21961 993,6732044 10
MySQL 17846 796,1059276 10
Linux - Ext3
PostgreSQL 11744 536,5409173 10
MySQL 14957 673,0266379 10

18. Tuning
Padrões e Otimizações
Pode-se constatar que o SGBD MySQL obteve um desempenho
superior ao SGBD PostgreSQL, em duas situações. Estas foram
utilizando o sistema operacional Windows com NTFS, e no sistema
operacional Linux utilizando Ext3, para o teste de 10 terminais e 1
warehouse que utiliza uma base de dados de aproximadamente
300MB de espaço em disco. No sistema operacional Linux utilizando
ReiserFS foi constatado que o SGBD PostgreSQL apresenta um bom
desempenho em sua configuração padrão em comparação com o
SGBD MySQL, para este teste que apresenta um número não muito
grande de conexões concorrentes.

19. Tuning
Padrões e Otimizações
Tabela 4: Resultados obtidos com as configurações padrão para
execução de 10 warehouses e 10 terminais
WeareHouse 10 - Terminais 10
Sistema Operacional Configuração Nº Transação Média TPm Duração (min)
Windows - NTFS
PostgreSQL 7413 330,4362277 10
MySQL 13416 593,6841333 10
Linux - ReiserFS
PostgreSQL 10649 476,1026567 10
MySQL 13187 595,8599724 10
Linux - Ext3
PostgreSQL 6547 294,8913817 10
MySQL 11154 361,796517 10

20. Tuning
Padrões e Otimizações
Constatou-se que conforme são aumentados os números de conexões
concorrentes o SGBD PostgreSQL apresenta uma queda de
desempenho inclusive no sistema operacional Linux utilizando
ReiserFS, isto devesse ao fato de que a configuração padrão do
SGBD PostgreSQL não é otimizada para ambientes OLTP (OnLine
Transaction Processing), que possuem grande número de conexões
concorrentes e consultas simples. Desta forma constatou-se a
necessidade de otimizar o SGBD PostgreSQL a fim de melhorar o seu
desempenho neste tipo de ambiente.

21. Tuning
• Conclusao
– Performance de BD pode ser definida como a otimização
de uso de recursos para aumentar a throughput e minimizar
a contenção, possibilitando o maior workload possível ser
processado.
– Um monitoramento efetivo de performance e estratégia de
tuning requer não apenas expertise no SGBD mas
conhecimento que vai além da administração de BD.

22. Tuning
• Referëncias
http://repositorio.furg.br/bitstream/handle/1/1692/TUNI
NG.pdf?sequence=1

23. Banco de Dados
Equipe: Carlos Jorge Ribeiro
Felipe Caiuby
James Moreira
Professora: Celinia Cantalice
ESTUDO DE CASOS EM FERRAMENTAS QUE
UTILIZAM TUNING
Obrigado!