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, abordarei uma maneira bastante simples, porém eficiente, de calcular o throughput de um banco de dados Oracle, independentemente 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 é chamada de CALIBRATE_IO e tem a função principal de mensurar a capacidade de I/O do dispositivo de storage onde o banco foi criado. Através da execução via Bloco PL/SQL é possível fazer este cálculo de maneira bem simples. Abaixo está a 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); 

Pré-requisitos 

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 (<DISKS>, <MAX_LATENCY>, 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 view DBA_RSRC_IO_CALIBRATE, a sugestão é alterar a procedure CALIBRATE_IO para armazenar cada execução em uma tabela auxilar. Abaixo segue o exemplo:

SET SERVEROUTPUT ON
DECLARE
  lat  INTEGER;
  iops INTEGER;
  mbps INTEGER;
BEGIN
-- DBMS_RESOURCE_MANAGER.CALIBRATE_IO (<DISKS>, <MAX_LATENCY>, 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 um 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 duas 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 o número 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