Medindo Throughput do Oracle Database com Calibrate IO

Uma das dúvidas mais comuns de Administradores de Banco de Dados é conseguir mensurar a quantidade de I/O ou throughput em MB de um Banco de Dados em relação aos dispositivos de armazenamento (storage).

Neste artigo será abordada uma maneira bastante simples, porém eficiente, de calcular othroughput de um Banco de Dados Oracle, independente da plataforma.

DBMS_RESOURCE_MANAGER

O Oracle Database Resource Manager (DBRM) permite que o Oracle gerencie / limite recursos utilizados pelo Banco de Dados.

A partir da versão 11g, o Oracle Database oferece uma nova procedure na package DBMS_RESOURCE_MANAGER. Esta procedure é chamado de CALIBRATE_IO e tem a função principal de mensurar a capacidade de I/O do dispositivo de Storage onde o Banco de Dados foi criado.

Através da execução via Bloco PL/SQL é possível fazer este cáculo de maneira bem simples. Abaixo descrição dos parâmetros da procedure CALIBRATE_IO

Parâmetros

DBMS_RESOURCE_MANAGER.CALIBRATE_IO (
num_physical_disks      IN  PLS_INTEGER DEFAULT 1,
max_latency             IN  PLS_INTEGER DEFAULT 20,
max_iops                OUT PLS_INTEGER,
max_mbps                OUT PLS_INTEGER,
actual_latency          OUT PLS_INTEGER);
Parâmetro
Descrição
num_physical_disks
Número de discos físicos onde o Database está alocado.
max_latency
Tolerância máximo em milisegundos para requisições de   I/O no Banco de dados
max_iops
Número máximo de requisições de I/O por segundo que pode ser suportado pela estrutura de Armazenamento.As requisições de I/O são distribuídas através de leitura de Blocos do Banco de Dados.
max_mbps
Throughput Máximo em MB/s que pode ser suportado pela estrutura de Armazenamento. As requisições são distribuídas em leituras de 1MB.
actual_latency
Latência médis em milisegundos para leitura de blocos do Database.

Pré-Requistios

Antes da execução alguns pré-requisitos são necessários.

– Usuário com Privilégio SYSDBA (Normalmente executado com usuário SYS).

– Parâmetro TIMED_STATISTICS=TRUE

– ASYNCH_IO habilitado para todos os arquivos do Database. Para verificar, pode-se executar o script abaixo:

col name format a50
SELECT name, asynch_io FROM v$datafile f,v$iostat_file i
WHERE f.file#      = i.file_no
AND filetype_name  = 'Data File'
/

– Executar apenas uma operação (CALIBRATE) por vez.

– Em ambientes com Oracle Real Application Clusters, a carga será distribuída entre todos os Nodes.

Exemplo de Execução

SET SERVEROUTPUT ON
DECLARE
  lat  INTEGER;
  iops INTEGER;
  mbps INTEGER;
BEGIN
-- DBMS_RESOURCE_MANAGER.CALIBRATE_IO (, , iops, mbps, lat);
   DBMS_RESOURCE_MANAGER.CALIBRATE_IO (2, 10, iops, mbps, lat);

  DBMS_OUTPUT.PUT_LINE ('max_iops = ' || iops);
  DBMS_OUTPUT.PUT_LINE ('latency  = ' || lat);
  dbms_output.put_line('max_mbps = ' || mbps);
end;
/

O resultado de execução é demonstrado abaixo:

SQL> @calibrate
max_iops = 3100
latency = 20
max_mbps = 376

O resultado de cada execução é demonstrado também na view DBA_RSRC_IO_CALIBRATE.

SQL> desc DBA_RSRC_IO_CALIBRATE
Name Null? Type
START_TIME TIMESTAMP(6)
END_TIME TIMESTAMP(6)
MAX_IOPS NUMBER
MAX_MBPS NUMBER
MAX_PMBPS NUMBER
LATENCY NUMBER
NUM_PHYSICAL_DISKS NUMBER

Como somente a última execução da procedure CALIBRATE_IO é listada na viewDBA_RSRC_IO_CALIBRATE a sugestão é alterar a procedure CALIBRATE_IO para armazenar cada execução em uma tabela auxilar. Abaixo exemplo:

SET SERVEROUTPUT ON
DECLARE
lat  INTEGER;
iops INTEGER;
mbps INTEGER;
BEGIN
-- DBMS_RESOURCE_MANAGER.CALIBRATE_IO (, , iops, mbps, lat);
DBMS_RESOURCE_MANAGER.CALIBRATE_IO (2, 10, iops, mbps, lat);
insert into CALIBRATE_REPORT as select * from DBA_RSRC_IO_CALIBRATE;

DBMS_OUTPUT.PUT_LINE ('max_iops = ' || iops);
DBMS_OUTPUT.PUT_LINE ('latency  = ' || lat);
DBMS_OUTPUT.PUT_LINE ('max_mbps = ' || mbps);
end;

O tempo de execução está diretamente ligado a alguns fatores:

  • Performance na estrutura de Armazenamento (Storage);
  • Número de Datafiles;
  • Tamanho do Database;

Em Storage compartilhados, por exemplo ambiente clusterizado, a performance pode variar também de acordo com o número de Nodes do Cluster.

Listando Resultados

Após a execução, pode-se listar os resultados de 2 maneiras:

– Pelo output da Procedure

SQL> @calibrate
max_iops = 3100
latency = 20
max_mbps = 376

– Pela view DBA_RSRC_IO_CALIBRATE

SELECT MAX_IOPS, MAX_MBPS,  MAX_PMBPS, ACTUAL_LATENCY, NUM_PHYSICAL_DISKS FROM DBA_RSRC_IO_CALIBRATE;
MAX_IOPS MAX_MBPS MAX_PMBPS LATENCY NUM_PHYSICAL_DISKS
428 176 77 8 4

*Esta lista somente a última execução. Implementando a alteração na execução da procedure CALIBRATE_IO, pode-se obter resultados de todas as execuções:

MAX_IOPS MAX_MBPS MAX_PMBPS LATENCY NUM_PHYSICAL_DISKS
428 176 77 8 4
524 173 76 21 4
537 183 74 28 4
598 174 78 38 4

Interpretando Resultados

Os resultados acima demonstram o máximo atingido em operações de Leitura nos discos do Storage.

O melhor resultado obtido foi de 428 operações de I/O por Segundo (em média), com latência de 8ms.

Para calcular a média de I/O por segundo em cada disco, basta dividir este valor pelo número de discos: 428/4 = 107 operações de I/O por segundo para cada disco do Storage.

Com estes resultados é possível gerar um gráfico de consumo de I/O e throughput com o resumo de execução:

Como demonstrado no Gráfico acima, o aumento (tolerância) de latência em milisegundos para operações no Banco de Dados  não gera um aumento  significativo de throughput nos discos do Storage.

Para operações em Banco de Dados (OLTP) a recomendação é manter o tempo médio de latência abaixo de 10ms.

O throughput do Storage em MB permaneceu o mesmo durante todo o teste, atingindo media de 176MB/s por operação de I/O.

Observações importantes:

  • Neste cenário, para aumentar o máximo de operações de I/O por Segundo, é nécessário o aumentar nº de discos no Storage ou ainda discos com maior performance.
  • O Número máximo de operações de I/O pode ou não atender as necessidades de uma determinada aplicação. Isso dependerá das operações que a aplicação irá solicitar ao banco de dados.
  • Relatórios AWR podem também ajudar a encontrar alta latência em requisições de I/O ao Banco de Dados.

Os resultados se alternam conforme a configuração de Hardware e Software de cada ambiente analisado. É importante manter um throughput compatível com a necessidade do Banco de Dados afim de evitar problemas de performance no acesso à aplicações.

Fonte e mais informações:
http://docs.oracle.com/cd/B28359_01/appdev.111/b28419/d_resmgr.htm#CJGHGFEA
http://docs.oracle.com/cd/E11882_01/server.112/e16638/iodesign.htm#CHDFBGFB

Abs

Victor DBA
http://victordba.net

Victor Armbrust

Mais artigos deste autor »

DBA Oracle há 7 anos, especialista em Banco de Dados Oracle, com conhecimentos em MySQL, DB2 e SQL-Server. Bacharel em Ciências da Computação pela USCS (Universidade de São Caetano do Sul). Com sólidos conhecimentos em Banco de Dados e Sistemas operacionais, possui certificações OCP 10g/11g, OCE 11g Performance Tuning, OCE 10g RAC, OCS 11g Exadata, OCA Solaris 10, OCA Mysql 5, MCITP SQL Server 2008 R2, IBM DB2 Administrator, LPIC-3, OCA Solaris 10, entre outras.

Apoiador de eventos do GUOB e participante ativo no grupo de Profissionais Oracle (GPO).

Articulista do portal iMasters

Instrutor Oficial Oracle University

Consultor de Banco de Dados na Oracle Advanced Customer Support Services.


Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!