Azure NetApp Files 단일 볼륨의 Oracle 데이터베이스 성능

  • 아티클

이 문서에서는 클라우드의 Oracle에 대한 다음 항목을 다룹니다. 해당 항목은 데이터베이스 관리자, 클라우드 설계자 또는 스토리지 설계자와 특히 관련이 있을 수 있습니다.

  • OLTP(온라인 트랜잭션 처리) 워크로드(대부분 임의 I/O) 또는 OLAP(온라인 분석 처리) 워크로드(대부분 순차 I/O)를 구동하는 경우 성능은 어떤가요?
  • 일반 Linux kNFS(커널 NFS) 클라이언트와 Oracle 고유의 Direct NFS 클라이언트 간에 어떤 성능 차이가 있나요?
  • 대역폭과 관련해서 단일 Azure NetApp Files 볼륨의 성능이 충분한가요?

Important

Orace dNFS의 정확하고 최적의 배포를 위해 여기에 설명된 패치 지침을 따릅니다.

환경 및 구성 요소 테스트

다음 다이어그램은 테스트에 사용되는 환경을 보여 줍니다. 일관되고 간편한 배포를 위해 Ansible 플레이북을 사용하여 테스트 환경의 모든 요소를 배포했습니다.

Oracle testing environment

가상 머신 구성

테스트에서 사용한 가상 머신 설정은 다음과 같습니다.

  • 운영 체제:
    RedHat Enterprise Linux 7.8(wle-ora01)
  • 인스턴스 유형:
    D32s_v3 및 D64s_v3의 두 가지 모델이 테스트에 사용됨
  • 네트워크 인터페이스 수:
    서브넷 3에 1개가 배치됨
  • 디스크:
    Oracle 이진 파일 및 OS가 단일 프리미엄 디스크에 배치됨

Azure NetApp Files 구성

테스트에서 사용한 Azure NetApp Files 구성은 다음과 같습니다.

  • 용량 풀 크기:
    4TiB, 8TiB, 16TiB, 32TiB 등 다양한 크기의 풀이 구성됨
  • 서비스 수준:
    Ultra(할당된 볼륨 용량 1TiB당 128MiB/초 대역폭)
  • 볼륨:
    한두 개의 볼륨 테스트가 평가됨

워크로드 생성기

테스트에서는 SLOB 2.5.4.2에서 생성된 워크로드를 사용했습니다. SLOB(Silly Little Oracle Benchmark)는 SGA로 버퍼링된 물리적 I/O 워크로드를 사용하여 SGA 하위 시스템에 스트레스를 주고 테스트하도록 설계된, Oracle 영역에서 잘 알려진 워크로드 생성기입니다.

SLOB 2.5.4.2는 PDB(플러그형 데이터베이스)를 지원하지 않습니다. 따라서 PDB 지원을 추가하기 위해 setup.sh 및 runit.sh 스크립트에 변경 내용이 추가되었습니다.

테스트에 사용된 SLOB 변수는 다음 섹션에 설명되어 있습니다.

워크로드 80% SELECT, 20% UPDATE | 임의 I/O – slob.conf 변수

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

워크로드 100% SELECT | 순차 I/O – slob.conf 변수

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

데이터베이스

테스트에 사용된 Oracle 버전은 Oracle Database Enterprise Edition 19.3.0.0입니다.

Oracle 매개 변수는 다음과 같습니다.

  • sga_max_size: 4096M
  • sga_target: 4096
  • db_writer_processes: 12
  • awr_pdb_autoflush_enabled: true
  • filesystemio_options: SETALL
  • log_buffer: 134217728

SLOB 데이터베이스에 대한 PDB를 만들었습니다.

다음 다이어그램은 SLOB 사용자 스키마 4개를 호스트하기 위해 생성된 600GB 크기(각각 30GB인 데이터 파일 20개)의 PERFIO라는 테이블스페이스를 보여 줍니다. 각 사용자 스키마의 크기는 125GB입니다.

Oracle database

성능 메트릭

목표는 애플리케이션에서 경험한 대로 IO 성능을 보고하는 것이었습니다. 따라서 이 문서의 모든 다이어그램은 AWR(자동 워크로드 리포지토리) 보고서를 통해 Oracle 데이터베이스에서 보고된 메트릭을 사용합니다. 다이어그램에서 사용된 메트릭은 다음과 같습니다.

  • 평균 IO 요청/초
    부하 프로필 섹션의 평균 읽기 IO 요청/초 및 평균 쓰기 IO 요청/초의 합계에 해당합니다.
  • 평균 IO MB/초
    부하 프로필 섹션의 평균 읽기 IO MB/초 및 평균 쓰기 IO MB/초의 합계에 해당합니다.
  • 평균 읽기 대기 시간
    Oracle 대기 이벤트 “db 파일 순차 읽기”의 평균 대기 시간(마이크로초)에 해당합니다.
  • 스레드 수/스키마
    사용자 스키마당 SLOB 스레드 수에 해당합니다.

성능 측정 결과

이 섹션에서는 성능 측정 결과에 대해 설명합니다.

Linux kNFS 클라이언트와 Oracle Direct NFS의 비교

이 시나리오는 Azure VM Standard_D32s_v3(Intel E5-2673 v4 @ 2.30 GHz)에서 실행되었습니다. 워크로드는 75% SELECT 및 25% UPDATE로, 대부분 임의 I/O이며 데이터베이스 버퍼 적중은 ~7.5%입니다.

다음 다이어그램과 같이 Oracle DNFS 클라이언트는 일반 Linux kNFS 클라이언트보다 최대 2.8배 높은 처리량을 제공했습니다.

Linux kNFS Client compared with Oracle Direct NFS

다음 다이어그램은 읽기 작업의 대기 시간 곡선을 보여 줍니다. 이 컨텍스트에서 kNFS 클라이언트의 병목 상태는 클라이언트와 NFS 서버(Azure NetApp Files 볼륨) 간에 설정된 단일 NFS TCP 소켓 연결입니다.

Linux kNFS Client compared with Oracle Direct NFS latency curve

DNFS 클라이언트는 수백 개의 TCP 소켓 연결을 만들 수 있기 때문에 더 많은 IO 요청/초를 푸시하여 병렬 처리를 활용할 수 있었습니다. Azure NetApp Files 구성에 설명된 대로 각 TiB 용량을 추가로 할당할 때마다 128MiB/초의 대역폭을 더 사용할 수 있습니다. DNFS의 최대 처리량은 8TiB 용량 선택 시 적용되는 한도인 1GiB/초였습니다. 용량을 더 많이 지정했다면 처리량이 더 증가했을 것입니다.

처리량은 고려 사항 중 하나일 뿐입니다. 또 다른 고려 사항은 사용자 환경에 주로 영향을 주는 대기 시간입니다. 다음 다이어그램에서 볼 수 있듯이 DNFS보다 kNFS에서 대기 시간이 훨씬 빨리 증가할 것으로 예상할 수 있습니다.

Linux kNFS Client compared with Oracle Direct NFS read latency

히스토그램은 데이터베이스 대기 시간에 대한 뛰어난 인사이트를 제공합니다. 다음 다이어그램은 가장 높은 동시성 데이터 요소(32개 스레드/스키마)에서 DNFS를 사용하는 동안 기록된 “db 파일 순차 읽기”의 관점에서 전체 뷰를 제공합니다. 다음 다이어그램에서 볼 수 있듯이 모든 읽기 작업의 47%는 512마이크로초와 1000마이크로초 사이에서 적용되었으며, 모든 읽기 작업의 90%는 2ms 미만의 대기 시간으로 처리되었습니다.

Linux kNFS Client compared with Oracle Direct NFS histograms

결론적으로, NFS에서 Oracle 데이터베이스 인스턴스의 성능을 향상시킬 때 DNFS가 필수인 것은 분명합니다.

단일 볼륨 성능 한도

이 섹션에서는 임의 I/O 및 순차 I/O를 사용하는 단일 볼륨의 성능 한도에 대해 설명합니다.

임의 I/O

DNFS는 8TB의 Azure NetApp Files 성능 할당량에서 제공하는 것보다 훨씬 더 많은 대역폭을 사용할 수 있습니다. Azure NetApp Files 볼륨 용량을 16TiB으로 늘리면 즉시 변경되며 볼륨 대역폭 양이 1024MiB/초에서 두 배인 2048MiB/초로 증가합니다.

다음 다이어그램은 데이터베이스 버퍼 적중률이 8%인 80% SELECT 및 20% UPDATE 워크로드의 구성을 보여 줍니다. SLOB는 단일 볼륨을 200,000 NFS I/O 요청/초까지 구동할 수 있었습니다. 각 작업의 크기가 8KiB라는 것을 감안할 때 테스트 중인 시스템은 ~200,000 IO 요청/초 또는 1600MiB/초를 제공할 수 있었습니다.

Oracle DNFS throughput

다음 읽기 대기 시간 곡선 다이어그램은 읽기 처리량이 증가함에 따라 1ms 선 아래에서는 대기 시간이 부드럽게 증가하다가 평균 읽기 대기 시간인 ~1.3ms에서 ~165,000 평균 읽기 IO 요청/초로 곡선의 무릎을 적중합니다. 이 값은 Azure 클라우드의 다른 모든 기술로는 거의 불가능한 놀라운 I/O 대비 대기 시간 값입니다.

Oracle DNFS latency curve

순차 I/O

다음 다이어그램에서 볼 수 있듯이 모든 I/O가 임의로 수행되는 것은 아닙니다. 예를 들어 RMAN 백업 또는 전체 테이블 검사의 경우 워크로드는 사용할 수 있는 모든 대역폭을 필요로 합니다. 앞에서 설명한 것과 동일한 구성을 사용하되 볼륨 크기를 32TiB로 조정한 다음 다이어그램은 단일 Oracle DB 인스턴스가 3,900MB/초의 처리량을 초과하여 32TB의 Azure NetApp Files 볼륨 성능 할당량(128MB/s * 32 = 4096MB/s)에 근접할 수 있음을 보여 줍니다.

Oracle DNFS I/O

요약하면, Azure NetApp Files는 Oracle 데이터베이스를 클라우드로 이동하는 데 도움이 됩니다. 데이터베이스에서 요청 시 성능을 제공합니다. 언제든지 볼륨 할당량의 크기를 동적으로 중단 없이 조정할 수 있습니다.

다음 단계