Olá pessoal,

Espero que estejam bem!

Estou trabalhando para um cliente fazendo algumas tarefas pró-ativamente para checar a performance dos ambientes ao longo do tempo.

Eu sempre inicio um trabalho como esse usando o eDB360. Você pode checar mais sobre essa incrível ferramenta aqui.

Eu executei o eDB360 para os bancos de dados mais críticos do cliente. Esse é um ambiente com algumas aplicações SAP e algumas outras desenvolvidas por algumas empresas bem grandes.

Eu iniciei a análise do output do eDB360. Eu sempre inicio a análise nas primeiras seções do eDB360, e então, após algum tempo, eu analisei a Seção 3, referente às estatísticas de sistema operacional:

Depois disso, verifiquei o gráfico identificado pelo ID 323:”OS Load and CPU Cores for Instance 1″

Quando eu vi esse gráfico, minha única reação foi: uau!

A gente pode ver claramente que depois do começo de Junho, tivemos um aumento no OS Load. O OS Load aumentou e nunca mais baixou para os valores que tínhamos antes de Junho.

Então, eu analisei outros gráficos sobre CPU, todos eles da Seção 3 do eDB360.

OK, podemos concluir que todos os gráficos exibidos acima não possuem o aumento que se iniciou em 4 de Junho. De fato, nós podemos concluir que os gráficos de CPU exibidos possuem um comportamento similar em termos de performance. Nenhuma tendência foi alterada.

Analisando o gráfico de métricas de Load no Oracle Enterprise Manager:

Isso aí, confirmado que tivemos um aumento do load após 4 de Junho.

Vocês observaram a barra cinza escura antes do aumento do load?

Essa barra cinza escura significa um blackout do OEM.

OK, vamos então continuar com a investigação…

Primeiramente, o que significa o OS load?

De acordo com a documentação da Red Hat:

O “load average” (ou média de carga) é um número que corresponde à média do número de processos que estão em execução no sistema operacional. O load average é frequentemente listado em 3 conjuntos de números, que representa o load average nos últimos 1, 5 e 15 minutos.

Para esse problema específico, um blog post do Tanel Poder foi extremamente útil. De fato, foi graças a esse blog post que encontrei o problema! Obrigado Tanel!

Você pode checar sobre o blog post aqui: High System Load with Low CPU Utilization on Linux?

No blog post dele, há também uma excelente explicação sobre o Load no sistema operacional:

OK, então o load pode estar relacionado aos processos no estado Runnable (em execução), ma também podem estar relacionado a processos no estado Uninterruptible sleep (algo como… sono ininterrupto).

À partir disso, iniciei um drill down no OS para checar mais em detalhes. O nome do servidor foi alterado por motivo de segurança! 🙂

sar -u 5

Vamos checar o output do sar:

Pelo sar podemos ver claramente que a utilização de CPU nunca excedeu 45%! Isso confirma os gráficos anteriores exibidos no meu blog post.

O próximo passo é checar o que (e quem) está contribuindo ao aumento do Load do sistema operacional:

ps -eo s,user | grep ^[RD] | sort | uniq -c | sort -nbr | head -20

     30 D root
      2 R orape1
      1 R root

Podemos ver que há 1 processo em Runnable state cujo dono é o root, 2 processos em Runnable state cujo dono é o usuário orape1 (o nosso usuário oracle nesse caso) e 30 processos em Uninterrupted sleep state cujo dono é o root. Interessante, hein?

Vamos continuar com o drill down e ver quais são esses processos:

ps -eo s,user,cmd | grep ^[RD] | sort | uniq -c | sort -nbr | head -45

      1 R root     ps -eo s,user,cmd
      2 R orape1   oraclePE1 (LOCAL=NO)
      1 D root     [llt_hb/9]
      1 D root     [llt_hb/8]
      1 D root     [llt_hb/7]
      1 D root     [llt_hb/6]
      1 D root     [llt_hb/5]
      1 D root     [llt_hb/4]
      1 D root     [llt_hb/3]
      1 D root     [llt_hb/29]
      1 D root     [llt_hb/28]
      1 D root     [llt_hb/27]
      1 D root     [llt_hb/26]
      1 D root     [llt_hb/25]
      1 D root     [llt_hb/24]
      1 D root     [llt_hb/23]
      1 D root     [llt_hb/22]
      1 D root     [llt_hb/21]
      1 D root     [llt_hb/20]
      1 D root     [llt_hb/2]
      1 D root     [llt_hb/19]
      1 D root     [llt_hb/18]
      1 D root     [llt_hb/17]
      1 D root     [llt_hb/16]
      1 D root     [llt_hb/15]
      1 D root     [llt_hb/14]
      1 D root     [llt_hb/13]
      1 D root     [llt_hb/12]
      1 D root     [llt_hb/11]
      1 D root     [llt_hb/10]
      1 D root     [llt_hb/1]
      1 D root     [llt_hb/0]

Todos os 30 processos em Uninterrupted state estão relacionados ao mesmo cara: llt_hb

Fazendo pesquisas, encontrei isso aqui:

Hummm, nesse documento da base de conhecimento da Red Hat há uma referência a um artigo de suporte para o site da Veritas:

Nós também temos isso no artigo de suporte da Veritas:

“The load average increases to approximately the number of CPU’s installed on the system. Here is an example on an 8 CPU server.”

Portanto, o load aumenta para aproximadamente o número de CPUs instaladas no sistema… isso bate com o que temos aqui no ambiente!

Vamos agora identificar a qual pacote esse processo pertence:

rpm -qa |grep llt


VRTSllt-8.0.0.0000-RHEL7.x86_64

Ótimo! Vamos ver mais detalhes sobre esse pacote:

rpm -qi VRTSllt

Name        : VRTSllt
Version     : 8.0.0.0000
Release     : RHEL7
Architecture: x86_64
Install Date: Sun 04 Jun 2023 08:29:28 AM UTC
Group       : Applications/System
Size        : 83286225
License     : Veritas Proprietary
Signature   : RSA/SHA1, Mon 22 Nov 2021 04:49:39 PM UTC, Key ID 4e84af75cc633953
Source RPM  : VRTSllt-8.0.0.0000-RHEL7.src.rpm
Build Date  : Mon 01 Nov 2021 06:42:01 PM UTC
Build Host  : vcsrsvrhel7bld1.rsv.ven.veritas.com
Relocations : (not relocatable)
Packager    : enterprise_technical_support@veritas.com
Vendor      : Veritas Technologies LLC
URL         : www.veritas.com/support
Summary     : Veritas Low Latency Transport
Description :
Veritas Low Latency Transport (LLT) Driver and commands for Linux
Supported kernel(s): 3.10.0-862.el7.x86_64 3.10.0-957.el7.x86_64 3.10.0-1062.el7.x86_64 3.10.0-1127.el7.x86_64 3.10.0-1160.el7.x86_64 [LINUX_RHEL70]
Build Stamp: Veritas-8.0.0.0000-2021-11-01_12.48.55

Observaram algo de interessante?

Install Date: Sun 04 Jun 2023 08:29:28 AM UTC

Isso bate com a data que observamos o aumento de load no sistema operacional!

Como citei anteriormente, esse ambiente utiliza aplicações SAP, para todos os bancos de dados de Produção das aplicações SAP, há clusters Veritas configurados. Nós checamos outros servidores (mesmo servidores de aplicação) e o comportamento é o mesmo, exemplo:

Também checamos um servidor onde temos o Oracle RAC / Grid Infrastructure como solução de cluster, para esse servidor, não temos o aumento de load. Ou seja, esse é de fato um problema específico do Veritas:

Nós compartilhamos todos esses detalhes com o time de Linux e eles abriram um chamado com alta prioridade no suporte da Veritas. Portanto, um novo patch deve ser liberado ou o time da Veritas vai solicitar a alteração em alguma configuração.

Espero que seja útil!

Um abraço!

Vinicius