SlideShare ist ein Scribd-Unternehmen logo
1 von 27
Downloaden Sie, um offline zu lesen
Otimização holística de ambiente
computacional
Bruno Domingues
Principal Architect @ Intel
IEEE Chairman of Computer Society para o Centro-Norte do Brasil
bruno.domingues@intel.com
Introdução
Escher– Unbelievable
A “equação” do planejamento de capacidade
Usuários
Aplicação
Planejamento
de
Capacidade
Infraestrutura
A x I = n x R x U
A = Aplicação
I = Infraestrutura
n = expectativa de sucesso
R = variável aleatória 
U = Usuários
Definição de Complexidade do Problema
Usuário Aplicação Infraestrutura
P
“P”
NP
P=NP?
Goes to???
Ferramentas
• EMON
– Linha de comando, baixo nível para obter contadores do processador e chipset
• SAR
– Ferramenta padrão do Linux
• PowerTop
– Ferramenta padrão do Linux
• Linuxpm
– Ferramenta Intel para obter métricas de potência no nível do Sistema Operacional
Analise do padrão de carga
• Uma semana de monitoramento de CPU
• Utilização media entre 15-35%
• O maior é entre 6hs e 18hs, sendo consumido > 25%
• Toda a noite, por aproximadamente 6hs o consumo cai abaixo de 20%
• A utilização segue um padrão durante os dias de semana e finais de semana
Segue a distribuição
normal (pela Teoria dos
grandes números)
Entendendo o incompreensível usuário
Michelangelo – A aliança entre Deus e os homens
Distribuição de requisição de acessos
Hits por hora Horário
5000 6:00
7000 7:00
11000 8:00
20000 9:00
29000 10:00
38000 11:00
42000 12:00
41000 13:00
38000 14:00
32000 15:00
26000 16:00
20000 17:00
15000 18:00
9000 19:00
5000 20:00
2000 21:00
Total de hits: 340000
x: 170000
média (µ): 21250.000
desvio padrão (α): 14092.551
Normal (y): 1.00000
hits/seg: 59.02778 Equação da curva de Gauss (σ = desvio padrão, µ =
média aritmética)
0
5000
10000
15000
20000
25000
30000
35000
40000
45000
Hits
por
hora
Horário
Carga no web site
Concorrência de acesso
Assumindo que a pior situação haja
42.000 usuários acessando o
sistema em um intervalo de 1h, não
significa que você tenha que lidar
com 11.16 requisições/seg (i.e.
42000/3600)
0.00000000
0.01000000
0.02000000
0.03000000
0.04000000
0.05000000
0.06000000
10
15
20
25
30
35
40
45
50
55
60
65
70
75
80
85
90
95
100
105
PROBABILIDADE
Distribuição de Poisson
A maior probabilidade é que se tenha
que lidar com 60 requisições
simultâneas em intervalos de 0,5 seg.
(i.e. precisão do segundo)
Distribuição de probabilidade de Poisson
QUIZ
• Temos um pico de 35% de utilização de
CPU com ~60 hits simultâneos (42000
usuários no intervalo de 1h)
• Podemos inferir que podemos atender
80.000 sem nenhum problema?
Teoria das Filas
Aplicação do LT (λ=taxa de requisição de Poisson, μ=capacidade de
processamento de requisições, p=λ/μ
Utilização do QPI
Utilização em torno de 10-20%
Distribuição de Leitura/Escrita em memória
Segue a regra de Pareto (similar a maioria do serviços web):
20% escrita e 80% leitura
Leitura Escrita
Acesso a memória Local e Remota
Local Remoto
O que este padrão nos diz a respeito da aplicação que
está rodando em um servidor de dois sockets?
Revisão de NUMA em x86
CPU CPU
Alocação de blocos de
64 bytes em round-robin
NUMA é habilitado por padrão se estiver habilitado na BIOS
Porém pode ser desligado no kernel pela seguinte opção:
kernel /vmlinuz-2.6.18-128.el5 ro root=/dev/VolGroup00/LogVol00 numa=off
Sub-sistema de discos
Desempenho antes x depois da
controladora:
10.000 rpm – 100 / 130 IOPS
15.000 rpm – 160 / 180 IOPS
Configurações
Penalidade do RAID5
1 escrita (host-write) = 2 leituras + 2 escritas
RAID 5 – não é viável em ambientes de alto I/O
Reconstrução (depende do fabricante)
RAID 10 – Ex: 72GB em aprox. 2 horas
RAID 5 – mesmo tempo ou pequena perda (< 20%)
Configuração de Disco
Supondo:
• 1TB de dados
• Discos de 100 GB
• 100 I/O por segundo
RAID # discos Max escritas/seg Max leituas/seg Disponibilidade
RAID-0 10 1000 1000 Baixa
RAID-0+1 20 1000 2000 Muito Alta
RAID-5 11 275 1100 Alta
Capacidade vs. Desempenho
4.800 IOPS, 800 GB de armazenamento
– Por capacidade
• RAID 5 = ~ 16 x 72GB
• RAID 10 = ~ 30 x 72GB
– Por desempenho (2:1 R/W)
• RAID 10
– 3200 reads + (1600 writes * 2) = ~ 6400 IOPS
– Discos de 10k rpm = 6400/130 = ~ 49 = ~ 48 discos
– Discos de 15k rpm = 6400/180 = ~ 35 = ~ 34 discos
• RAID 5
– 3200 reads + (1600 writes * 4) = ~ 9600 IOPS
– Discos de 10k rpm = 9600/130 = ~ 73 discos
– Discos de 15k rpm = 9600/180 = ~ 53 discos
Estudo de Caso – Efeito Cache em Storage
Interaction
Total Elapsed write time for
cycle (sec)
Average writes per
second
Average MB per
second
1 469 341,151398 2,831823
2 460 347,82608 2,887228
3 466 343,347626 2,850054
4 467 342,612427 2,843951
5 467 342,612427 2,843951
6 462 346,320343 2,874279
7 462 346,320343 2,874279
8 456 350,877197 2,912555
9 458 349,344971 2,899836
10 457 350,109406 2,906182
Avg 462,4 346,0522218 2,8724138
Std. Dev 4,647580015 3,478041696 0,028863353
Interaction
Total Elapsed write time for
cycle (sec)
Average writes per
second
Average MB per
second
1 150 1066,666626 8,854166
2 151 1059,602661 7,9553
3 159 1006,289307 8,352987
4 157 1019,108276 8,459395
5 152 1052,631592 8,737665
6 148 1081,081055 8,973817
7 144 1111,111084 9,22309
8 154 1038,96106 8,624188
9 148 1081,081055 8,973817
10 151 1059,602661 7,9553
Avg 151,4 1057,613538 8,6109725
Std. Dev 4,427188724 30,80922367 0,429820883
Teste de
desempenho de
storage usando o
SQLIOSim.exe
30min
depois…
Saturação do
cache devido a
utilização de
RAID 5, derrubou
o desempenho de
I/O
Estudo de Caso – Fator HBA
Queuetarget e Queuedetph
Deve-se procurar valores ótimos para a sua apliação
QUIZ
• Se dobrarmos o número de núcleos de uma
máquina, dobramos a sua capacidade de
processamento?
• Porque?
Estudo de Caso – Web Site (paralelismo)
• Teste de desempenho em três configurações distintas de
servidores com aplicação configurada para medium pooled
usando o ACT para gerar a mesma carga, removendo o fator
latência – índices normalizados
Servidor (antigo)
8 cores
Desempenho: 1
Servidor atual 16
cores
Desempenho: 3.15
Servidor 16 cores
com virtualização
4 VMs (4vCPU por
VM)
Desempenho: 3.30
16 cores com servidor de aplicações
0.0
1.0
2.0
3.0
4.0
5.0
6.0
7.0
8.0
9.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Desempenho
Relativo
Escalabilidade SMP (Servidor Web)
Nesta situação fictícia, 16 núcleos físicos entregam
desempenho relativo de 7,4 cores, com eficiência de 0,46
16 cores virtualizados em 4 VMs
0.0
1.0
2.0
3.0
4.0
5.0
6.0
7.0
8.0
9.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Desempenho
Relativo
Escalabilidade SMP (Servidor Web)
4 núcleos físicos,
representam
desempenho relativo
de 3,2 núcleos e 0,8
de eficiência
Desempenho Relativo
7,4 < 4 x (3,2 x Δ)
4 máquinas virtuais rodando app
server e Δ é o overhead [0 ≤ Δ ≤ 1]
1 máquina física com 16
núcleos rodando app server
Eficiência Computacional
0
50
100
150
200
250
300
350
400
450
500
Pbase Pmax
Consumo
de
Potência
(W)
Potência Proporcional a Computação
5300
5400
5500
5600
E5-2600
Pspread
Patual = P𝑏𝑎𝑠𝑒 + P𝑠𝑝𝑟𝑒𝑎𝑑
Simplificação da relação potência vs. trabalho computacional
Obrigado!

Weitere ähnliche Inhalte

Andere mochten auch

João Galdino - Educando filhos(as) na era da informação
João Galdino - Educando filhos(as) na era da informaçãoJoão Galdino - Educando filhos(as) na era da informação
João Galdino - Educando filhos(as) na era da informaçãoRodrigo Campos
 
Desempenho e Escalabilidade de Banco de Dados em ambiente x86
Desempenho e Escalabilidade de Banco de Dados em ambiente x86Desempenho e Escalabilidade de Banco de Dados em ambiente x86
Desempenho e Escalabilidade de Banco de Dados em ambiente x86Rodrigo Campos
 
Velocity Conference NYC 2014 - Real World DevOps
Velocity Conference NYC 2014 - Real World DevOpsVelocity Conference NYC 2014 - Real World DevOps
Velocity Conference NYC 2014 - Real World DevOpsRodrigo Campos
 
7Masters Webops in the Cloud
7Masters Webops in the Cloud7Masters Webops in the Cloud
7Masters Webops in the CloudRodrigo Campos
 
DevOps no mundo real - QCON 2014
DevOps no mundo real - QCON 2014DevOps no mundo real - QCON 2014
DevOps no mundo real - QCON 2014Rodrigo Campos
 
The Dependency Theory
The Dependency TheoryThe Dependency Theory
The Dependency TheoryTom McLean
 

Andere mochten auch (9)

João Galdino - Educando filhos(as) na era da informação
João Galdino - Educando filhos(as) na era da informaçãoJoão Galdino - Educando filhos(as) na era da informação
João Galdino - Educando filhos(as) na era da informação
 
Desempenho e Escalabilidade de Banco de Dados em ambiente x86
Desempenho e Escalabilidade de Banco de Dados em ambiente x86Desempenho e Escalabilidade de Banco de Dados em ambiente x86
Desempenho e Escalabilidade de Banco de Dados em ambiente x86
 
Large and Giant Pages
Large and Giant PagesLarge and Giant Pages
Large and Giant Pages
 
14 guendert pres
14 guendert pres14 guendert pres
14 guendert pres
 
13 coelho final-pres
13 coelho final-pres13 coelho final-pres
13 coelho final-pres
 
Velocity Conference NYC 2014 - Real World DevOps
Velocity Conference NYC 2014 - Real World DevOpsVelocity Conference NYC 2014 - Real World DevOps
Velocity Conference NYC 2014 - Real World DevOps
 
7Masters Webops in the Cloud
7Masters Webops in the Cloud7Masters Webops in the Cloud
7Masters Webops in the Cloud
 
DevOps no mundo real - QCON 2014
DevOps no mundo real - QCON 2014DevOps no mundo real - QCON 2014
DevOps no mundo real - QCON 2014
 
The Dependency Theory
The Dependency TheoryThe Dependency Theory
The Dependency Theory
 

Ähnlich wie Otimização ambiental computacional

Planejamento de Capacidade - Técnicas e Ferramentas
Planejamento de Capacidade - Técnicas e FerramentasPlanejamento de Capacidade - Técnicas e Ferramentas
Planejamento de Capacidade - Técnicas e FerramentasRodrigo Campos
 
Cloud Server Embratel
Cloud Server EmbratelCloud Server Embratel
Cloud Server EmbratelAlex Hübner
 
What’s new in Amazon Aurora - ADB204 - São Paulo AWS Summit
What’s new in Amazon Aurora - ADB204 - São Paulo AWS SummitWhat’s new in Amazon Aurora - ADB204 - São Paulo AWS Summit
What’s new in Amazon Aurora - ADB204 - São Paulo AWS SummitAmazon Web Services
 
FISL14: Como domar uma fera de 1 TFlop que cabe na palma da sua mão!
FISL14: Como domar uma fera de 1 TFlop que cabe na palma da sua mão!FISL14: Como domar uma fera de 1 TFlop que cabe na palma da sua mão!
FISL14: Como domar uma fera de 1 TFlop que cabe na palma da sua mão!Intel Software Brasil
 
FISL14: Como domar uma fera de 1 TFlop que cabe na palma da sua mão!
FISL14: Como domar uma fera de 1 TFlop que cabe na palma da sua mão!FISL14: Como domar uma fera de 1 TFlop que cabe na palma da sua mão!
FISL14: Como domar uma fera de 1 TFlop que cabe na palma da sua mão!Luciano Palma
 
PostgreSQL Tuning: O elefante mais rápido que um leopardo
PostgreSQL Tuning: O elefante mais rápido que um leopardoPostgreSQL Tuning: O elefante mais rápido que um leopardo
PostgreSQL Tuning: O elefante mais rápido que um leopardoelliando dias
 
Performance Tuning de Clusters Plone - PyConBrasil 2 (2006)
Performance Tuning de Clusters Plone - PyConBrasil 2 (2006)Performance Tuning de Clusters Plone - PyConBrasil 2 (2006)
Performance Tuning de Clusters Plone - PyConBrasil 2 (2006)Fabiano Weimar
 
Amazon EC2 boas praticas e otimizações de desempenho
Amazon EC2 boas praticas e otimizações de desempenhoAmazon EC2 boas praticas e otimizações de desempenho
Amazon EC2 boas praticas e otimizações de desempenhoAmazon Web Services LATAM
 
Explorando o poder do banco de dados com Amazon Aurora
Explorando o poder do banco de dados com Amazon AuroraExplorando o poder do banco de dados com Amazon Aurora
Explorando o poder do banco de dados com Amazon AuroraAmazon Web Services LATAM
 
Raising the bar #2 - Explorando o poder do banco de dados com Amazon Aurora
Raising the bar #2 - Explorando o poder do banco de dados com Amazon AuroraRaising the bar #2 - Explorando o poder do banco de dados com Amazon Aurora
Raising the bar #2 - Explorando o poder do banco de dados com Amazon AuroraAmazon Web Services LATAM
 
Oracle e SQL Server na prática mitos, semelhanças e diferenças
Oracle e SQL Server na prática mitos, semelhanças e diferençasOracle e SQL Server na prática mitos, semelhanças e diferenças
Oracle e SQL Server na prática mitos, semelhanças e diferençasLeonardo Pedroso Costa
 
Planejamento de Capacidade Técnicas e Ferramentas
Planejamento de Capacidade Técnicas e FerramentasPlanejamento de Capacidade Técnicas e Ferramentas
Planejamento de Capacidade Técnicas e Ferramentasluanrjesus
 
Planejamento de capacidade em ambiente virtualizado, por Bruno Domingues
Planejamento de capacidade em ambiente virtualizado, por Bruno DominguesPlanejamento de capacidade em ambiente virtualizado, por Bruno Domingues
Planejamento de capacidade em ambiente virtualizado, por Bruno DominguesJoao Galdino Mello de Souza
 
Escalando para os primeiros 10 milhoes de usuarios
Escalando para os primeiros 10 milhoes de usuariosEscalando para os primeiros 10 milhoes de usuarios
Escalando para os primeiros 10 milhoes de usuariosAmazon Web Services LATAM
 
Cache, Concorrência e Sincronização.
Cache, Concorrência e Sincronização.Cache, Concorrência e Sincronização.
Cache, Concorrência e Sincronização.Thiago Rondon
 
Mais performance com o MySQL 5.6
Mais performance com o MySQL 5.6Mais performance com o MySQL 5.6
Mais performance com o MySQL 5.6MySQL Brasil
 
PostgreSQL Tuning: O elefante mais rápido que um leopardo
PostgreSQL Tuning: O elefante mais rápido que um leopardoPostgreSQL Tuning: O elefante mais rápido que um leopardo
PostgreSQL Tuning: O elefante mais rápido que um leopardoFabio Telles Rodriguez
 

Ähnlich wie Otimização ambiental computacional (20)

Planejamento de Capacidade - Técnicas e Ferramentas
Planejamento de Capacidade - Técnicas e FerramentasPlanejamento de Capacidade - Técnicas e Ferramentas
Planejamento de Capacidade - Técnicas e Ferramentas
 
Cloud Server Embratel
Cloud Server EmbratelCloud Server Embratel
Cloud Server Embratel
 
What’s new in Amazon Aurora - ADB204 - São Paulo AWS Summit
What’s new in Amazon Aurora - ADB204 - São Paulo AWS SummitWhat’s new in Amazon Aurora - ADB204 - São Paulo AWS Summit
What’s new in Amazon Aurora - ADB204 - São Paulo AWS Summit
 
FISL14: Como domar uma fera de 1 TFlop que cabe na palma da sua mão!
FISL14: Como domar uma fera de 1 TFlop que cabe na palma da sua mão!FISL14: Como domar uma fera de 1 TFlop que cabe na palma da sua mão!
FISL14: Como domar uma fera de 1 TFlop que cabe na palma da sua mão!
 
FISL14: Como domar uma fera de 1 TFlop que cabe na palma da sua mão!
FISL14: Como domar uma fera de 1 TFlop que cabe na palma da sua mão!FISL14: Como domar uma fera de 1 TFlop que cabe na palma da sua mão!
FISL14: Como domar uma fera de 1 TFlop que cabe na palma da sua mão!
 
PostgreSQL Tuning: O elefante mais rápido que um leopardo
PostgreSQL Tuning: O elefante mais rápido que um leopardoPostgreSQL Tuning: O elefante mais rápido que um leopardo
PostgreSQL Tuning: O elefante mais rápido que um leopardo
 
Performance Tuning de Clusters Plone - PyConBrasil 2 (2006)
Performance Tuning de Clusters Plone - PyConBrasil 2 (2006)Performance Tuning de Clusters Plone - PyConBrasil 2 (2006)
Performance Tuning de Clusters Plone - PyConBrasil 2 (2006)
 
Amazon EC2 boas praticas e otimizações de desempenho
Amazon EC2 boas praticas e otimizações de desempenhoAmazon EC2 boas praticas e otimizações de desempenho
Amazon EC2 boas praticas e otimizações de desempenho
 
Amazon EC2 avançado
Amazon EC2 avançadoAmazon EC2 avançado
Amazon EC2 avançado
 
Explorando o poder do banco de dados com Amazon Aurora
Explorando o poder do banco de dados com Amazon AuroraExplorando o poder do banco de dados com Amazon Aurora
Explorando o poder do banco de dados com Amazon Aurora
 
Raising the bar #2 - Explorando o poder do banco de dados com Amazon Aurora
Raising the bar #2 - Explorando o poder do banco de dados com Amazon AuroraRaising the bar #2 - Explorando o poder do banco de dados com Amazon Aurora
Raising the bar #2 - Explorando o poder do banco de dados com Amazon Aurora
 
Oracle e SQL Server na prática mitos, semelhanças e diferenças
Oracle e SQL Server na prática mitos, semelhanças e diferençasOracle e SQL Server na prática mitos, semelhanças e diferenças
Oracle e SQL Server na prática mitos, semelhanças e diferenças
 
Planejamento de Capacidade Técnicas e Ferramentas
Planejamento de Capacidade Técnicas e FerramentasPlanejamento de Capacidade Técnicas e Ferramentas
Planejamento de Capacidade Técnicas e Ferramentas
 
Planejamento de capacidade em ambiente virtualizado, por Bruno Domingues
Planejamento de capacidade em ambiente virtualizado, por Bruno DominguesPlanejamento de capacidade em ambiente virtualizado, por Bruno Domingues
Planejamento de capacidade em ambiente virtualizado, por Bruno Domingues
 
Iniciando com Amazon Aurora
Iniciando com Amazon AuroraIniciando com Amazon Aurora
Iniciando com Amazon Aurora
 
Escalando para os primeiros 10 milhoes de usuarios
Escalando para os primeiros 10 milhoes de usuariosEscalando para os primeiros 10 milhoes de usuarios
Escalando para os primeiros 10 milhoes de usuarios
 
Deep dive com Amazon Aurora
Deep dive com Amazon AuroraDeep dive com Amazon Aurora
Deep dive com Amazon Aurora
 
Cache, Concorrência e Sincronização.
Cache, Concorrência e Sincronização.Cache, Concorrência e Sincronização.
Cache, Concorrência e Sincronização.
 
Mais performance com o MySQL 5.6
Mais performance com o MySQL 5.6Mais performance com o MySQL 5.6
Mais performance com o MySQL 5.6
 
PostgreSQL Tuning: O elefante mais rápido que um leopardo
PostgreSQL Tuning: O elefante mais rápido que um leopardoPostgreSQL Tuning: O elefante mais rápido que um leopardo
PostgreSQL Tuning: O elefante mais rápido que um leopardo
 

Mehr von Rodrigo Campos

Mistério ou tecnologia? Paralelismo!
Mistério ou tecnologia? Paralelismo!Mistério ou tecnologia? Paralelismo!
Mistério ou tecnologia? Paralelismo!Rodrigo Campos
 
z/VM Performance Analysis
z/VM Performance Analysisz/VM Performance Analysis
z/VM Performance AnalysisRodrigo Campos
 
Sistemas de proteção de perímetro
Sistemas de proteção de perímetroSistemas de proteção de perímetro
Sistemas de proteção de perímetroRodrigo Campos
 
Devops at Walmart GeC Brazil
Devops at Walmart GeC BrazilDevops at Walmart GeC Brazil
Devops at Walmart GeC BrazilRodrigo Campos
 
Disk IO Benchmarking in shared multi-tenant environments
Disk IO Benchmarking in shared multi-tenant environmentsDisk IO Benchmarking in shared multi-tenant environments
Disk IO Benchmarking in shared multi-tenant environmentsRodrigo Campos
 
Cloud Computing Oportunidades e Desafios
Cloud Computing Oportunidades e DesafiosCloud Computing Oportunidades e Desafios
Cloud Computing Oportunidades e DesafiosRodrigo Campos
 
The good, the bad and the big... data
The good, the bad and the big... dataThe good, the bad and the big... data
The good, the bad and the big... dataRodrigo Campos
 
CMG 2012 - Tuning where it matters - Gerry Tuddenham
CMG 2012 - Tuning where it matters - Gerry TuddenhamCMG 2012 - Tuning where it matters - Gerry Tuddenham
CMG 2012 - Tuning where it matters - Gerry TuddenhamRodrigo Campos
 
A Consumerização da TI e o Efeito BYOT
A Consumerização da TI e o Efeito BYOTA Consumerização da TI e o Efeito BYOT
A Consumerização da TI e o Efeito BYOTRodrigo Campos
 
CMG Brasil 2012 - Uso de Lines nos z196
CMG Brasil 2012 - Uso de Lines nos z196CMG Brasil 2012 - Uso de Lines nos z196
CMG Brasil 2012 - Uso de Lines nos z196Rodrigo Campos
 
Racionalização e Otimização de Energia em Computação na Nuvem
Racionalização e Otimização de Energia em Computação na NuvemRacionalização e Otimização de Energia em Computação na Nuvem
Racionalização e Otimização de Energia em Computação na NuvemRodrigo Campos
 
SDN - Openflow + OpenVSwitch + Quantum
SDN - Openflow + OpenVSwitch + QuantumSDN - Openflow + OpenVSwitch + Quantum
SDN - Openflow + OpenVSwitch + QuantumRodrigo Campos
 
AWS RDS Benchmark - CMG Brasil 2012
AWS RDS Benchmark - CMG Brasil 2012AWS RDS Benchmark - CMG Brasil 2012
AWS RDS Benchmark - CMG Brasil 2012Rodrigo Campos
 
Isolamento de Recursos na Nuvem
Isolamento de Recursos na NuvemIsolamento de Recursos na Nuvem
Isolamento de Recursos na NuvemRodrigo Campos
 
Cloud Computing at Academia UOL
Cloud Computing at Academia UOLCloud Computing at Academia UOL
Cloud Computing at Academia UOLRodrigo Campos
 
Capacity Planning for Linux Systems
Capacity Planning for Linux SystemsCapacity Planning for Linux Systems
Capacity Planning for Linux SystemsRodrigo Campos
 
Performance Oriented Design
Performance Oriented DesignPerformance Oriented Design
Performance Oriented DesignRodrigo Campos
 
Adam Grummitt - Capacity Management: Guided Practitioner Satnav
Adam Grummitt - Capacity Management: Guided Practitioner SatnavAdam Grummitt - Capacity Management: Guided Practitioner Satnav
Adam Grummitt - Capacity Management: Guided Practitioner SatnavRodrigo Campos
 
Planejamento de Capacidade com ferramentas gratuitas
Planejamento de Capacidade com ferramentas gratuitasPlanejamento de Capacidade com ferramentas gratuitas
Planejamento de Capacidade com ferramentas gratuitasRodrigo Campos
 
Capacity Planning for fun & profit
Capacity Planning for fun & profitCapacity Planning for fun & profit
Capacity Planning for fun & profitRodrigo Campos
 

Mehr von Rodrigo Campos (20)

Mistério ou tecnologia? Paralelismo!
Mistério ou tecnologia? Paralelismo!Mistério ou tecnologia? Paralelismo!
Mistério ou tecnologia? Paralelismo!
 
z/VM Performance Analysis
z/VM Performance Analysisz/VM Performance Analysis
z/VM Performance Analysis
 
Sistemas de proteção de perímetro
Sistemas de proteção de perímetroSistemas de proteção de perímetro
Sistemas de proteção de perímetro
 
Devops at Walmart GeC Brazil
Devops at Walmart GeC BrazilDevops at Walmart GeC Brazil
Devops at Walmart GeC Brazil
 
Disk IO Benchmarking in shared multi-tenant environments
Disk IO Benchmarking in shared multi-tenant environmentsDisk IO Benchmarking in shared multi-tenant environments
Disk IO Benchmarking in shared multi-tenant environments
 
Cloud Computing Oportunidades e Desafios
Cloud Computing Oportunidades e DesafiosCloud Computing Oportunidades e Desafios
Cloud Computing Oportunidades e Desafios
 
The good, the bad and the big... data
The good, the bad and the big... dataThe good, the bad and the big... data
The good, the bad and the big... data
 
CMG 2012 - Tuning where it matters - Gerry Tuddenham
CMG 2012 - Tuning where it matters - Gerry TuddenhamCMG 2012 - Tuning where it matters - Gerry Tuddenham
CMG 2012 - Tuning where it matters - Gerry Tuddenham
 
A Consumerização da TI e o Efeito BYOT
A Consumerização da TI e o Efeito BYOTA Consumerização da TI e o Efeito BYOT
A Consumerização da TI e o Efeito BYOT
 
CMG Brasil 2012 - Uso de Lines nos z196
CMG Brasil 2012 - Uso de Lines nos z196CMG Brasil 2012 - Uso de Lines nos z196
CMG Brasil 2012 - Uso de Lines nos z196
 
Racionalização e Otimização de Energia em Computação na Nuvem
Racionalização e Otimização de Energia em Computação na NuvemRacionalização e Otimização de Energia em Computação na Nuvem
Racionalização e Otimização de Energia em Computação na Nuvem
 
SDN - Openflow + OpenVSwitch + Quantum
SDN - Openflow + OpenVSwitch + QuantumSDN - Openflow + OpenVSwitch + Quantum
SDN - Openflow + OpenVSwitch + Quantum
 
AWS RDS Benchmark - CMG Brasil 2012
AWS RDS Benchmark - CMG Brasil 2012AWS RDS Benchmark - CMG Brasil 2012
AWS RDS Benchmark - CMG Brasil 2012
 
Isolamento de Recursos na Nuvem
Isolamento de Recursos na NuvemIsolamento de Recursos na Nuvem
Isolamento de Recursos na Nuvem
 
Cloud Computing at Academia UOL
Cloud Computing at Academia UOLCloud Computing at Academia UOL
Cloud Computing at Academia UOL
 
Capacity Planning for Linux Systems
Capacity Planning for Linux SystemsCapacity Planning for Linux Systems
Capacity Planning for Linux Systems
 
Performance Oriented Design
Performance Oriented DesignPerformance Oriented Design
Performance Oriented Design
 
Adam Grummitt - Capacity Management: Guided Practitioner Satnav
Adam Grummitt - Capacity Management: Guided Practitioner SatnavAdam Grummitt - Capacity Management: Guided Practitioner Satnav
Adam Grummitt - Capacity Management: Guided Practitioner Satnav
 
Planejamento de Capacidade com ferramentas gratuitas
Planejamento de Capacidade com ferramentas gratuitasPlanejamento de Capacidade com ferramentas gratuitas
Planejamento de Capacidade com ferramentas gratuitas
 
Capacity Planning for fun & profit
Capacity Planning for fun & profitCapacity Planning for fun & profit
Capacity Planning for fun & profit
 

Otimização ambiental computacional

  • 1. Otimização holística de ambiente computacional Bruno Domingues Principal Architect @ Intel IEEE Chairman of Computer Society para o Centro-Norte do Brasil bruno.domingues@intel.com
  • 3. A “equação” do planejamento de capacidade Usuários Aplicação Planejamento de Capacidade Infraestrutura A x I = n x R x U A = Aplicação I = Infraestrutura n = expectativa de sucesso R = variável aleatória  U = Usuários
  • 4. Definição de Complexidade do Problema Usuário Aplicação Infraestrutura P “P” NP P=NP?
  • 6. Ferramentas • EMON – Linha de comando, baixo nível para obter contadores do processador e chipset • SAR – Ferramenta padrão do Linux • PowerTop – Ferramenta padrão do Linux • Linuxpm – Ferramenta Intel para obter métricas de potência no nível do Sistema Operacional
  • 7. Analise do padrão de carga • Uma semana de monitoramento de CPU • Utilização media entre 15-35% • O maior é entre 6hs e 18hs, sendo consumido > 25% • Toda a noite, por aproximadamente 6hs o consumo cai abaixo de 20% • A utilização segue um padrão durante os dias de semana e finais de semana Segue a distribuição normal (pela Teoria dos grandes números)
  • 8. Entendendo o incompreensível usuário Michelangelo – A aliança entre Deus e os homens
  • 9. Distribuição de requisição de acessos Hits por hora Horário 5000 6:00 7000 7:00 11000 8:00 20000 9:00 29000 10:00 38000 11:00 42000 12:00 41000 13:00 38000 14:00 32000 15:00 26000 16:00 20000 17:00 15000 18:00 9000 19:00 5000 20:00 2000 21:00 Total de hits: 340000 x: 170000 média (µ): 21250.000 desvio padrão (α): 14092.551 Normal (y): 1.00000 hits/seg: 59.02778 Equação da curva de Gauss (σ = desvio padrão, µ = média aritmética) 0 5000 10000 15000 20000 25000 30000 35000 40000 45000 Hits por hora Horário Carga no web site
  • 10. Concorrência de acesso Assumindo que a pior situação haja 42.000 usuários acessando o sistema em um intervalo de 1h, não significa que você tenha que lidar com 11.16 requisições/seg (i.e. 42000/3600) 0.00000000 0.01000000 0.02000000 0.03000000 0.04000000 0.05000000 0.06000000 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 105 PROBABILIDADE Distribuição de Poisson A maior probabilidade é que se tenha que lidar com 60 requisições simultâneas em intervalos de 0,5 seg. (i.e. precisão do segundo) Distribuição de probabilidade de Poisson
  • 11. QUIZ • Temos um pico de 35% de utilização de CPU com ~60 hits simultâneos (42000 usuários no intervalo de 1h) • Podemos inferir que podemos atender 80.000 sem nenhum problema?
  • 12. Teoria das Filas Aplicação do LT (λ=taxa de requisição de Poisson, μ=capacidade de processamento de requisições, p=λ/μ
  • 13. Utilização do QPI Utilização em torno de 10-20%
  • 14. Distribuição de Leitura/Escrita em memória Segue a regra de Pareto (similar a maioria do serviços web): 20% escrita e 80% leitura Leitura Escrita
  • 15. Acesso a memória Local e Remota Local Remoto O que este padrão nos diz a respeito da aplicação que está rodando em um servidor de dois sockets?
  • 16. Revisão de NUMA em x86 CPU CPU Alocação de blocos de 64 bytes em round-robin NUMA é habilitado por padrão se estiver habilitado na BIOS Porém pode ser desligado no kernel pela seguinte opção: kernel /vmlinuz-2.6.18-128.el5 ro root=/dev/VolGroup00/LogVol00 numa=off
  • 17. Sub-sistema de discos Desempenho antes x depois da controladora: 10.000 rpm – 100 / 130 IOPS 15.000 rpm – 160 / 180 IOPS Configurações Penalidade do RAID5 1 escrita (host-write) = 2 leituras + 2 escritas RAID 5 – não é viável em ambientes de alto I/O Reconstrução (depende do fabricante) RAID 10 – Ex: 72GB em aprox. 2 horas RAID 5 – mesmo tempo ou pequena perda (< 20%)
  • 18. Configuração de Disco Supondo: • 1TB de dados • Discos de 100 GB • 100 I/O por segundo RAID # discos Max escritas/seg Max leituas/seg Disponibilidade RAID-0 10 1000 1000 Baixa RAID-0+1 20 1000 2000 Muito Alta RAID-5 11 275 1100 Alta
  • 19. Capacidade vs. Desempenho 4.800 IOPS, 800 GB de armazenamento – Por capacidade • RAID 5 = ~ 16 x 72GB • RAID 10 = ~ 30 x 72GB – Por desempenho (2:1 R/W) • RAID 10 – 3200 reads + (1600 writes * 2) = ~ 6400 IOPS – Discos de 10k rpm = 6400/130 = ~ 49 = ~ 48 discos – Discos de 15k rpm = 6400/180 = ~ 35 = ~ 34 discos • RAID 5 – 3200 reads + (1600 writes * 4) = ~ 9600 IOPS – Discos de 10k rpm = 9600/130 = ~ 73 discos – Discos de 15k rpm = 9600/180 = ~ 53 discos
  • 20. Estudo de Caso – Efeito Cache em Storage Interaction Total Elapsed write time for cycle (sec) Average writes per second Average MB per second 1 469 341,151398 2,831823 2 460 347,82608 2,887228 3 466 343,347626 2,850054 4 467 342,612427 2,843951 5 467 342,612427 2,843951 6 462 346,320343 2,874279 7 462 346,320343 2,874279 8 456 350,877197 2,912555 9 458 349,344971 2,899836 10 457 350,109406 2,906182 Avg 462,4 346,0522218 2,8724138 Std. Dev 4,647580015 3,478041696 0,028863353 Interaction Total Elapsed write time for cycle (sec) Average writes per second Average MB per second 1 150 1066,666626 8,854166 2 151 1059,602661 7,9553 3 159 1006,289307 8,352987 4 157 1019,108276 8,459395 5 152 1052,631592 8,737665 6 148 1081,081055 8,973817 7 144 1111,111084 9,22309 8 154 1038,96106 8,624188 9 148 1081,081055 8,973817 10 151 1059,602661 7,9553 Avg 151,4 1057,613538 8,6109725 Std. Dev 4,427188724 30,80922367 0,429820883 Teste de desempenho de storage usando o SQLIOSim.exe 30min depois… Saturação do cache devido a utilização de RAID 5, derrubou o desempenho de I/O
  • 21. Estudo de Caso – Fator HBA Queuetarget e Queuedetph Deve-se procurar valores ótimos para a sua apliação
  • 22. QUIZ • Se dobrarmos o número de núcleos de uma máquina, dobramos a sua capacidade de processamento? • Porque?
  • 23. Estudo de Caso – Web Site (paralelismo) • Teste de desempenho em três configurações distintas de servidores com aplicação configurada para medium pooled usando o ACT para gerar a mesma carga, removendo o fator latência – índices normalizados Servidor (antigo) 8 cores Desempenho: 1 Servidor atual 16 cores Desempenho: 3.15 Servidor 16 cores com virtualização 4 VMs (4vCPU por VM) Desempenho: 3.30
  • 24. 16 cores com servidor de aplicações 0.0 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Desempenho Relativo Escalabilidade SMP (Servidor Web) Nesta situação fictícia, 16 núcleos físicos entregam desempenho relativo de 7,4 cores, com eficiência de 0,46
  • 25. 16 cores virtualizados em 4 VMs 0.0 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Desempenho Relativo Escalabilidade SMP (Servidor Web) 4 núcleos físicos, representam desempenho relativo de 3,2 núcleos e 0,8 de eficiência Desempenho Relativo 7,4 < 4 x (3,2 x Δ) 4 máquinas virtuais rodando app server e Δ é o overhead [0 ≤ Δ ≤ 1] 1 máquina física com 16 núcleos rodando app server
  • 26. Eficiência Computacional 0 50 100 150 200 250 300 350 400 450 500 Pbase Pmax Consumo de Potência (W) Potência Proporcional a Computação 5300 5400 5500 5600 E5-2600 Pspread Patual = P𝑏𝑎𝑠𝑒 + P𝑠𝑝𝑟𝑒𝑎𝑑 Simplificação da relação potência vs. trabalho computacional