CPU 성능평가 (HW용량산정)

개념
실제 업무와 응용을 기반으로 수학적 방법을 사용하여 도입하고자 하는 시스템의 용량을 계산하는 활동 시스템 아키텍처와 응용 기반을 전제로 용량 요구사항과 성능을 결정하는 용량계획과 차이가 있으며, 일반적으로 시스템 규모 산정과 동일한 의미로 사용 CPU는 용량산정 방식이 다양하고 많은 비용을 차지하고 때문에 시스템 규모산정의 쟁점은 CPU 부분임, 메모리나 디스크는 도입 비용이 전체 비용에서 작아지는 추세고 CPU에 비해 객관화될 수 있음

I.  HW 용량산정의 개념 및 절차
    가. HW 용량산정의 개념

  • 실제 업무와 응용을 기반으로 수학적 방법을 사용하여 도입하고자 하는 시스템의 용량을 계산하는 활동
  • 시스템 아키텍처와 응용 기반을 전제로 용량 요구사항과 성능을 결정하는 용량계획과 차이가 있으며, 일반적으로 시스템 규모 산정과 동일한 의미로 사용
  • CPU는 용량산정 방식이 다양하고 많은 비용을 차지하고 때문에 시스템 규모산정의 쟁점은 CPU 부분임, 메모리나 디스크는 도입 비용이 전체 비용에서 작아지는 추세고 CPU에 비해 객관화될 수 있음

    나. 용량산정 절차

II.  시스템 성능평가 기준, TPC와 SPEC 설명
    가. 시스템 성능평가 기준의 개요
 

  • 일반적 컴퓨터 성능을 나타내는 단위로 MIPS(Million Instruction Per Second)를 사용했으나, 이는 원래 OS가 없는 HW 상에서 업무용 프로그램을 직접 실행하던 때의 지표로, 현재의 기준에 적정하지 않음
  • 오늘날 HW 벤더 및 SI업체 동향을 살펴보면 서버와 메인프레임은 TPC를, 워크스테이션은 SPEC 성능 평가를 많이 사용하고 있고, 공공기관의 경우 TPC 기준을 많이 적용하고 있음

    나. TPC(Transaction Procession Performance Council) 성능기준 설명

  • 1988년 설립해 세계 최고의 공신력을 갖는, HW 및 SW 트랜잭션 프로세싱과 데이터베이스 벤치마킹을 정의하기 위한 비영리 단체(독립기관)로 RDBMS의 OLTP성능을 평가하는 공신력 있는 지표 제공
  • - OLTP 시스템은 TPC-C를 기준으로 한 CPU 용량산정을 일반적으로 사용하며, 기본성능, 특정 업무 시스템의 처리성능, DB성능, 실시간 처리성능, 복합 데이터의 처리성능 등 5가지 측면에서 평가       
  • TPC-A,B,C,D,H,R,W 등의 벤치마킹 결과를 발표하였고, TPC-A,B,D는 폐지되었고 WEB/WAS와 OLTP 벤치마킹 기준은 TPC-W와 TPC-C임

기준

설명

TPC-A

- 가장 단순한 트랜잭션 처리 성능 평가용 벤치마크

- 네트워크를 포함한 기본성능을 평가

- 업무 내용은 ATM을 사용하고 있는 은행의 입출금 시스템임

TPC-B

- TPC-A와 유하사지만 네트워크를 포함하지 않음

TPC-C

- TPC-A의 단순, 비현실의 단점을 개선하여 다양한 크기와 복잡도를 가진 서로 다르면서도 연관성이 있는 DB 테이블에 수행할 수 있는 5개 트랜잭션 규정, 분당 트랜잭션으로 측정

- tpm(Transaction Per Minute)을 기본 단위로 사용하고 tpmC로 표현, 사용자 생각시간을 고려

TPC-D

- Decision Support 응용을 지원하기 위한 벤치마크

- A/B/C 보다 훨씬 복잡한 17개 쿼리 기반

TPC-H

- 의사결정을 지원하기 위한 벤치마크 성능평가 기준

- 비즈니스 지향 비정규적 병렬데이터 처리에 대한 성능평가로 실 업무 환경에 적용하기 어려움

TPC-R

- TPC-H와 유하사지만 정형화된 대용량 데이터 처리에 대한 질의로 구성

TPC-W

- 웹사이트로부터 제품을 찾고 구매하는 고객들을 시뮬레이션 하는 전자상거래 작업부하를 지정

- 웹/캐시/이미지/DB 서버로 구성된 환경을 고려 성능측정

- 시뮬레이트 된 전자상거래 작업부하 내에서 특정 전자상거래 서버들의 성능특성 결정 가능

    다. SPEC(Standard Performance Evaluation Corporation) 성능기준 설명

  • 1988년 HP, 썬마이크로시스템 등 주요 시스템 업체가 컨소시엄 형태로 참여하여 표준화된 벤치마킹을 개발하고 검토 결과를 공개하는 컴퓨터 산업 벤더들로 구성된 단체
  • SPEC의 벤치마킹 테스트 중 가장 권위 있는 벤치마킹 테스트는 CPU 성능테스트임.

기준

설명

SPECweb96

- 클라이언트 수는 서버를 포화상태로 이르게 구성, 서버 처리성능이 포화상태에 이르고 응답시간이 급격히 느려질 대까지 부하를 점차 증가시켜 최대 http operation 수 측정

- http get만을 테스트하여 post, cgi call, 보안기술 등을 고려하지 않고 http 1.1을 지원하지 않으며 WAN 환경에서의 테스트가 아닌 단점이 있음

SPECweb99

- SPECweb96의 발전, 웹 서버의 개수에 제한이 없으며 DBMS를 고려한 테스트가 아니며 서버와 클라이언트로 구성되어 있는 단순한 웹 환경을 테스트하기 위한 것

- 성능측정의 결과는 서버가 처리할 수 있는 최대 동시 연결 수

SPECjbb2000

- 단일서버 안에서 3 tier 환경을 이용하여 시뮬레이션 하는 벤치마킹 방법

- 하나의 JVM 내에서 테스트를 실행하며 측정 단위는 http ops/Sec를 사용

- 고객의 네트워크, 연동, disk I/O, DBMS에 대한 고려가 누락되는 단점이 있음

III.  CPU, 메모리, 디스크 용량산정 방법
    가. CPU 용량산정 방법

  • 시스템의 아키텍처와 작업부하의 특성을 OLTP와 WEB/WAS 등으로 구분하여 산정하는 것이 바람직함
  • 공공/민간, 프로젝트 특성에 따라 임의 산정할 수 있으나 국제적 성능기준을 고려, OLTP를 위해서는 TPC-C, WEB 서버는 SPECweb99, WAS 시스템은 SPECjbb2000을 적용하는 것이 바람직함(한국전산원)
  • tmpC는 다수의 측정항목을 사용하므로 구체적으로 업무분석이 이루어져야 하고, WEB/WAS 서버의 용량산정을 위한 OPS(Operation Per Second) 추정은 tpmC 추정 방식에 비해 상대적으로 간단하게 산정될 수 있으며, 업무 분석이 안된 경우에도 산정 가능

작업구분

성능평가기준

산정방법

OLTP

TPC-C

tpmC = 동시사용자 수 * 트랜잭션 처리 수 * 기본 tpmC 보정 * peak time 보정 * CPU 부하보정 * app복잡도 보정 * (사용자 복잡성 보정 * app 구조 보정 * app 부하보정) * 네트워크 보정 * 클러스터 보정 * 여유율 보정

WEB

SPECweb99

OPS = 동시사용자 수 * app interface 부하보정 * peak time 보정 * 시스템 여유율 * 사용자당 operation 수

WAS

SPECjbb2000

      나. 메모리 용량산정 방법

  • 메모리의 용량산정은 시스템의 용도와 구조를 바탕으로 산정되고, CPU에 비해 훨씬 단순하게 측정 가능

메모리 = {시스템영역 + 시스템관리자영역 + 사용자당필요메모리 * 사용자수 } * 버퍼캐쉬 * 클러스터 보정 * 여유율

      다. 디스크 용량산정 방법

  • 디스크 용량산정 시 가장 중요 고려요소는 데이터 백업정책으로, 이에 따라 디스크 요구량이 큰 차이를 가지므로 데이터 백업에 대한 적절한 정책 수립 필요
  • 시스템 디스크 = {시스템운영체제 + 응용프로그램 + SWAP영역} * 여유율
  • 데이터 디스크 = {데이터 영역 + 백업 영역} * RAID 영역 * 여유율

IV.  HW 용량산정 시 사전 고려사항
    가. 장기적으로 시스템을 단계적으로 구축하는가?

  • CPU 증설만으로 요구성능으로 업그레이드가 불가한 경우, 과부하가 발생하므로 장기적 계획 확인 필요

    나. 기종 별 각종 slot 수가 적정한가?

  • CPU, 메모리, 메인보드 등 주요자원의 확장 slot 수를 고려

    다. 장비 설치 요건이 맞는가?

  • 초기 시스템 도입 시 작은 모듈로 메모리를 구성하면 확장에 한계 존재

    라. 시스템 설치 전략에 맞는 용량인가?

  • 시스템 용량산정 수행 시 다양한 변수가 많이 존재하므로 철저한 검토가 필요

댓글