Performance tuning

Red Hat Enterprise Linux

Performance Tuning

Rodrigo Missiaggia
Platform Technical Leader
Red Hat Brasil
rmissiaggia@redhat.com
@rmissiaggia

Agenda
●
Introdução
●
O que é Performance Tuning?
●
Só se pode “Tunar” o que se pode medir
●
Teoria das Filas.
●
Interdependência de componentes.
●
Componentes “Tunáveis”
●
Colhendo informações e acionando o suporte o
suporte.

Objetivo do “Performance Tuning”
●
Atingir o comportamento desejado;
●
Neste caso é necessário definir o que é desejado...

●
●

●
Compensar características físicas do Hardware
balanceando:
●
Menor tempo de resposta vs Alto Thoughput;
●
Performance percebida vs Eficiência no uso de recursos;
●
Redistribuir o Workload durante diferentes períodos do dia;

●
●

●
balanceando:
●
●
●

●
Encontrar e minimizar Gargalos;
●
Eventualmente restringindo recursos de certas aplicações;

●
●

●
balanceando:
●
●
●

●
Encontrar e minimizar Gargalos;
●
Eventualmente restringindo recursos de certas aplicações;

Ajustar o sistema ao fator humano;
●

●
O que é lento, o que é rápido?

Só se pode “tunar” o que se pode medir
●
É necessário medir o desempenho e tempo de
resposta;
●
Bandwidth (fixa) vs Throughput (dados úteis)

●
Ter informações confiáveis sobre o comportamento
de cada componente;
●
Preferencialmente os “Workloads” devem ser
reproduzíveis para medir as melhorias realizadas;

Ferramentas para Medir a Performance
CPU Tools
1 – top
2 – vmstat
3 – ps aux
4 – mpstat -P all
5 – sar -u
6 – iostat
7 – oprofile
8–
gnomesystem-
CPU
CPU monitor
9 – KDE-monitor
10 – /proc
11 - perf

Disk Tools
1 – iostat -x
2 – vmstat -
D
3 – sar -DEV
#
4 – nfsstat
5 - dstat
Storage
Storage
/Disco
/Disco


Memória
Memória
Memory Tools
1 – top
2 – vmstat -s
3 – ps aur
4 – ipcs
5 – sar -r -B -W
6 – free
7 – oprofile
8–
gnomesystem-
monitor
9 – KDE-monitor
10 – /proc


Process
Tools
1 – top
2 – ps -o
pmem
3 – gprof Processos
Processos
4–
strace,ltrace
5 – sar


Network Tools
1 – tcpdump
2 – wireshark
3 – netstat
4 – iptraf
5 – dstat
6 – ethtool
...

Rede
Rede


Memória
Memória

Storage
Storage Processos
Processos
CPU
CPU
/Disco
/Disco

Conjunto
1 – dstat
Rede
Rede 2 – sar
3 – oprofile
4 – ...

Teoria das Filas
Lei de Little

Desenvolvida por John Little no início dos anos
60. A Lei de Little relaciona o número de
clientes no sistema com o tempo médio
despendido no sistema por cada um deles.

Teoria das Filas
Utilização = Número de requisições * Tempo de Serviço

Exemplo: saída do iostat -x sda 5
Device: rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrqsz avgqusz   await  svctm  %util

Sda       0,00  5293,60    0,00   76,00     0,00 65598,40   863,14    54,58  905,83   7,12  54,10

Utilização = (0.00 + 76.00) * 7.12 ms / 1000 ms   = 54,10%

Teoria das Filas
Número Máximo de Novas transações = 1 / Tempo de Serviço

Exemplo:
Utiliza-se o Tempo de Serviço quando a Utilização
esta a 100%.
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrqsz avgqusz await svctm %util

sda 0,00 21958,40 0,00 165,20 0,00 169164,80 1024,00 129,63 711,42 6,05 100,00

Número Máximo de Novas transações = 1 segundo / 6.05 ms =
165.28 IOs
Qualquer volume maior que este de novas requisições tende a
gerar filas de espera crescentes!

Teoria das Filas

Usuário diz: “O SISTEMA ESTA LENTO!!!!”
Leis de Little (e limites físicos também)

Utilização = Número de requisições * Tempo de Serviço

Ou diminuímos (“tunamos”) o Tempo de Serviço ( = Execução + espera” )
ou redistribuímos a carga.

Teoria das Filas
Teoria das filas e a Lei de Little afetam todas as
aplicações e Subsistemas Participantes.
– Escrita em disco envolve RAM, CPU, spindle, BUS,
controladoras e sistema de arquivos.

O mais eficiente é pensarmos em camadas;
– Infra-estrutura, Hardware, SO, Aplicação, Negócios

E então se deve criar um modelo para cada camada:
– Estabelecer um máximo “teórico” vs “medido”
– Incongruências podem indicar problemas...

Exemplo de Modelo de Aplicação

Storage / Disco IO
O Disco é, normalmente, um equipamento com
peças móveis e esta sujeito, a maiores latências e
limitações de crescimentos.
Cálculo de IOPs de um disco rígido:
Model: XXX SAS

Rotational speed: 10,000 RPM

Average latency: 4 ms (0.004 seconds)

Average seek time: 4.2 (r)/4.7 (w) = 4.45 ms (0.0045 seconds)

Número de IOPs calculado para este disco: 1/(0.004 + 0.0045) = ~ 117 IOPS

Storage / Disco IO
Como melhorar a performance de um “Disco”?
Podemos redistribuir a carga ou trocá-los..
Método comum, criação de RAID:

Impacto do
uso de RAID
no I/o
Níveo de Read Write
RAID
0 1 1
1 ou 10 1 2
5 1 4
6 1 6

Storage / Disco IO
Caso: Necessito de 1000 IOPs por segundo para a
aplicação X. Sendo 50% leitura e 50% escrita.
Quantos discos preciso para cada nível de RAID?

Nível de RAID Write (TOTAL IOps × % READ)+ ((TOTAL IOps × % WRITE)
×RAID Penalty)

0 1 ((1000 * 0.5) + (1000 *0.5) * 1) = 1000 1000 / 150 = 7
IOPS discos
1 ou 10 2 ((1000 * 0.5) + (1000 *0.5) * 2) = 1500 1500 / 150 = 10
IOPS discos
5 4 ((1000 * 0.5) + (1000 *0.5) * 4) = 2500 2500 / 150 = 17
IOPS discos
6 6 ((1000 * 0.5) + (1000 *0.5) * 6) = 3500 3500 / 150 = 24
IOPS discos
(900 * 50%) + (900 * 50% / 2) = 450 + 225 = 675

Alguns dados: http://www.techrepublic.com/blog/datacenter/calculate-iops-in-a-storage-array/2182

Storage / Disco IO
Interface de Interconexão
●

●
SATA até 300MiB/s
●
SCSI até 320MiB/s
●
Fibre Channel até 256MiB/s (4Gib/s)
●
Fibre Channel até 512MiB/s (8Gib/s)

Storage / Disco IO
●
Interface de Interconexão;
●
Tamanho, distribuição e alinhamento de Disco;
●
Nível de RAID;
●
Formatação correta em relação ao blocos físicos do
disco:
Para ler 4KB é
Alinhado 4K 4K 4K 4K 4K 4K necessário ler 4KB

4K 4K 4K 4K 4K 4K 4K 4K 4K 4K

Para ler 4KB é
Desalinhado 4K 4K 4K 4K 4K 4K necessário ler 8KB

4K 4K 4K 4K 4K 4K 4K 4K 4K 4K

Storage / Disco IO
●

●

Parametrização dos discos;
●

Scheduler de Disco;
●

●
CFQ -. Divide o IO igualmente por processo
●
Deadline – Otimiza os tempos de leitura e escrita das filas. Requisições devem
ser atendidas quando o tempo de expiração é atingido
●
NOOP – Filas do tipo FIFO

Storage / Disco IO

Escolha correta de Filesystem;
●

Tipos, tamanho e localização de Journal;
●

Opções de montagem de Filesystem;
●

●
Ext3 = Mais maduro;
●
Ext4 = Melhor performance na maioria dos casos em
relação ao Ext3;
●
XFS = Melhor para grandes arquivos, tem problemas
com pequenos;
●
GFS/GFS2 = Sistema de arquivos para Cluster.
Melhor para grandes arquivos;
●
NFSv2,3,4 = Multi-plataforma, via rede, necessita um
filesystem para oferecer os arquivos;

Storage / Disco IO
●

●

Parametrização dos discos;
●

Scheduler de Disco;
●

Escolha correta de Filesystem;
●

Tipos, tamanho e localização de Journal;
●

Opções de montagem de Filesystem;
●

Fragmentação;
●

Tuning de Buffer e Caches
●

Memória
O gerenciamento de memória é extremamente
parametrizável. Permitindo ajustar o
comportamento para condições muito particulares
de uso.

Memória
Quanta memória temos disponível?
free
             total       used       free     shared    buffers     cached

Mem:       8086612    5222256    2864356          0     185616    2388244

/+ buffers/cache:    2648396    5438216

Swap:     10190840     100224   10090616

Memória e áreas de “Defesa”

●
Quanto devo manter de memória livre?
# cat /proc/sys/vm/min_free_kbytes
67584

Definido em Kbytes, procura definir uma marca
d'água de quanta memória RAM deve ser mantida
livre. A partir dai busca encontrar memória de
maneira agressiva.

Memória vs Swap

●
A memória RAM tende a ser 40000 vezes mais
rápida que o SWAP (ms vs ns);
●
Para melhor performance crie partições de SWAP
distribuídos em vários discos, preferencialmente no
início do disco, e com prioridades idênticas
(quando os discos tiverem a mesma performance;
●
O VM (Virtual Memory) pode ser parametrizada
para utilizar SWAP com + ou – agressividade por
default o sistema vem configurado para “uso geral”;

Memória vs Swap

●
Quem controla o SWAP?
# cat /proc/sys/vm/swappiness
60
Quanto mais perto de 100 maior é a predisposição
a usar SWAP, quanto mais perto de 0 menor é a
predisposição.
swap_tendency = mapped_ratio/2 + distress + vm_swappiness

Memória vs Swap

Quanto mais perto de 100 maior é a predisposição
●

a usar SWAP, quanto mais perto de 0 menor é a
predisposição.
swap_tendency = mapped_ratio/2 + distress + vm_swappiness

Se “swap_tendency > 100” então
“Tente reclamar página des memória inativas e utilize swap
se necessário...”

Senão
“Libere páginas de cache/buffer...”

Memória vs Swap

swap_tendency = mapped_ratio/2 + distress +
vm_swappiness
Mapped_ratio = quantos % da memória alocados?
This is a measure of the percentage of total system memory that is taken up with mapped pages. It is computed
as (numbermappedpages)/(totalpages) * 100

distress = O quão difícil é recuperar memória em
cache?
This is a measurement of how much difficulty the VM is having reclaiming pages. Each time the VM tries to
reclaim memory, it scans 1/nth of the inactive lists in each zone in an effort to reclaim pages. Each time a
pass over the list is made, if the number of inactive clean + free pages in that zone is not over the low water
mark, n is decreased by one. Distress is measured as 100 >> n

Swappiness = “O fator humano”

Memória vs Swap
swap_tendency = mapped_ratio/2 + distress +
vm_swappiness
Conta de padeiro:
Minha máquina tem 64GB de RAM e estou alocando
48GB. Está fácil recuperar memória de cache
(distress = 0) e swappiness = 60
swap_tendency = 48/64*100/2 + 0 + 60
swap_tendency = 37.5 + 0 + 60 = 97.5
97.5 < 100 então prefiro não usar swap...

Memória vs Cache

Como influenciar a alocação do cache:
●

# cat /proc/sys/vm/dirty_ratio
40
dirty_ratio = indica que quando o sistema tiver mais do que 40% da memória alocada para dados que devem
ser escritos em disco (páginas “sujas”), qualquer processo que faça uma nova escrita em disco vai esperar
que o sistema termine de escrever as páginas pendentes.

# cat /proc/sys/vm/dirty_background_ratio
10
dirty_background_ratio = 10 faz com que o sistema comece a escrever em segundo plano as páginas “sujas”
assim que estas passem de 10% da memória. Desta forma se obtém mais rapidamente memória que pode
ser realocada para outros processos ou liberada.

Memória vs Cache

●

# cat /proc/sys/vm/dirty_expire_centisecs
2999
dirty_expire_centisecs = indica quantos centésimos de segundo uma informação poderá ficar em cache sem ser
persistida em disco. 2999 = 29,99 segundos.

# cat /proc/sys/vm/dirty_writeback_centisecs
499
dirty_writeback_centisecs = indica a cada quantos centésimos de segundo os daemons de pdflush “acordam”
para analisar páginas não escritas em disco com idade maior que “distry_expire_centisecs”.

Memória vs Cache

●

# cat /proc/sys/vm/vfs_cache_pressure
100
vfs_cache_pressure = faz com que o sistema também libere memória alocada para informações de inodes e
directory entries quando precisar liberar memória. Valores maiores que 100 liberam memória mais
facilmente...

Memória

●
Também podem ser ajustados, tamanhos de
caches diversos do sistema para resoluções de
tabela ARP, número de conexões de rede
suportadas, slabcache (cache de inodes, entradas de diretório, …)
Pergunta: Quanta memória eu preciso ter no meu servidor para garantir
que, com o Workload atual, eu terei 99,999% de chance de não
exaurir a memória?

Memória

●
Também podem ser ajustados, tamanhos de
caches diversos do sistema para resoluções de
tabela ARP, número de conexões de rede
suportadas, slabcache (cache de inodes, entradas de diretório, …)
Pergunta: Quanta memória eu preciso ter no meu servidor para garantir
que, com o Workload atual, eu terei 99,999% de chance de não
exaurir a memória?
Resposta:
# cat /proc/meminfo | grep Comm

CommitLimit: 14234144 kB

Committed_AS: 3547652 kB

Memória
Melhore a performance da memória e o TLB
utilizando Hugepages sempre que possível.

CPU
●
Ajustar o Scheduler de CPU para perfomance ou
on-demand;
●
Utilizar o comando “taskset” para “pinar” um
processo/tarefa a um conjunto de CPUs
●
Isolar CPUs do sistema indicando quais podem ser
usadas para tarefas do SO e quais serão
reservadas para aplicações;
●
Habilitar a IRQ affinity, fazendo com que as IRQs
seja processadas num conjunto de CPUs e
aproveita consistência de cache;

Rede
Estratégias para melhorar a performance;
●

Evitar autonegociação de rede;
●

Utilizar técnicas de bonding – agregação de link;
●

Ajustar tamanhos de buffer de envio e recebimento
●

de rede baseados na latência da rede.

Ajuste fino de recursos
Gerenciamento de recursos

Possibilidade de priorizar recursos entre diferentes usuários e processos via Control Groups
(Cgroups).


Benefício: Garantir Qualidade de Serviço

Cgroups Pode ser usado para controlar:

cpu

memória

rede

Ajuste fino de recursos
Permite a realocação de
14 recursos entre processos
CPUS
8 ou máquinas virtuais
Sem restrição CPUS “a quente” sem paradas!
de recursos.
Ou 32 cores de CPU.

4
CPUS

2
CPUS

Colhendo informações
Sempre que abrir um chamado de suporte, adicione
informações extras para oferecer subsídios para o
pessoal de Suporte.
Rode o comando:
#sosreport
Anexe o resultado no chamado de suporte.

https://access.redhat.com/support/offerings/production/sla.html

Agilizando a resolução de
problemas com o ABRT*

* Automatic bug detection and reporting tool

Encurtando Caminhos com o ABRT

Seleciona-se o “travamento”
da aplicação no qual
se deseja abrir um Ticket
de suporte.


Seleciona-se RHTSupport
para abrir um chamado na sua
conta do RHN.


Após análise das informações
autorize o uso dos dados para
análise.


Adicione informações, se possível,
das maneiras de reproduzir
o problema.


Verifique as informações e
aprove, ou não, a abertura
do chamado..

O chamado será aberto
automaticamente e os
dados do backtrace serão
anexados ao chamado.
O link para o chamado será
disponibilizado a seguir e você
receberá dados a respeito dele
no seu email.

Você pode editar os dados do
chamado, alterar prioridades etc.

Ciclo de Suporte
O suporte por até 10 anos per o planejamento adequado
da migração de sistemas legados e preserva investimentos.

https://access.redhat.com/support/policy/updates/errata/

Escalabilidade e limites suportados

http://www.redhat.com/rhel/compare/

Escalabilidade e limites suportados
(sob virtualização)

http://www.redhat.com/rhel/compare/

Ecossistema de Software

http://www.redhat.com/rhel/compatibility/software/

Ecossistema de Hardware

https://hardware.redhat.com/

Milhares de combinações
de Hardware suportadas

Performance tuning

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (14)

Semelhante a Performance tuning

Semelhante a Performance tuning (20)

Mais de Rodrigo Missiaggia

Mais de Rodrigo Missiaggia (7)

Performance tuning