Ajuste de desempenho do Oracle na Solução Bare Metal
Objetivo
Neste documento, fornecemos diretrizes sobre como abordar problemas relacionados ao desempenho usando o Oracle na Solução Bare Metal.
Etapa 1: coletar dados de diagnóstico
Entenda o problema da forma mais detalhada possível. Colete o máximo de informações possível, incluindo:
- Informações do ambiente do banco de dados - ID/IP da máquina, local do data center, detalhes do ambiente Oracle etc.
- A descrição do problema inclui a linha do tempo.
- Extensão do impacto: por exemplo, o problema está afetando apenas uma única sessão ou servidor, um conjunto de sessões e servidores relacionados ou todos os usuários do banco de dados?
- Descreva a investigação realizada até agora. Há alguma solução alternativa em vigor?
- O problema pode ser reproduzido à vontade? Caso afirmativo, como?
- Existe algum bom valor de referência para comparar?
- Houve mudanças recentes nas configurações nas camadas do banco de dados, host, rede, armazenamento ou aplicativo, incluindo alterações na carga de trabalho?
- Coletar todos os registros e traces relevantes, incluindo ASH, AWR, registros de alerta, arquivos de rastreamento e registros de inspeção TFA/OS.
# TFA command to generate a bundled package containing files like
# the AWR report, ADDM report, ASH report, OSWatcher and ORAchk performance
# related checks.
tfactl diagcollect -srdc dbperf
Etapa 2: analisar e criar recomendações
Se quiser, pule as seções aqui com base nos dados coletados acima.
2.1 Integridade do host do banco de dados
Realizar uma verificação de integridade rápida no host do banco de dados é um bom começo. Use os arquivos TFA/OSWatcher durante o período do problema. Você está procurando aqui sinais de saturação de recursos, utilização e/ou erros aqui. Também é possível usar BMS Infrascope
para entender seu ambiente em um nível alto usando o machine-id,
lun-id e assim por diante.
2.2.1 Registos do sistema
/var/log/messagesoudmesgpodem ser usados para identificar possíveis problemas no armazenamento, camada n/w como visto pelo sistema.# System messages cat /var/log/messages Or dmesg -T
2.2.2 CPU
"uptime"/"top" pode ser usado para visualizar as médias de carga do sistema nos últimos 1/5/15 min. Leve em consideração o número de núcleos de CPU ao analisar esses números. No Linux, esses números incluem o número de procedimentos na CPU/aguardando a CPU, bem como aqueles em suspensão ininterrupta(normalmente disco de E/S). Veja abaixo alguns comandos úteis.
# To find load average "w" Or "uptime" Or "top" [root@svr001 ~]# uptime 21:32:09 up 12 days, 1:04, 3 users, load average: 0.31, 0.44, 0.64 # To find CPU Usage over time "sar -u 5" [root@svr001 ~]# sar -u 5 Linux 4.14.35-2025.401.4.el7uek.x86_64 (svr001) 12/16/2020 _x86_64_ (16 CPU) 09:52:20 PM CPU %user %nice %system %iowait %steal %idle 09:52:25 PM all 0.63 0.00 0.73 0.11 0.00 98.52 09:52:30 PM all 1.10 0.00 0.82 0.15 0.00 97.93 # To list the no. of processes in Runnable (R) and in Uninterruptible sleep (D) states "ps -eo s,user,cmd | grep ^[RD] | sort | uniq -c | sort -nbr | head -20"
2.2.3 Memória
Use "gratuito" para encontrar a memória livre "disponível". Um sistema íntegro precisa ter espaço suficiente.
# Find system memory usage "free -m" [root@svr001 ~]# free -m total used free shared buff/cache available Mem: 385423 16603 188217 153744 180602 211778 Swap: 16383 0 16383"vmstat" pode ser usado para visualizar estatísticas de troca (si,assim). Você verá zero em um sistema íntegro. Também fornece outras colunas interessantes para procs/memory/cpu etc. que também podem ser do seu interesse, dependendo do problema.
# Virtual Mem stats 5 snapshots 5 secs apart "vmstat 5 5" [root@svr001 ~]# vmstat 5 5 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 192717472 497132 184439376 0 0 82 35 2 0 1 1 98 0 0 1 0 0 192717520 497132 184439616 0 0 3225 719 15118 29594 1 1 98 0 0Ative as páginas grandes se ainda não estiver ativada para aproveitar o tamanho maior da página, o bloqueio de sga na memória do sistema.
- Confirme o uso do ampliar da página na seção init.ora do relatório do awr (use_large_pages definido apenas) ou na seção de inicialização da instância em alerta.log.
- O não uso de bigpages também pode ser uma causa de troca do sistema e maior uso de memória por conexão com o banco de dados.
2.2.4 Armazenamento
"iostat" pode ser usado para ver as estatísticas dos dispositivos em blocos, como "await", avgqu-sz, %util, que podem indicar a saturação do armazenamento, o desempenho sub-par etc.
# IO Stats with extended per-disk statistics "iostat -x 5 5" Or "sar -dp" # For devices with 90% utilization and above "sar -dp | awk '/%util/ || ($11 > 90)'" [root@svr001 ~]# iostat -x 5 5 Linux 4.14.35-2025.401.4.el7uek.x86_64 (svr001) 12/16/2020 _x86_64_ (16 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 1.05 0.01 0.77 0.09 0.00 98.08 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sde 0.00 0.00 0.17 0.83 7.10 20.12 54.46 0.04 41.10 18.91 45.57 1.12 0.11 sdf 0.00 0.00 0.00 0.00 0.00 0.00 43.50 0.00 1.03 1.03 0.00 0.75 0.00 sdc 0.00 0.00 0.00 0.00 0.00 0.00 40.15 0.00 0.40 0.40 0.00 0.22 0.00 sda 0.00 0.00 1.16 20.80 7.76 177.15 16.84 0.02 0.82 0.73 0.83 0.14 0.31 sdd 0.00 0.00 43.24 8.03 639.16 97.67 28.75 0.01 0.20 0.18 0.31 0.18 0.92Estes são alguns bons pontos de partida, se você vir saturação com E/S:
- O QOS para o número de IOPS (8 mil blocos) para volumes SSD é 6.000 por terabyte. O Google não fornece QOS para HDD. Defina as expectativas corretas usando esses números.
- Se você não estiver vendo o QOS esperado acima, a próxima etapa pode ser verificar se você adere às práticas recomendadas em relação à configuração de armazenamento.
Cada servidor BMS tem quatro NICs, 25 Gbps em cada, vinculada a dois NICs de 50 Gb usando a agregação de links dinâmicos 802.3ad (ativo-ativo).
# Interface Transfer Speed # bond0 is the primary interface in this case. [root@svr001 ~]# ethtool bond0 | grep -i speed Speed: 50000Mb/sIsso significa que ( 50000 Mb/s = 6.250 MB/s = 6.400.000 KB/s) é o ponto de saturação da interface de rede principal.
# Interface stats "sar -n DEV | head -3 && sar -n DEV | grep bond0" [root@svr001 ~]# sar -n DEV | head -3 && sar -n DEV | grep bond0 12:00:01 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s 12:10:01 AM bond0.118 87.30 49.94 69.45 24.93 0.00 0.00 0.00 12:10:01 AM bond0 89.31 52.26 71.58 25.59 0.00 0.00 2.00 12:20:01 AM bond0.118 21.91 13.21 18.92 8.02 0.00 0.00 0.00 12:20:01 AM bond0 23.94 15.55 19.65 8.39 0.00 0.00 2.00
Use ferramentas comuns, como ping, traceroute, tnsping etc., para procurar possíveis problemas de rede, como perda/latência de pacotes entre máquinas de usuários/apps e o servidor db. Veja mais informações neste tutorial.
# Quick check for 9000 mtu. # If not configured correctly, we will see "Message too long" errors ping -c 5 -s 8972 -M do <IP>Analisar as estatísticas de interconexão no relatório de erros e comparar com um bom valor de referência, bem como usar o comando "netstat -s" (contadores de estatísticas do IP) para encontrar falhas de fragmentação/remontagem, problemas de sobrecarga de buffer etc. podem nos ajudar.{101 }sobre a integridade da rede privada.
# Interface errors: [root@svr001 ~]netstat -s | egrep "IP|Ip|ip:|TCP|Tcp|tcp:|UDP|Udp|udp:|ICMP|Icmp|icmp:|IGMP|igmp:|icmpv6:|ipv6:|drop|Drop|dropped|Dropped|error|Error|discard|Discard|timeout|Timeout|fail|Fail|Receive|receive" Ip: 168848352 total packets received 0 incoming packets discarded 701 outgoing packets dropped 3265322 fragments received ok
2.3 Integridade do banco de dados
Agora que você conhece a integridade geral do sistema e fez observações úteis, é possível explorar ainda mais a camada do banco de dados. Dependendo da natureza do problema, colete todos os relatórios relevantes (awm, ash etc.) e arquivos de registro (tfa, registros de alerta, arquivos de rastreamento etc.) que podem ajudar a diagnosticar o problema.
Algumas das principais áreas que você deve observar no relatório awr são:
Parte superior do relatório
- O resumo do ambiente informa informações sobre Oracle/s, informações de host, como núcleos, memória, tempo decorrido, tempo de banco de dados etc.
- O perfil de carregamento nos fornece informações sobre tempo do Db x CPU do DB, análise de estatísticas, estatísticas do IO etc.
- Tempo do banco de dados = CPU do banco de dados + Tempo de espera + Aguardando cpu (fila de execução)
- DB CPU = tempo de execução na CPU (runqueue não incluído)
- Média de sessão ativa = tempo db / tempo decorrido
- db cpu por segundo / (num_cpus * segundos decorridos) fornece informações sobre a saturação da CPU pelo banco de dados
Init.ora
- Procure qualquer parâmetro (sublinhado, relacionado à proteção de dados etc.) que possa ser um acionador aqui.
Principais eventos cronometrados em primeiro plano
- Investigue a distribuição de tempo do banco de dados para identificar o maior potencial de melhoria.
- Procure as principais esperas que aparecem na seção e as características de desempenho delas, como DBTime%, classe de espera ou média. tempo etc.
- Dependendo dos eventos encontrados nesta seção, detalharemos outras seções do relatório de erros.
Estatísticas do modelo de tempo
- Algumas das estatísticas importantes a serem observadas nesta seção são: análise, tempo de CPU em segundo plano, tempo de execução do sql, db cpu.
- Geralmente, são desejados um tempo de processamento SQL alto e tempos de análise baixos. O tempo de execução do sql é muito maior do que a CPU db pode indicar um tempo alto de espera.
Eventos comuns de espera da Oracle relacionados a problemas de infraestrutura
sincronização do arquivo de registros:
- A sincronização do arquivo de registro pode ser causada por problemas de infraestrutura subjacentes ou devido ao design do aplicativo. Veja abaixo algumas diretrizes que podem ser usadas para determinar se a infraestrutura degradada está contribuindo para esse evento de espera.
- A sincronização do arquivo de registros pode ser causada pelo baixo desempenho do armazenamento local, bem como pelo armazenamento remoto e/ou pela rede se o protetor de dados estiver envolvido.
- O desempenho de gravação paralela de arquivo de registro é um bom indicador de que existem latências no armazenamento local que afetam diretamente o desempenho de sincronização do arquivo de registros. É possível analisar os histogramas de eventos de espera e compará-los com valores de referência válidos para descobrir variações recentes. Uma gravação ideal em disco normalmente estaria mais próxima de 10 ms.
- Ter uma configuração de proteção de dados de disponibilidade/proteção máxima pode ser outro colaborador aqui. Observe as esperas relacionadas à proteção de dados e os histogramas dela podem ajudar a indicar latências de rede e/ou problemas de E/S no site de espera.
- Outra causa é um lgwr ocupado devido a confirmações excessivas ou privação da CPU. A estatística "tempo de CPU em segundo plano" precisa ser verificada para garantir que não seja uma grande parte do tempo do banco de dados.
- A sincronização do arquivo de registro pode ser causada por problemas de infraestrutura subjacentes ou devido ao design do aplicativo. Veja abaixo algumas diretrizes que podem ser usadas para determinar se a infraestrutura degradada está contribuindo para esse evento de espera.
Esperas relacionadas ao Cloud Storage:
- Além de recomendar o ajuste de aplicativos chatty ou de problemas de ponto de acesso, você deve verificar e eliminar a possibilidade de gargalos de desempenho da interconexão.
- BLOCOS DE CACHE GLOBAL PERDA/CORRUPTO devem estar o mais próximo possível de zero.
- LOST - bloquear as perdas durante as transferências. Pode indicar problemas de rede
- CORRUPT: valores altos indicam um problema de IPC, rede ou hardware.