성능 검증 및 벤치마크 결과
변경 제안
PDF
이 성능 검증의 목표는 마크를 설정하지 않는 것입니다. 대신 이 문서에 설명된 구현 절차 및 모범 사례를 따르는 경우 퍼블릭 클라우드의 Oracle 데이터베이스 구축에 대해 유사한 성능 메트릭을 기대할 수 있습니다.
Swingbench SOE(Sales Order Entry) 모듈을 사용하여 OLTP 유형의 워크로드를 시뮬레이션했으며 NFS 프로토콜의 FSx 스토리지 볼륨이 있는 M5 EC2 인스턴스에 구축된 Oracle 데이터베이스에 워크로드를 적용했습니다. 기본 Swingbench SOE I/O 프로필은 80/20 읽기/쓰기 분할에 근접하며, 이는 실제 OLTP Oracle 워크로드 프로필과 가깝습니다.
작업 부하는 판매 주문 입력, 검색, 재고 쿼리 등을 수행하는 클라이언트 측의 동시 사용자 수를 늘려 증가합니다. 테스트한 숫자는 8, 16, 32, 64 및 128명의 동시 사용자였습니다. 이 알고리즘은 서버 측에서 상당한 트랜잭션 볼륨을 푸시하고 Oracle 서버 제한을 테스트하기 위해 Swingbench를 사용합니다. 128명의 동시 사용자가 EC2 인스턴스 CPU 활용률은 약 80-90%에 달하는 것으로 확인되었습니다.
다음 섹션에서는 설정 및 테스트 결과에 대한 세부 정보를 제공합니다.
테스트 환경 설정
컴퓨팅
우리는 8vCPU, 32G RAM, 10Gps 네트워크 대역폭을 갖춘 EC2 M5 인스턴스를 구축했습니다.
FSX 저장소
다음과 같이 세 개의 데이터베이스 볼륨을 생성하고 EC2 인스턴스에 NFS를 사용하여 볼륨을 마운트했습니다.
-
/u01 - Oracle 바이너리
-
/u02 - Oracle 데이터 파일, 제어 파일
-
/u03 - Oracle 로그 파일, 제어 파일
이중화를 위해 중요한 제어 파일의 복사본 2개를 보관했습니다.
FSx 파일 시스템은 80,000 IOPS 용량과 2GiBps 입출력 처리량으로 구성됩니다.
Oracle 구성
Oracle 버전 19c와 RU 패치 19.8을 설치했습니다. 서버에서 dNFS가 설정되었습니다.
이 데이터베이스는 PDB 3개가 포함된 컨테이너형 데이터베이스로 배포되었습니다. 성능 테스트에 하나의 PDB 인스턴스를 사용했습니다. 다음 그림에서는 NFS 마운트 지점의 Oracle 스토리지 사이징을 보여 줍니다.
Swingbench 구성
Windows 호스트에 8vCPU 및 32G RAM이 있는 Swingbench 2.6(최신 버전)을 구축했습니다. SOE PLSQL 테스트 모듈 버전 2를 벤치마크에 사용했습니다. 기본 로드 프로필은 80/20 읽기/쓰기 비율을 제공하여 실제 OLTP 트랜잭션 워크로드를 시뮬레이션합니다.
우리가 사용한 스키마 척도 계수는 50으로, 초기 데이터 로드 크기는 160G이고 임시 공간 할당은 30G입니다. 이러한 확장 요인으로 SOE 스키마는 온라인 주문 처리 시뮬레이션을 위해 1000개의 물류창고와 5천만 명의 고객을 제공했습니다.
다음 스크린 샷에서는 Swingbench Windows UI의 워크로드 프로필과 일반적인 트랜잭션 실행 메트릭을 보여 줍니다.
이 그래프에서 알 수 있듯이 테스트 실행 동안 트랜잭션 수준은 동일한 수준으로 유지되었습니다.
테스트 결과 분석
각 테스트 실행에 대한 Swingbench 결과를 캡처하고 성능 분석을 위한 해당 Oracle AWR 보고서를 확보했습니다.
최종 사용자 측에서 트랜잭션 볼륨 및 사용자 응답 시간과 같은 주요 메트릭을 살펴보았습니다. 두 메트릭 모두 시스템에 로그인하는 동시 사용자 수와 사용자가 주문을 입력한 후 트랜잭션을 완료하고 응답을 다시 받을 수 있는 속도를 기준으로 영업 주문 입력 시스템에서 사용자가 실행할 수 있는 트랜잭션 수를 보여 줍니다.
Oracle 서버 엔드에서 Oracle AWR 보고서를 구문 분석하여 사용자 트랜잭션 속도를 늦출 수 있는 주요 대기 이벤트를 파악했습니다. 상위 10개 Oracle 대기 이벤트에는 Swingbench 시뮬레이션 트랜잭션 테스트 실행 중에 Oracle 서버가 대부분 I/O로 바인딩되어 있으며, 데이터베이스 시간의 50%~60%는 Db 파일 순차 읽기에 소비됩니다. 로그 파일 동기화도 트랜잭션 커밋이 로그 I/O를 버퍼 캐시에서 디스크의 로그 파일로 플러시하도록 하는 Oracle 로깅 프로세스가 데이터베이스 시간 비율 수준의 더 작은 요소이기 때문에 중요한 요소입니다.
트랜잭션 실행 중 동시 사용자 수에 대한 사용자 트랜잭션 볼륨, 사용자 응답 시간 및 Oracle 상위 대기 이벤트를 차트로 작성하였습니다. 결과는 다음과 같습니다.
이러한 결과는 지속적으로 낮은 I/O 지연 시간과 사용자 응답 시간을 유지하면서 동시 사용자 수가 증가하는 사용자 트랜잭션 볼륨을 꾸준히 늘릴 수 있다는 것을 나타냅니다. 이는 Oracle 애플리케이션에 적합한 성능입니다.
128명의 동시 사용자에 도달하면 I/O 지연 시간과 사용자 응답 시간이 다소 증가하기 시작했습니다. 다음 다이어그램과 같이 EC2 인스턴스가 전체 서버 용량에 거의 도달하므로 이 작업이 필요합니다.
마찬가지로 다음 다이어그램은 해당 시점의 사용자 트랜잭션 볼륨을 충족하는 동시에 해당 FSx IOPS 및 처리량을 보여 줍니다.
Oracle 서버 EC2 인스턴스가 제한 요소가 되었을 때 IOPS 또는 처리량으로 프로비저닝된 FSx 스토리지 용량에 도달하지 않았습니다. 따라서 섹션에 나와 있는 것처럼 사용자 애플리케이션 레벨 트랜잭션 볼륨에 따라 컴퓨팅 및 스토리지의 크기를 적절하게 지정해야 합니다 "Oracle 데이터베이스 구축에 고려해야 할 요인"