domingo, 24 de janeiro de 2021

VM Guest lenta e com elevado percentual de CPU roubada (steal)

Acompanhando a performance de algumas máquinas virtualizadas em um ODA X7-2 HA foi observado durante o período alto percentual de CPU steal (%st) que mostra a porcentagem de tempo gasto (roubado)  em esperas involuntárias da CPU enquanto o hypervisor está atendendo outro processador virtual.

Para dar ênfase ao problema e posteriormente demonstrar a mudança de comportamento junto aos ajustes em uma VM com 8 vCPU, forcei a utilização de CPU disparando comandos "yes" em nohup onde dentro de alguns segundos o percentual de CPU roubada já atingiu 68%

[root@vm04 ~]# cat /proc/cpuinfo | egrep 'processor' | wc -l
8
[root@vm04 ~]#
[root@vm04 ~]# yes > /dev/null &
[1] 26080
[root@vm04 ~]# yes > /dev/null &
[2] 26135
[root@vm04 ~]# yes > /dev/null &
[3] 26137
[root@vm04 ~]# yes > /dev/null &
[4] 26138
[root@vm04 ~]#














Tratando-se de um Oracle engineered systems, busquei como referência o MOS (My Oracle Support) onde encontrei a Doc ID 1928868.1 falando exatamente sobre este comportamento destacando em seu título "Guest VM Running Slow and is not Able to Use All the CPUs Assigned to it on ODA"

Este comportamento ocorre devido ao parâmetro CPU_CAP estar definido como 100 que independente da quantidade de CPUs associados a máquina virtual ela utilizará apenas 1 CPU.

Cancelando o stress de CPU na VM

[root@vm04 ~]# pkill yes
[1]   Terminated              yes > /dev/null
[2]-  Terminated              yes > /dev/null
[3]-  Terminated              yes > /dev/null
[4]+  Terminated              yes > /dev/null

No dom0 confirme o valor do CPU CAP e ajuste dinamicamente seu valor para 0. 

[root@dom0 ~]# xm sched-credit
Name                                ID Weight  Cap
Domain-0                             0  65535    0
oakDom1                              1    256    0
vm03                                 3    256  100
vm04                                 4    256  100


[root@dom0 ~]# xm sched-credit -d vm04 -c 0
[root@dom0 ~]# xm sched-credit
Name                                ID Weight  Cap
Domain-0                             0  65535    0
oakDom1                              1    256    0
vm03                                 3    256  100
vm04                                 4    256    0
[root@dom0 ~]#

Ao ser criado uma VM, o valor padrão para o parâmetro é 100%. Esse valor é então convertido em um limite de utilização da CPU no arquivo vm.cfg para a máquina virtual. 

O valor definido no arquivo vm.cfg limita a quantidade de CPU que um convidado (VM Guest) pode consumir. Se o Processor Cap for definido como 100% no Oracle VM, o valor definido em vm.cfg será 0, o que significa que não há limite para a utilização da CPU.

Retornando a VM vou proceder com um novo teste forçando a utilização das CPUs da mesma forma que a anterior

[root@vm04 ~]# yes > /dev/null &
[1] 31926
[root@vm04 ~]# yes > /dev/null &
[2] 31928
[root@vm04 ~]# yes > /dev/null &
[3] 31929
[root@vm04 ~]# yes > /dev/null &
[4] 31976

Com alguns segundos já foi perceptível que o percentual de CPU roubada não sofria oscilações, estava de forma constante em 0%















Comparando o antes e depois do ajuste

















Referência:

Guest VM Running Slow and is not Able to Use All the CPUs Assigned to it on ODA (Doc ID 1928868.1)

Mais informações →

quarta-feira, 29 de julho de 2020

sábado, 18 de julho de 2020

terça-feira, 16 de junho de 2020

segunda-feira, 18 de maio de 2020

Exibindo valores válidos para parâmetros de múltiplas opções

Dentre seus milhares de parâmetros, o Oracle Database possui parâmetros do tipo string, número, booleano e os que aceitam uma lista predeterminada de valores como o cursor_sharing, por exemplo, que pode ser configurado com os valores SIMILAR, EXACT e FORCE.

Para sabermos os valores válidos para estes parâmetros de múltiplas opções predeterminadas podemos:


1. Consultar a documentação Oracle onde será exibido a lista de valores válidos, desde que o parâmetro não seja oculto.

Adicionar legenda

2. Alterar o parâmetro, incluindo os ocultos para um valor não válido, desta forma a lista de valores suportados será exibida:

SQL> alter system set cursor_sharing='X';
alter system set cursor_sharing='X'
*
ERROR at line 1:
ORA-00096: invalid value X for parameter cursor_sharing, must be from among SIMILAR, EXACT, FORCE

SQL> alter system set "_mv_refresh_enhanced_dml_detection"='TST';
alter system set "_mv_refresh_enhanced_dml_detection"='TST'
*
ERROR at line 1:
ORA-00096: invalid value TST for parameter _mv_refresh_enhanced_dml_detection, must be from among ON_RC, ON, OFF

3. Utilizar a view v$parameter_valid_values, não é válida para parâmetros ocultos
set lines 200
col name for a50
col value for a30
select * from v$parameter_valid_values where name='use_large_pages';

       NUM NAME                                                  ORDINAL VALUE                          ISDEFAULT
---------- -------------------------------------------------- ---------- ------------------------------ -----------------------
       117 use_large_pages                                             1 TRUE                           TRUE
       117 use_large_pages                                             2 AUTO                           FALSE
       117 use_large_pages                                             3 ONLY                           FALSE
       117 use_large_pages                                             4 FALSE                          FALSE

4. ou, ainda utilizar a X$KSPVLD_VALUES onde podemos visualizar os valores válidos inclusive para os parâmetros ocultos
set lines 200
col ISDEFAULT_KSPVLD_VALUES for a15
col VALUE_KSPVLD_VALUES for a30
select PARNO_KSPVLD_VALUES NUM,
       NAME_KSPVLD_VALUES NAME,
       ORDINAL_KSPVLD_VALUES ORDINAL,
       VALUE_KSPVLD_VALUES VALUE,
       DECODE(ISDEFAULT_KSPVLD_VALUES, 'FALSE', '', 'DEFAULT') ISDEFAULT
  from X$KSPVLD_VALUES
 where NAME_KSPVLD_VALUES = '_mv_refresh_enhanced_dml_detection';

       NUM NAME                                                  ORDINAL VALUE                          ISDEFAU
---------- -------------------------------------------------- ---------- ------------------------------ -------
      2484 _mv_refresh_enhanced_dml_detection                          1 OFF
      2484 _mv_refresh_enhanced_dml_detection                          2 ON
      2484 _mv_refresh_enhanced_dml_detection                          3 ON_RC                          DEFAULT

enjoy!

Mais informações →

quinta-feira, 19 de março de 2020

Pré-requisitos para instalação do Oracle Database no Linux

Quando pensamos em instalar um banco de dados Oracle é importante nos lembrarmos que existem um conjunto de requisitos de hardware, software e sistema operacional a serem atendidos e que estes podem facilmente serem encontrados nas documentações da Oracle através do Oracle Help Center (Oracle Docs) e MOS (My Oracle Support).



Ao vencermos etapas, como o provisionamento de hardware destinado ao banco de dados e a instalação de um sistema operacional homologado, como o Linux 7 para o Oracle Database 19c, por exemplo, que é facilmente identificado através da matriz de certificação disponível no MOS,





É necessário também proceder com alguns ajustes no sistema operacional de modo que todos os pré-requisitos relacionados ao produto e versão que será instalada sejam atendidos, pois o banco de dados requer pacotes específicos de software para garantir seu funcionamento bem como ajustes em determinados parâmetros do kernel. 

Estes pré-requisitos a nível de sistema operacional também podem ser encontrados nas fontes descritas acima, porém a muito tempo a Oracle já oferece alguns pacotes que facilitam estes ajustes básicos relacionados aos pré-requisitos de funcionamento do produto.

Os pacotes foram evoluindo e mudando de nome conforme versão do sistema operacional Linux e versão do produto Oracle:

  • oracle-validated
  • oracle-rdbms-server-11gR2-preinstall
  • oracle-rdbms-server-12cR1-preinstall
  • oracle-database-server-12cR2-preinstall
  • oracle-database-preinstall-18c
  • oracle-database-preinstall-19c

Para instalar um dos pacotes basta realizar o download do arquivo ou do repositório condizente a versão do sistema operacional e proceder com a instalação do pacote.


# cd /etc/yum.repos.d
# wget http://public-yum.oracle.com/public-yum-ol7.repo
# yum install oracle-database-preinstall-19c


# curl -o oracle-database-preinstall-19c-1.0-2.el7.x86_64.rpm https://yum.oracle.com/repo/OracleLinux/OL7/latest/x86_64/getPackage/oracle-database-preinstall-19c-1.0-2.el7.x86_64.rpm
# yum -y localinstall oracle-database-preinstall-19c-1.0-2.el7.x86_64.rpm
# rm oracle-database-preinstall-19c-1.0-2.el7.x86_64.rpm


Concluída mais esta etapa de pré-requisitos, pode-se dar sequencia na instalação do Oracle Database onde durante sua instalação via GUI (Graphical User Interface), por exemplo, será realizada uma nova consistência de pre-requisitos e caso algum novo ajuste seja necessário será informado na tela do usuário para que possa ser ajustado ou ignorado (em alguns casos temos pacotes que podem ser ignorados, mas sempre confirme junto a documentação Oracle especialmente se for um ambiente produtivo para evitar problemas futuros).

Espero que as dicas possam ser úteis, até a próxima.
Mais informações →

domingo, 23 de fevereiro de 2020

Checksum de fontes PL/SQL

Assim como temos em ambientes Linux o cksum e o sha1sum que nos permitem gerar um código hash para a comparação de consistência de um arquivo, umas das opções no Oracle Database é a função GET_HASH_VALUE disponível no pacote DBMS_UTILITY que permite gerar um código hash do fonte sendo muito útil para identificar se ele está consistente ou se houve alguma alteração, principalmente quando comparamos extensos códigos PL/SQL que visivelmente daria trabalho para determinar se estão iguais entre uma base de dados e outra, por exemplo.

Criando uma procedure de exemplo e obtendo o hash:

SQL> create or replace procedure exemplo as
  2  begin
  3  null;
  4  end;
  5  /

Procedure created.

SQL> SELECT AVG(DBMS_UTILITY.GET_HASH_VALUE(TEXT,1000000000,POWER(2,30))) AS CHECKSUM FROM DBA_SOURCE WHERE OWNER = 'SYS' AND NAME ='EXEMPLO';

  CHECKSUM
----------
1742638361

Agora recriando a procedure incluindo apenas um espaço entre o null e o ; (ponto e virgula)

SQL> create or replace procedure exemplo as
  2  begin
  3  null ;
  4  end;
  5  /

Procedure created.

SQL> SELECT AVG(DBMS_UTILITY.GET_HASH_VALUE(TEXT,1000000000,POWER(2,30))) AS CHECKSUM FROM DBA_SOURCE WHERE OWNER = 'SYS' AND NAME ='EXEMPLO';

  CHECKSUM
----------
1701853948

Com a inserção de apenas um espaço já podemos constatar que o hash dela já não é igual ao hash do PL/SQL anterior indicando assim que o fonte é diferente.

Recriando a procedure da forma que era originalmente iremos voltar a ter o mesmo hash 1742638361


SQL> create or replace procedure exemplo as
  2  begin
  3  null;
  4  end;
  5  /

Procedure created.

SQL> SELECT AVG(DBMS_UTILITY.GET_HASH_VALUE(TEXT,1000000000,POWER(2,30))) AS CHECKSUM FROM DBA_SOURCE WHERE OWNER = 'SYS' AND NAME ='EXEMPLO';

  CHECKSUM
----------
1742638361

Outro método para se obter o hash de um PL/SQL é através do pacote DBMS_CRYPTO

SQL> set serveroutput on
SQL> declare
  2
  3  string varchar2(32767);
  4  l_hash raw(2000);
  5  lvschema VARCHAR2(30) :='SYS';
  6  lvname VARCHAR2(30) :='EXEMPLO';
  7  lvtype varchar2(30) :='PROCEDURE';
  8
  9  begin
 10
 11  l_hash:=dbms_crypto.hash(dbms_metadata.get_ddl(lvtype, lvname, lvschema), dbms_crypto.hash_sh1);
 12  dbms_output.put_line('HashSHA1='||l_hash||' Name='||lvschema||'.'||lvname);
 13
 14  end;
 15  /
HashSHA1=859EEB0AEE5CF93CF9507951E7446D6EAD958885 Name=SYS.EXEMPLO

PL/SQL procedure successfully completed.

Espero que a dica possa ser útil para você também.
Mais informações →
Postagens mais antigas Página inicial

Translate

# Suporte

# ACE Program

#Oracle

#Oracle
Disclaimer: The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

#Blog reconhecido

#ARTICULISTA

Marcadores

Postagens populares