3. Sobre mim
Mestre e doutorando em computação pelo ITA
Escritor da SQL Magazine, Fórum Access, Java
Magazine, SQLServerCentral.com e outras
Colaborador do iMasters há 10 anos
Autor do livro “Conversando sobre banco de dados”
Co-autor do @databasecast
3 | 14/04/2012 |
4. Roteiro
Hardware e HPC
Processamento paralelo no SGBDR
Paralelisando instruções SQL
Demonstrações
Testes de desempenho
Análise dos resultados
Conclusão
4 | 14/04/2012 |
5. Processamento paralelo - hardware
Era de processadores multi-core (lógicos/físicos)
Virtualização: controle de processadores lógicos
Licenciamento do SGBD: depende de número de processadores
Fabricante fornece o valor máximo de processamento em GFLOPS
Para lembrar:
1 megaflop = 1 milhão de flops = 10^6 operações p.f. por segundo
1 gigaflop = 1 bilhão de flops = 10^9 operações p.f. por segundo
1 teraflop = 1 trilhão de flops = 10^12 operações p.f. por segundo
1 petaflop = 1 quatrilhão de flops = 10^15 operações p.f. por segundo
Processador topo de linha: 50~70 GFLOPS
No máximo 10% disso é utilizado
É preciso muito esforço de programação para obter bom desempenho
Solução: uso de processamento paralelo
5 | 14/04/2012 |
6. Processamento paralelo - HPC
HPC: High Performance Computing
Supercomputadores: lista TOP500 (http://www.top500.org/)
Uso de cluster, GPU, SSD, Infini Band e outras tecnologias
Uso de linguagens de programação adequadas (C/C++, Fortran, etc)
Modelo de programação paralela
Diversas primitivas para processameto paralelo
Suporte de compilador
Diretivas para lock direto no microcódigo
Paralelismo é tradicionamento aplicado em:
Jogos
Simulações
Construção de modelos
Renderização
Segurança (força bruta)
6 | 14/04/2012 |
7. Processamento paralelo no SGBDR
Geralmente processamento paralelo é utilizado na aplicação
No SGBDR utiliza-se um plano de execução para cada instrução SQL
Plano de execução pode conter operadores indicando paralelismo:
Sem recursos para trabalhar com threads no SGBDR. Porém:
SGBDR escala bem pelo número de conexões
Há recursos para tratar problemas de concorrência (locks)
Utiliza linguagem adequada para manipulação de dados
Há como utilizar outras linguagems (C#, Java, Pl/Pg-SQL, etc) no SGBDR
Proposta: fornecer recursos para programação paralela com instruções SQL
Nota: novos recursos do .NET seguem esta linha (Parallel.ForEach)
7 | 14/04/2012 |
8. Paralelisando instruções SQL - Assembly
Assembly .NET escrito por Alan Kaplan:
Artigo “Asynchronous T-SQL Execution Without Service Broker”
em http://migre.me/8EUFc
Cria até 64 conexões no sevidor local
Executa instruções SQL de forma paralela
Aguarda por término de todas elas
Emprega 6 stored procedures, 2 funções e tabelas internas
Permite controle de transação
Obtenção de tempos de execução e erros
Código fonte disponível (projeto em C# no VS.NET).
Demo 1: Instalação do assembly (Listagem1.sql e Deployment.sql)
Demo 2: Inserção de linhas de forma paralela (Listagem2.sql)
Demo 3: Tempo de execução (Listagem3.sql)
8 | 14/04/2012 |
9. Paralelisando instruções SQL - Técnicas
Não substitui as técnicas existentes para tuning de SQL
Para obtenção de desempenho com paralelismo:
Técnica de independência de instruções
Técnica de divisão do domínio
Procurar utilizar o assembly em cenários de muito
processamento (expurgo, fechamento mensal, etc)
Tenha muito cuidado com o controle de concorrência
Evitar colocar paralelismo em consultas „simples‟
Fazer testes para comprovar o ganho de desempenho
9 | 14/04/2012 |
10. Testes de desempenho – cenário
Testes de desempenho de INSERT, DELETE, UPDATE, SELECT
com e sem cache do SQL Server
Cenário:
Intel Core i 950 (4 core @ 3.06 GHZ), 12GB RAM, 64KB Cache L1,
256KB Cache L2, 8MB Cache L3, 1 TB SATA 2 ~ 50 GFLOPS
Windows 2008 Enterprise+SP1 64 Bits (real), SQL Server 2008 R2+SP1
64 Bits
Dados:
Tabela com 11 colunas: 1 int (PK) + 10 float. Valores float aleatórios
Número de linhas (N) variando de 100.000 a 1.000.000
64 Threads dividindo o valor de N igualmente
Um banco de dados com Recovery Model bulk-logged+Transaction log
adequado
Limpeza de cache: DBCC DROPCLEANBUFFERS e DBCC
FREEPROCCACHE
10 | 14/04/2012 |
13. Testes de desempenho – INSERT
Ferramentas para o INSERT:
Comando INSERT
Comando BULK INSERT
Utilitário bcp.exe [MELHOR DESEMPENHO]
Teste:
Importação de N linhas em 64 threads. Cada thread: N/64 linhas
Todos os arquivos na mesma pasta e divididos por tamanho
Transaction log adequado (50% acima do máximo em cada teste)
Para cada N o teste foi realizado 10 vezes
Limpeza do cache a cada teste para cenário sem cache
Medição do tempo de execução com o SET STATISTICS TIME
13 | 14/04/2012 |
14. Testes de desempenho – Resultado INSERT
Melhor cenário: N=700.000 com cache (redução de 92%)
Média do tempo de execução paralelo:
69% mais rápido sem cache
83% mais rápido com cache
S.O. paralelisa I/O da leitura e gravação de dados
14 | 14/04/2012 |
15. Testes de desempenho – DELETE
DELETE apaga linhas passando pelo Transaction Log
Teste didático: para remover todas as linhas use TRUNCATE
TABLE ou DROP TABLE
Uso ou não de lock hints não alteraram resultado
Teste:
Remoção de N linhas em 64 threads. Cada thread: N/64 linhas
TempDB adequado (50% acima do máximo em cada teste)
Transaction log adequado (50% acima do máximo em cada teste)
Para cada N o teste foi realizado 10 vezes
Limpeza do cache a cada teste para cenário sem cache
Medição do tempo de execução com o SET STATISTICS TIME
15 | 14/04/2012 |
16. Testes de desempenho – Resultado DELETE
Melhor cenário: N=500.000 com cache (redução de 99%)
Média do tempo de execução paralelo:
27% mais rápido sem cache
85% mais rápido com cache
Dados não cabem no cache a partir de (N=500.000)
16 | 14/04/2012 |
17. Testes de desempenho – UPDATE
Teste de UPDATE incrementa 1 para cada coluna float
Soma ou subtração geram resultados semelhantes
Uso ou não de lock hints não alteraram resultado
Teste:
Update de N linhas em 64 threads. Cada thread: N/64 linhas
TempDB adequado (50% acima do máximo em cada teste)
Transaction log adequado (50% acima do máximo em cada teste)
Valores float adequados para evitar overflow
Para cada N o teste foi realizado 10 vezes
Limpeza do cache a cada teste para cenário sem cache
Medição do tempo de execução com o SET STATISTICS TIME
17 | 14/04/2012 |
18. Testes de desempenho – Resultado UPDATE
Melhor cenário: N=500.000 com cache (redução de 99%)
Média do tempo de execução paralelo:
70% mais rápido sem cache
63% mais rápido com cache
Novamente, dados não cabem no cache a partir de (N=500.000)
18 | 14/04/2012 |
19. Testes de desempenho – SELECT
Instrução SELECT somou o valor das 10 colunas float
Uso do SUM() sem o group by. Outras aggregações geraram
resultados semelhantes
Uso ou não de lock hints não alteraram resultado
Teste:
Select de N linhas em 64 threads. Cada thread: N/64 linhas
TempDB adequado (50% acima do máximo em cada teste)
Valores float adequados para evitar overflow
Para cada N o teste foi realizado 10 vezes
Limpeza do cache a cada teste para cenário sem cache
Medição do tempo de execução com o SET STATISTICS TIME
19 | 14/04/2012 |
20. Testes de desempenho – Resultado SELECT
Nota: diferença de escala com e sem cache
Melhor cenário: N=400.000 sem cache (redução de 98%)
Média do tempo de execução paralelo:
77% mais rápido sem cache
57% mais rápido com cache
Variações no plano de execução explicam picos/declínios no gráfico
20 | 14/04/2012 |
21. Análise dos resultados
Alguns fatores impactam no resultado: plano de execução,
cache, transaction log e I/O do S.O.
INSERT: 69% mais rápido sem cache e 83% mais rápido com cache
DELETE: 27% mais rápido sem cache e 85% mais rápido com cache
UPDATE: 70% mais rápido sem cache e 63% mais rápido com cache
SELECT: 77% mais rápido sem cache e 57% mais rápido com cache
Supondo melhor cenário no SELECT: 2*10^8 ~ 1 GFLOP
Isso representa apenas 2% da capacidade total do
processador
21 | 14/04/2012 |
22. Conclusões
Era de processadores com múltiplos núcleos
Programação paralela é necessária para obter desempenho
Poucos recursos para paralelismo em SGBDR
Custo do paralelismo requer esforço de programação
Testes com assembly .NET indicam melhora média de:
76% no tempo de execução do INSERT
56% no tempo de execução do DELETE
66,5% no tempo de execução do UPDATE
67% no tempo de execução do SELECT
Há espaço para novas possibilidades e melhorias nos
SGBDR em termos de paralelismo e desempenho
22 | 14/04/2012 |