Desempenho da base de dados Oracle em volumes individuais do Azure NetApp Files
Este artigo aborda os seguintes tópicos sobre o Oracle na nuvem. Estes tópicos podem ser de particular interesse para um administrador de banco de dados, arquiteto de nuvem ou arquiteto de armazenamento:
- Quando você dirige uma carga de trabalho OLTP (processamento de transações online) (principalmente E/S aleatória) ou uma carga de trabalho OLAP (processamento analítico online) (principalmente E/S sequencial), como é o desempenho?
- Qual é a diferença de desempenho entre o cliente NFS (kNFS) do kernel Linux regular e o cliente Direct NFS da própria Oracle?
- No que diz respeito à largura de banda, o desempenho de um único volume de Arquivos NetApp do Azure é suficiente?
Importante
Para uma implantação correta e ideal do Oracle dNFS, siga as diretrizes de aplicação de patches descritas aqui.
Ambiente de teste e componentes
O diagrama a seguir ilustra o ambiente usado para testes. Para consistência e simplicidade, os playbooks do Ansible foram usados para implantar todos os elementos do banco de testes.
Configuração da máquina virtual
Os testes usaram a seguinte configuração para a máquina virtual:
- Sistema operativo:
RedHat Enterprise Linux 7.8 (wle-ora01) - Tipos de instância:
Dois modelos foram usados nos testes – D32s_v3 e D64s_v3 - Contagem da interface de rede:
Um (1) colocado na sub-rede 3 - Discos:
Os binários e o sistema operacional Oracle foram colocados em um único disco premium
Configuração dos Arquivos NetApp do Azure
Os testes usaram a seguinte configuração de Arquivos NetApp do Azure:
- Tamanho do pool de capacidade:
Vários tamanhos da piscina foram configurados: 4 TiB, 8 TiB, 16 TiB, 32 TiB - Nível de serviço:
Ultra (128 MiB/s de largura de banda por 1 TiB de capacidade de volume alocado) - Volumes:
Foram avaliados um e dois testes de volume
Gerador de carga de trabalho
Os testes utilizados carga de trabalho geraram SLOB 2.5.4.2. SLOB (Silly Little Oracle Benchmark) é um gerador de carga de trabalho bem conhecido no espaço Oracle projetado para estressar e testar o subsistema de E/S com uma carga de trabalho de E/S física em buffer SGA.
SLOB 2.5.4.2 não suporta o banco de dados conectável (PDB). Como tal, uma alteração foi adicionada setup.sh aos scripts e runit.sh para adicionar suporte ao PDB.
As variáveis SLOB usadas nos testes são descritas nas seções a seguir.
Carga de trabalho 80% SELECT, 20% UPDATE | E/S aleatórias – slob.conf variáveis
UPDATE_PCT=20
SCAN_PCT=0
RUN_TIME=600
WORK_LOOP=0
SCALE=75G
SCAN_TABLE_SZ=50G
WORK_UNIT=64
REDO_STRESS=LITE
LOAD_PARALLEL_DEGREE=12
Carga de trabalho 100% SELECT | E/S sequencial – slob.conf variáveis
UPDATE_PCT=0
SCAN_PCT=100
RUN_TIME=600
WORK_LOOP=0
SCALE=75G
SCAN_TABLE_SZ=50G
WORK_UNIT=64
REDO_STRESS=LITE
LOAD_PARALLEL_DEGREE=12
Base de Dados
A versão Oracle usada para os testes é o Oracle Database Enterprise Edition 19.3.0.0.
Os parâmetros Oracle são os seguintes:
sga_max_size: 4096Msga_target: 4096db_writer_processes: 12awr_pdb_autoflush_enabled: verdadeirofilesystemio_options: SETALLlog_buffer: 134217728
Foi criado um APO para a base de dados SLOB.
O diagrama a seguir mostra o espaço de tabela chamado PERFIO com 600 GB de tamanho (20 arquivos de dados, 30 GB cada) criado para hospedar quatro esquemas de usuário SLOB. Cada esquema de usuário tinha 125 GB de tamanho.
Métricas de desempenho
O objetivo era relatar o desempenho de IO conforme experimentado pelo aplicativo. Portanto, todos os diagramas neste artigo usam métricas relatadas pelo banco de dados Oracle por meio de seus relatórios AWR (Automatic Workload Repository). As métricas usadas nos diagramas são as seguintes:
- Média de solicitações de E/Seg
Corresponde à soma da média de Solicitações de E/S de Leitura/s e da média de Solicitações de E/S de Gravação/s da seção de perfil de carga - Média de E/S MB/seg
Corresponde à soma da média de E/S de leitura MB/s e da média de E/S de gravação MB/s da seção de perfil de carga - Latência média de leitura
Corresponde à latência média do evento Oracle Wait "db file sequential read" em microssegundos - Número de threads/esquema
Corresponde ao número de threads SLOB por esquema de usuário
Resultados da medição de desempenho
Esta secção descreve os resultados da medição do desempenho.
Cliente kNFS Linux vs. Oracle Direct NFS
Este cenário estava sendo executado em um Standard_D32s_v3 de VM do Azure (Intel E5-2673 v4 @ 2,30 GHz). A carga de trabalho é de 75% SELECT e 25% UPDATE, principalmente E/S aleatórias, e com um acerto de buffer de banco de dados de ~7,5%.
Como mostrado no diagrama a seguir, o cliente Oracle DNFS entregou até 2,8x mais taxa de transferência do que o cliente kNFS Linux normal:
O diagrama a seguir mostra a curva de latência para as operações de leitura. Nesse contexto, o gargalo para o cliente kNFS é a única conexão de soquete TCP NFS estabelecida entre o cliente e o servidor NFS (o volume Arquivos NetApp do Azure).
O cliente DNFS foi capaz de enviar mais solicitações de E/s devido à sua capacidade de criar centenas de conexões de soquete TCP, aproveitando assim o paralelismo. Conforme descrito na configuração dos Arquivos NetApp do Azure, cada TiB adicional de capacidade alocada permite 128 MiB/s adicionais de largura de banda. O DNFS atingiu 1 GiB/s de rendimento, que é o limite imposto pela seleção de capacidade de 8 TiB. Dada mais capacidade, mais rendimento teria sido impulsionado.
A taxa de transferência é apenas uma das considerações. Outra consideração é a latência, que tem o principal impacto na experiência do usuário. Como mostra o diagrama a seguir, aumentos de latência podem ser esperados muito mais rapidamente com kNFS do que com DNFS.
Os histogramas fornecem uma excelente visão sobre as latências do banco de dados. O diagrama a seguir fornece uma visão completa da perspetiva da "leitura sequencial do arquivo db" gravado, enquanto usa DNFS no ponto de dados de simultaneidade mais alto (32 threads/esquema). Como mostrado no diagrama a seguir, 47% de todas as operações de leitura foram honradas entre 512 microssegundos e 1000 microssegundos, enquanto 90% de todas as operações de leitura foram servidas em uma latência inferior a 2 ms.
Em conclusão, está claro que o DNFS é essencial quando se trata de melhorar o desempenho de uma instância de banco de dados Oracle em NFS.
Limites de desempenho de volume único
Esta seção descreve os limites de desempenho de um único volume com E/S aleatórias e E/S sequenciais.
E/S aleatórias
O DNFS é capaz de consumir muito mais largura de banda do que o fornecido por uma cota de desempenho de Arquivos NetApp do Azure de 8 TB. Ao aumentar a capacidade de volume dos Arquivos NetApp do Azure para 16 TiB, que é uma alteração instantânea, a quantidade de largura de banda de volume aumentou de 1024 MiB/s em 2X para 2048 MiB/s.
O diagrama a seguir mostra uma configuração para uma carga de trabalho de seleção de 80% e atualização de 20%, e com uma taxa de acertos do buffer de banco de dados de 8%. O SLOB foi capaz de direcionar um único volume para 200.000 solicitações de E/S NFS por segundo. Considerando que cada operação tem o tamanho de 8 KiB, o sistema em teste foi capaz de entregar ~200.000 solicitações de E/S/s ou 1600 MiB/s.
O diagrama de curva de latência de leitura a seguir mostra que, à medida que a taxa de transferência de leitura aumenta, a latência aumenta suavemente abaixo da linha de 1 ms e atinge o joelho da curva em ~165.000 solicitações de E/S de leitura média/seg na latência média de leitura de ~1,3 ms. Esse valor é um valor de latência incrível para uma taxa de E/S inatingível com quase qualquer outra tecnologia na Nuvem do Azure.
E/S sequencial
Como mostrado no diagrama a seguir, nem todas as E/S são aleatórias por natureza, considerando um backup RMAN ou uma verificação de tabela completa, por exemplo, como cargas de trabalho que exigem o máximo de largura de banda possível. Usando a mesma configuração descrita anteriormente, mas com o volume redimensionado para 32 TiB, o diagrama a seguir mostra que uma única instância de banco de dados Oracle pode gerar mais de 3.900 MB/s de taxa de transferência, muito próxima da cota de desempenho do volume do Azure NetApp Files de 32 TB (128 MB/s * 32 = 4096 MB/s).
Em resumo, o Azure NetApp Files ajuda você a levar seus bancos de dados Oracle para a nuvem. Ele oferece desempenho quando o banco de dados exige. Você pode redimensionar sua cota de volume de forma dinâmica e sem interrupções a qualquer momento.