bonnie++
페이지 정보
작성자 조희승 댓글 0건 조회 216,710회 작성일 12-08-17 15:08본문
fs benchmark
Benchmarking Tools 분석 보고서
Benchmarking Tools 분석 보고서
목 차 (Table of Contents)
1. 문서 개요 (PREFACE) 4
2. 전체 설명 (GENERAL DESCRIPTION) 5
2.1. 벤치마크 개요 (Benchmark Summary) 5
2.2. 문서 범위 (Documentation Scope) 5
3. 벤치마크 분류 (DIFFERENT TYPES OF BENCHMARKS) 6
4. 벤치마크 예(EXAMPLE OF BENCHMARKS) 7
4.1. 파일 시스템 레벨 벤치마크(File System Level Benchmarks) 7
4.1.1. Bonnie, Bonnie++ 7
4.1.2. IOZONE 7
4.1.3. Postmark 7
4.1.4. IOMETER 8
4.1.5. WINBENCH 8
4.1.6. IOSTONE 8
4.1.7. LADDIS 8
4.2. 블록 디바이스 레벨 벤치마크(Block Device Level Benchmarks) 9
4.2.1. CLYDE 9
4.2.2. HD Tach 9
4.2.3. SPEK 9
4.3. 디바이스 레벨 벤치마크(Device Level Benchmarks) 9
4.3.1. IPEAK SPT-V30 9
4.3.2. QBENCH 10
5. 벤치마크 성능 비교 (COMPARISON OF BENCHMARK CAPABILITIES) 11
6. BONNIE++ 12
6.1. 테스트 세부설명(Test Details) 16
6.1.1. 파일 입출력 테스트(File I/O Test) 16
6.1.2. 파일 생성 테스트(File Creation Test) 17
6.2. Bonnie++ 실행방법 17
6.3. Bonnie++ 실행 예 17
6.4. Bonnie++ 사용 가능한 옵션 17
7. 결론 (CONCLUSION) 22
1. 문서 개요 (Preface)
? 문서 목적 (Purpose)
본 문서는 현재 사용되고 있는 파일 시스템, 디바이스 및 블록 디바이스 레벨의 벤치마크에 대해 조사하고 분석하여 기술하는 것을 목적으로 한다.
? 문서 목적 (Purpose)
본 문서는 현재 사용되고 있는 파일 시스템, 디바이스 및 블록 디바이스 레벨의 벤치마크에 대해 조사하고 분석하여 기술하는 것을 목적으로 한다.
? 문서 범위 (Scope)
각 벤치마크의 특징과 사용방법, 장점과 단점을 기술한다.
? 참고 문헌 (References)
[1] Diane Tang, “Benchmarking Filesystems”
[2] http://www.textuality.com/bonnie/
[3] http://www.iozone.org/
[4] Jeffrey Katcher, “PostMark: A New File System Benchmark”
[5] http://www.iometer.org/
[6] Arvin Park, Jeffery C.Becker, Richard J.Lipton, “IOStone : a synthetic file system benchmark”
[7] http://tdec.free.fr/clyde/clyde.en.html
[8] http://www.simplisoftware.com/Public/index.php?request=HdTach
[9] Ming Zhang, Qing Yang and Xubin He, “SPEK : A strorage Performance Evaluation Kernel Module for Block Level Storage Systems”
[10] http://storagereview.com/index.html
[1] Diane Tang, “Benchmarking Filesystems”
[2] http://www.textuality.com/bonnie/
[3] http://www.iozone.org/
[4] Jeffrey Katcher, “PostMark: A New File System Benchmark”
[5] http://www.iometer.org/
[6] Arvin Park, Jeffery C.Becker, Richard J.Lipton, “IOStone : a synthetic file system benchmark”
[7] http://tdec.free.fr/clyde/clyde.en.html
[8] http://www.simplisoftware.com/Public/index.php?request=HdTach
[9] Ming Zhang, Qing Yang and Xubin He, “SPEK : A strorage Performance Evaluation Kernel Module for Block Level Storage Systems”
[10] http://storagereview.com/index.html
2. 전체 설명 (General Description)
2.1. 벤치마크 개요 (Benchmark Summary)
벤치마크는 성능 측정 과정을 포함하는 일련의 프로그램으로 서로 다른 시스템을 비교하고, 성능향상을 위해 개선의 여지가 있는 부분을 찾아내는 데 사용될 수 있다. 즉, 시스템 디자이너 들은 기존의 시스템을 이해하고 개선하기 위해, 사용자들은 어떤 파일 시스템을 이용하는 게 가장 효과적일 지를 결정하기 위해, 벤치마크를 이용한다.
2.2. 문서 범위 (Documentation Scope)
이 문서는 각 벤치마크의 특징에 대해 간단히 살펴보고, 플래시 메모리의 성능 측정을 위해 가장 적합한 벤치마크를 선정하여 그 이유와 간단한 사용방법에 대해 기술한다.
3. 벤치마크 분류 (Different Types Of Benchmarks)
벤치마크는 여러 가지 방법으로 분류할 수 있는데, 기본적으로 다음과 같이 두 가지 방법이 사용된다. 벤치마크를 구성하는 일련의 동작(operation)들의 단위에 따라 애플리케이션(Application) 벤치마크와 합성(Synthetic) 벤치마크로, 시스템의 전체 성능을 측정하는지, 특정 부분을 나누어 측정하는 지에 따라 매크로 벤치마크와 마이크로 벤치마크로 분류할 수 있다.
애플리케이션 벤치마크는 사용자가 직접 사용하는, 예를 들어 C 컴파일러, 스프레드시트와 같은 일련의 프로그램으로 구성된다. 합성 벤치마크는 측정을 필요로 하는 시스템이 수행하는 작업의 특성을 나타낼 수 있도록, 사용자가 조정할 수 있는 여러 가지 기본적인 동작으로 이루어진다. 합성 벤치마크의 경우에는 상황에 따라 여러 가지 다른 작업환경을 구성하여 좀 더 유연하게 테스트를 할 수 있다는 장점이 있으나, 실제 애플리케이션 실행 시 애플리케이션 벤치마크와 같이 실제 작업환경을 테스트하는 것은 아니기 때문에, 예상했던 것과 다른 성능을 보일 수도 있다는 단점이 있다.
매크로 벤치마크는 대상 시스템 전체의 성능을 측정하고, 마이크로 벤치마크는 사용자가 필요로 하는 시스템의 일부분만의 성능을 측정한다. 마이크로 벤치마크의 경우는 측정 결과가 왜곡되어 이용될 수도 있다는 문제점을 가지고 있다. 즉, 파일 시스템의 전체 성능을 결정하는 여러 가지 요소 중, 해당 파일 시스템이 뛰어난 성능을 보이는 요소만을 부각시켜 사용자를 현혹시킬 수도 있다.
이러한 이유들로 시스템 디자이너의 입장으로는 합성 벤치마크를 이용하여 좀 더 유연하게 성능 개선의 여지를 찾아보는 편이 적합하고, 사용자의 입장에서는 매크로, 애플리케이션 벤치마크를 이용하여 전체적인 성능을 객관적으로 평가하는 편이 낫다.
이 문서는 각 벤치마크의 특징에 대해 간단히 살펴보고, 플래시 메모리의 성능 측정을 위해 가장 적합한 벤치마크를 선정하여 그 이유와 간단한 사용방법에 대해 기술한다.
3. 벤치마크 분류 (Different Types Of Benchmarks)
벤치마크는 여러 가지 방법으로 분류할 수 있는데, 기본적으로 다음과 같이 두 가지 방법이 사용된다. 벤치마크를 구성하는 일련의 동작(operation)들의 단위에 따라 애플리케이션(Application) 벤치마크와 합성(Synthetic) 벤치마크로, 시스템의 전체 성능을 측정하는지, 특정 부분을 나누어 측정하는 지에 따라 매크로 벤치마크와 마이크로 벤치마크로 분류할 수 있다.
애플리케이션 벤치마크는 사용자가 직접 사용하는, 예를 들어 C 컴파일러, 스프레드시트와 같은 일련의 프로그램으로 구성된다. 합성 벤치마크는 측정을 필요로 하는 시스템이 수행하는 작업의 특성을 나타낼 수 있도록, 사용자가 조정할 수 있는 여러 가지 기본적인 동작으로 이루어진다. 합성 벤치마크의 경우에는 상황에 따라 여러 가지 다른 작업환경을 구성하여 좀 더 유연하게 테스트를 할 수 있다는 장점이 있으나, 실제 애플리케이션 실행 시 애플리케이션 벤치마크와 같이 실제 작업환경을 테스트하는 것은 아니기 때문에, 예상했던 것과 다른 성능을 보일 수도 있다는 단점이 있다.
매크로 벤치마크는 대상 시스템 전체의 성능을 측정하고, 마이크로 벤치마크는 사용자가 필요로 하는 시스템의 일부분만의 성능을 측정한다. 마이크로 벤치마크의 경우는 측정 결과가 왜곡되어 이용될 수도 있다는 문제점을 가지고 있다. 즉, 파일 시스템의 전체 성능을 결정하는 여러 가지 요소 중, 해당 파일 시스템이 뛰어난 성능을 보이는 요소만을 부각시켜 사용자를 현혹시킬 수도 있다.
이러한 이유들로 시스템 디자이너의 입장으로는 합성 벤치마크를 이용하여 좀 더 유연하게 성능 개선의 여지를 찾아보는 편이 적합하고, 사용자의 입장에서는 매크로, 애플리케이션 벤치마크를 이용하여 전체적인 성능을 객관적으로 평가하는 편이 낫다.
매크로 마이크로 특징
애플리케이션 애플리케이션
매크로 벤치마크 애플리케이션
마이크로 벤치마크 실제 상황에서와 거의 일치하는 성능 측정 결과를 얻음
합성 합성 매크로
벤치마크 합성 마이크로
벤치마크 유연한 테스트환경 구성이 가능
특징 시스템 전체의
성능 측정 시스템 일부분의
성능 측정
표 1 벤치마크 분류
4. 벤치마크 예(Example Of Benchmarks)
현재 사용되고 있는 벤치마크를 앞에서 소개한 분류방법과 함께 살펴보고, 각각의 특징을 자세히 알아본다.
4.1. 파일 시스템 레벨 벤치마크(File System Level Benchmarks)
4.1.1. Bonnie, Bonnie++
Bonnie는 합성 마이크로 벤치마크로 파일 I/O 동작에 대한 성능을 측정하기 위해 고안되었다. 기본적인 데이터베이스 애플리케이션이 수행하는 작업에 대한 성능을 예측하기 위해, 2Gbytes 이하의 파일에 순차적인(Sequential) 입력(Input)/출력(Output), 랜덤(Random) 탐색(seek)/입력/출력을 수행하여, 1초당 처리한 작업량과, CPU 점유율을 보고한다. 이 때, 작업량은 많을수록, CPU 점유율은 낮을수록 더 나은 성능을 보인다고 할 수 있다.
Bonnie++은 Bonnie에 기초하였으나, 2Gbytes 이상 크기의 파일들에 대해서도 테스트를 할 수 있다는 점이 다르다. Bonnie++은 크게 두 가지 테스트를 행하는데, Bonnie에서 수행하는 기본적인 I/O 처리량 측정이 한 가지이고, Squid나 INN과 같은 서버의 동작을 모방하기 위해 작은 크기의 파일들을 여러 개 생성하고, 읽고, 지우는 작업을 반복하여 성능을 측정하는 것이 다른 한 가지이다. Bonnie++에서는 모든 I/O 동작에 있어서 싱크(sync)를 필요로 하는 메일 서버 등의 성능을 고려하기 위해서, 쓰기 시 버퍼링을 켜고 끌 수 있는 옵션도 포함하고 있다.
Linux, Solaris 환경에서 사용 가능하다.
4.1.2. IOZONE
Iozone은 합성 마이크로 벤치마크로 Linux, Windows 그리고 NFS Client 환경에서의 I/O 동작의 성능을 측정할 수 있다. Iozone은 시간에 따라, 상황에 따라 변하는 수많은 작업 환경들에 대한 성능을 예측할 수 있도록, 다른 벤치마크에 비해 훨씬 다양한 동작에 대한 I/O 성능을 측정한다. 읽기(Read), 쓰기(write), 다시 읽기(re-read), 다시 쓰기(re-write), 거꾸로 읽기(read backwards), 건너뛰고 읽기(read strided), 버퍼링된 읽기(fread), 버퍼링된 쓰기(fwrite), 랜덤 읽기/쓰기(random read/write), 비동기적 읽기/쓰기(aio_read/aio_write), mmap에 대한 성능 측정이 가능하다. 물론, 이 중에서 우리가 필요로 하는 동작만 골라서 이용할 수 있는데, 만약 읽기/쓰기에만 관심이 있다면, ?i 0 ?i 1 옵션(-i 는 어떤 테스트를 행할 것인지 구체적으로 명시해준다는 의미, 예를 들어 0 = 쓰기/다시 쓰기, 1= 읽기/다시 읽기 이다). ?R 옵션을 사용하면 부수적으로 엑셀 버전의 보고서도 얻을 수 있다.
4.1.3. Postmark
인터넷의 빠른 발전으로, 이메일, 넷뉴스 그리고 웹 기반 커머스를 관리하는 파일 서버들이 많아졌고, 이 서버들은 오래도록 보관하지는 않는, 작은 용량의 파일들을 많이 보관하고 있다. 기존의 벤치마크는 대부분 장기간 보관되는 대용량의 파일 관리에 대한 성능을 고려하고 있는데 반해, Postmark는 이러한 인터넷 소프트웨어에서 사용되는 파일들에 대한 성능을 측정하는 데 사용되는 합성 마이크로 벤치마크다 .
Postmark는 우선, 주어진 범위 내의 크기를 가지는 다량의 텍스트 파일들을 생성한 후, 랜덤하게 파일을 골라 그 파일에 대해 삭제, 읽기, 추가(append) 등의 작업을 수행한다. 이 때, 수행에 걸린 시간과 기타 정보들로부터 성능을 측정할 수 있다.
Solaris, Microsoft Win32 환경에서 사용 가능하다.
4.1.4. IOMETER
IOMeter는 단일시스템 또는 다중시스템에서의 I/O 동작을 구성하고 측정할 수 있는 합성 매크로 벤치마크로, 작업부하 생성 프로그램(workload generator)인 ‘Dynamo’와 제어 프로그램인 ‘IOMeter’로 구성되어 있다.
Dynamo는 Linux, Solaris, Windows 플랫폼에서 모두 지원이 되지만, IOMeter는 Windows에서만 지원되는 GUI이다.
IOMeter는 디스크 컨트롤러와 네트워크 컨트롤러의 성능, 버스의 대역폭과 전송대기시간, 네트워크 처리량, 공유 버스의 성능, 시스템 레벨 하드 드라이브 성능과 네트워크 성능을 측정하는 데 이용할 수 있다.
IOMeter는 단일 사용자 시스템에서의 성능 측정보다는 다중 사용자 시스템에서의 성능에 더욱 적합하다. 실제 단일 사용자 시스템에서는 높은 집약성으로 디스크 탐색 시간에 드는 시간이 무척이나 적어서, 버퍼와 호스트 간 전송속도에 큰 영향을 받게 된다. 그런데, IOMeter는 집약성의 영향력을 설정해주는 옵션이 제공되지 않아, 단일 사용자 시스템의 성능 측정에서도 디스크 전체를 사용하여 읽기, 쓰기를 해 주기 때문에, 다중 사용자 시스템에서의 성능 측정보다 정확도가 떨어진다고 할 수 있다.
4.1.5. WINBENCH
Winbench 패키지의 일부인 Disk WinMarks99는 미리 추출된 애플리케이션 레벨의 실제 디스크 액세스 패턴을 이용하여 읽기 성능을 측정하는 합성 마이크로 벤치마크다. 반복 사용이 가능한 벤치마크로 제공된 액세스 패턴에 대해 무척 정확한 측정 결과를 보여준다.
하지만, 쓰기 액세스 시간을 측정하는 도구를 제공하고 있지 않고, 읽기 액세스 시간에 사용되는 액세스 패턴이 최신 OS가 아닌, 구식 버전의 OS에서 동작하는 유틸리티(Utility)에서 추출해낸 것으로 현재 OS에서의 성능과 약간 차이가 있을 수 있다. 그리고, 패턴을 추출하는 단계에서, 그리고 측정을 위해 그 패턴을 다시 실행시키는 단계에서, 이렇게 두 번씩 시스템의 구성 ? CPU, RAM, OS, 캐시 그리고 파일 시스템 ? 에 이중으로 영향을 받기 때문에, 역시 측정 결과가 조금 더 달라질 수 있다.
4.1.6. IOSTONE
IOStone은 합성 매크로 벤치마크로 파일 시스템 태스크에 대한 디스크성능, CPU성능, 그리고 디스크 캐시성능 등, 파일 시스템에 대한 전반적인 성능을 측정하는 벤치마크다.
우선 다양한 크기의 파일의 집합을 생성한다. 집약성을 고려하기 위해, 파일들을 그룹별로 나눈 후 랜덤하게 선택된 파일에 대해 2:1의 비율로 읽기, 쓰기를 수행한다. 이를 통해, 최대 대역폭, 랜덤 액세스 시간뿐만 아니라 디스크 캐시의 성능까지도 고려할 수 있다.
하지만 파일 시스템 성능에 비해 전체 I/O 시스템 로드에 별로 영향을 미치지 않는다고 판단되는 페이징 성능은 고려하지 않고 있다. 그리고, 처음에 생성하는 전체 파일 시스템의 크기가 5Mbytes 이하로 제한되어 있기 때문에, 디스크 캐시가 성능향상에 지나치게 큰 역할을 하고 있다고 생각될 수도 있지만, 사실상 파일 시스템에 행해지는 작업들은 집약성이 크기 때문에 별 문제는 없다.
Unix환경에서 사용 가능하다.
4.1.7. LADDIS
SPEC SFS 1(0.97 LADDIS)는 시스템 레벨 파일 서버(SFS) 벤치마크 모음(suite)을 이루는 NFS 파일 서버에 대한 합성 마이크로 벤치마크로, NHFSStone을 개선한 프로그램이다. 이 프로그램은 여러 클라이언트에서 NFS 서버에 점점 더 많은 요청(request)을 보내어, 얼마만큼의 요청까지 처리할 수 있는지를 측정한다. 즉, 처리량(throughput)이나 응답 시간이 사용자가 정한 기준보다 떨어지는 시점의, NFS 동작 처리량과 응답 시간을 보여준다. NFS 동작 처리량을 통해서 이 서버가 얼마나 많은 사용자에게 서비스를 제공할 수 있는지를 알 수 있고, 응답 시간으로 서버가 얼마나 빠르게 동작하는지를 알 수 있다.
NFS 서버에만 사용된다는 단점이 있다.
4.2. 블록 디바이스 레벨 벤치마크(Block Device Level Benchmarks)
4.2.1. CLYDE
CLYDE는 GNU/Linux용 합성 마이크로 벤치마크로 순차적, 랜덤, 캐시 이렇게 세 가지 패턴으로 읽기/쓰기 테스트를 수행한다. (캐시 테스트는 디스크 캐시에서만 읽기/쓰기를 수행하는 테스트로 SCSI 버스가 사용된다)
이 때 가능한 한 실제 작업환경과 유사한 조건에서 테스트를 할 수 있도록, 많은 수의 매개변수를 자유롭게 설정할 수 있다.
4.2.2. HD Tach
HD Tach는 합성 마이크로 벤치마크로 하드 드라이브, 이동식 드라이브 (ZIP/JAZZ), 플래시 디바이스, 그리고 RAID와 같은 랜덤 액세스 읽기/쓰기 저장장치에 대한 Windows용 벤치마크다.
선택한 장치의 순차적 읽기/쓰기 속도, 랜덤 액세스 속도, 버퍼와 호스트간 처리 속도 그리고 CPU 활용도를 분석하여 그래프의 형태로 보여준다.
읽기, 쓰기 액세스 시간에 대한 비교적 정확한 성능 측정 결과를 보이지만, 측정 장치의 일부 섹터에서만 측정한 결과값을 얻기 때문에, RAID 같은 하드웨어 구성의 효과는 제대로 나타내지 못하는 단점을 가지고 있다.
4.2.3. SPEK
SPEK은 합성 마이크로 벤치마크로 순차적 읽기/쓰기, 랜덤 읽기/쓰기를 수행하여 이 때의 처리량과 응답 시간을 보고한다. 이 때 블록 크기, 각 트랜잭션의 수행 횟수, 읽기/쓰기의 수행 비율, 순차적/랜덤의 수행 비율을 사용자가 매개변수로 넘겨주어, 유연한 테스트를 할 수 있게 한다.
아직 상용화될 프로그램이 개발된 것은 아니고, 기능성과 효율성을 증명하기 위한 Linux 환경의 데모 버전만 구현된 상태이다.
4.3. 디바이스 레벨 벤치마크(Device Level Benchmarks)
4.3.1. IPEAK SPT-V30
Intel에서 개발한 SPT(Storage Performance Tool)은 디스크의 성능을 측정하고 분석하기 위한 합성 마이크로 벤치마크로 다음과 같은 5개의 유틸리티로 구성되어 있다.
애플리케이션 애플리케이션
매크로 벤치마크 애플리케이션
마이크로 벤치마크 실제 상황에서와 거의 일치하는 성능 측정 결과를 얻음
합성 합성 매크로
벤치마크 합성 마이크로
벤치마크 유연한 테스트환경 구성이 가능
특징 시스템 전체의
성능 측정 시스템 일부분의
성능 측정
표 1 벤치마크 분류
4. 벤치마크 예(Example Of Benchmarks)
현재 사용되고 있는 벤치마크를 앞에서 소개한 분류방법과 함께 살펴보고, 각각의 특징을 자세히 알아본다.
4.1. 파일 시스템 레벨 벤치마크(File System Level Benchmarks)
4.1.1. Bonnie, Bonnie++
Bonnie는 합성 마이크로 벤치마크로 파일 I/O 동작에 대한 성능을 측정하기 위해 고안되었다. 기본적인 데이터베이스 애플리케이션이 수행하는 작업에 대한 성능을 예측하기 위해, 2Gbytes 이하의 파일에 순차적인(Sequential) 입력(Input)/출력(Output), 랜덤(Random) 탐색(seek)/입력/출력을 수행하여, 1초당 처리한 작업량과, CPU 점유율을 보고한다. 이 때, 작업량은 많을수록, CPU 점유율은 낮을수록 더 나은 성능을 보인다고 할 수 있다.
Bonnie++은 Bonnie에 기초하였으나, 2Gbytes 이상 크기의 파일들에 대해서도 테스트를 할 수 있다는 점이 다르다. Bonnie++은 크게 두 가지 테스트를 행하는데, Bonnie에서 수행하는 기본적인 I/O 처리량 측정이 한 가지이고, Squid나 INN과 같은 서버의 동작을 모방하기 위해 작은 크기의 파일들을 여러 개 생성하고, 읽고, 지우는 작업을 반복하여 성능을 측정하는 것이 다른 한 가지이다. Bonnie++에서는 모든 I/O 동작에 있어서 싱크(sync)를 필요로 하는 메일 서버 등의 성능을 고려하기 위해서, 쓰기 시 버퍼링을 켜고 끌 수 있는 옵션도 포함하고 있다.
Linux, Solaris 환경에서 사용 가능하다.
4.1.2. IOZONE
Iozone은 합성 마이크로 벤치마크로 Linux, Windows 그리고 NFS Client 환경에서의 I/O 동작의 성능을 측정할 수 있다. Iozone은 시간에 따라, 상황에 따라 변하는 수많은 작업 환경들에 대한 성능을 예측할 수 있도록, 다른 벤치마크에 비해 훨씬 다양한 동작에 대한 I/O 성능을 측정한다. 읽기(Read), 쓰기(write), 다시 읽기(re-read), 다시 쓰기(re-write), 거꾸로 읽기(read backwards), 건너뛰고 읽기(read strided), 버퍼링된 읽기(fread), 버퍼링된 쓰기(fwrite), 랜덤 읽기/쓰기(random read/write), 비동기적 읽기/쓰기(aio_read/aio_write), mmap에 대한 성능 측정이 가능하다. 물론, 이 중에서 우리가 필요로 하는 동작만 골라서 이용할 수 있는데, 만약 읽기/쓰기에만 관심이 있다면, ?i 0 ?i 1 옵션(-i 는 어떤 테스트를 행할 것인지 구체적으로 명시해준다는 의미, 예를 들어 0 = 쓰기/다시 쓰기, 1= 읽기/다시 읽기 이다). ?R 옵션을 사용하면 부수적으로 엑셀 버전의 보고서도 얻을 수 있다.
4.1.3. Postmark
인터넷의 빠른 발전으로, 이메일, 넷뉴스 그리고 웹 기반 커머스를 관리하는 파일 서버들이 많아졌고, 이 서버들은 오래도록 보관하지는 않는, 작은 용량의 파일들을 많이 보관하고 있다. 기존의 벤치마크는 대부분 장기간 보관되는 대용량의 파일 관리에 대한 성능을 고려하고 있는데 반해, Postmark는 이러한 인터넷 소프트웨어에서 사용되는 파일들에 대한 성능을 측정하는 데 사용되는 합성 마이크로 벤치마크다 .
Postmark는 우선, 주어진 범위 내의 크기를 가지는 다량의 텍스트 파일들을 생성한 후, 랜덤하게 파일을 골라 그 파일에 대해 삭제, 읽기, 추가(append) 등의 작업을 수행한다. 이 때, 수행에 걸린 시간과 기타 정보들로부터 성능을 측정할 수 있다.
Solaris, Microsoft Win32 환경에서 사용 가능하다.
4.1.4. IOMETER
IOMeter는 단일시스템 또는 다중시스템에서의 I/O 동작을 구성하고 측정할 수 있는 합성 매크로 벤치마크로, 작업부하 생성 프로그램(workload generator)인 ‘Dynamo’와 제어 프로그램인 ‘IOMeter’로 구성되어 있다.
Dynamo는 Linux, Solaris, Windows 플랫폼에서 모두 지원이 되지만, IOMeter는 Windows에서만 지원되는 GUI이다.
IOMeter는 디스크 컨트롤러와 네트워크 컨트롤러의 성능, 버스의 대역폭과 전송대기시간, 네트워크 처리량, 공유 버스의 성능, 시스템 레벨 하드 드라이브 성능과 네트워크 성능을 측정하는 데 이용할 수 있다.
IOMeter는 단일 사용자 시스템에서의 성능 측정보다는 다중 사용자 시스템에서의 성능에 더욱 적합하다. 실제 단일 사용자 시스템에서는 높은 집약성으로 디스크 탐색 시간에 드는 시간이 무척이나 적어서, 버퍼와 호스트 간 전송속도에 큰 영향을 받게 된다. 그런데, IOMeter는 집약성의 영향력을 설정해주는 옵션이 제공되지 않아, 단일 사용자 시스템의 성능 측정에서도 디스크 전체를 사용하여 읽기, 쓰기를 해 주기 때문에, 다중 사용자 시스템에서의 성능 측정보다 정확도가 떨어진다고 할 수 있다.
4.1.5. WINBENCH
Winbench 패키지의 일부인 Disk WinMarks99는 미리 추출된 애플리케이션 레벨의 실제 디스크 액세스 패턴을 이용하여 읽기 성능을 측정하는 합성 마이크로 벤치마크다. 반복 사용이 가능한 벤치마크로 제공된 액세스 패턴에 대해 무척 정확한 측정 결과를 보여준다.
하지만, 쓰기 액세스 시간을 측정하는 도구를 제공하고 있지 않고, 읽기 액세스 시간에 사용되는 액세스 패턴이 최신 OS가 아닌, 구식 버전의 OS에서 동작하는 유틸리티(Utility)에서 추출해낸 것으로 현재 OS에서의 성능과 약간 차이가 있을 수 있다. 그리고, 패턴을 추출하는 단계에서, 그리고 측정을 위해 그 패턴을 다시 실행시키는 단계에서, 이렇게 두 번씩 시스템의 구성 ? CPU, RAM, OS, 캐시 그리고 파일 시스템 ? 에 이중으로 영향을 받기 때문에, 역시 측정 결과가 조금 더 달라질 수 있다.
4.1.6. IOSTONE
IOStone은 합성 매크로 벤치마크로 파일 시스템 태스크에 대한 디스크성능, CPU성능, 그리고 디스크 캐시성능 등, 파일 시스템에 대한 전반적인 성능을 측정하는 벤치마크다.
우선 다양한 크기의 파일의 집합을 생성한다. 집약성을 고려하기 위해, 파일들을 그룹별로 나눈 후 랜덤하게 선택된 파일에 대해 2:1의 비율로 읽기, 쓰기를 수행한다. 이를 통해, 최대 대역폭, 랜덤 액세스 시간뿐만 아니라 디스크 캐시의 성능까지도 고려할 수 있다.
하지만 파일 시스템 성능에 비해 전체 I/O 시스템 로드에 별로 영향을 미치지 않는다고 판단되는 페이징 성능은 고려하지 않고 있다. 그리고, 처음에 생성하는 전체 파일 시스템의 크기가 5Mbytes 이하로 제한되어 있기 때문에, 디스크 캐시가 성능향상에 지나치게 큰 역할을 하고 있다고 생각될 수도 있지만, 사실상 파일 시스템에 행해지는 작업들은 집약성이 크기 때문에 별 문제는 없다.
Unix환경에서 사용 가능하다.
4.1.7. LADDIS
SPEC SFS 1(0.97 LADDIS)는 시스템 레벨 파일 서버(SFS) 벤치마크 모음(suite)을 이루는 NFS 파일 서버에 대한 합성 마이크로 벤치마크로, NHFSStone을 개선한 프로그램이다. 이 프로그램은 여러 클라이언트에서 NFS 서버에 점점 더 많은 요청(request)을 보내어, 얼마만큼의 요청까지 처리할 수 있는지를 측정한다. 즉, 처리량(throughput)이나 응답 시간이 사용자가 정한 기준보다 떨어지는 시점의, NFS 동작 처리량과 응답 시간을 보여준다. NFS 동작 처리량을 통해서 이 서버가 얼마나 많은 사용자에게 서비스를 제공할 수 있는지를 알 수 있고, 응답 시간으로 서버가 얼마나 빠르게 동작하는지를 알 수 있다.
NFS 서버에만 사용된다는 단점이 있다.
4.2. 블록 디바이스 레벨 벤치마크(Block Device Level Benchmarks)
4.2.1. CLYDE
CLYDE는 GNU/Linux용 합성 마이크로 벤치마크로 순차적, 랜덤, 캐시 이렇게 세 가지 패턴으로 읽기/쓰기 테스트를 수행한다. (캐시 테스트는 디스크 캐시에서만 읽기/쓰기를 수행하는 테스트로 SCSI 버스가 사용된다)
이 때 가능한 한 실제 작업환경과 유사한 조건에서 테스트를 할 수 있도록, 많은 수의 매개변수를 자유롭게 설정할 수 있다.
4.2.2. HD Tach
HD Tach는 합성 마이크로 벤치마크로 하드 드라이브, 이동식 드라이브 (ZIP/JAZZ), 플래시 디바이스, 그리고 RAID와 같은 랜덤 액세스 읽기/쓰기 저장장치에 대한 Windows용 벤치마크다.
선택한 장치의 순차적 읽기/쓰기 속도, 랜덤 액세스 속도, 버퍼와 호스트간 처리 속도 그리고 CPU 활용도를 분석하여 그래프의 형태로 보여준다.
읽기, 쓰기 액세스 시간에 대한 비교적 정확한 성능 측정 결과를 보이지만, 측정 장치의 일부 섹터에서만 측정한 결과값을 얻기 때문에, RAID 같은 하드웨어 구성의 효과는 제대로 나타내지 못하는 단점을 가지고 있다.
4.2.3. SPEK
SPEK은 합성 마이크로 벤치마크로 순차적 읽기/쓰기, 랜덤 읽기/쓰기를 수행하여 이 때의 처리량과 응답 시간을 보고한다. 이 때 블록 크기, 각 트랜잭션의 수행 횟수, 읽기/쓰기의 수행 비율, 순차적/랜덤의 수행 비율을 사용자가 매개변수로 넘겨주어, 유연한 테스트를 할 수 있게 한다.
아직 상용화될 프로그램이 개발된 것은 아니고, 기능성과 효율성을 증명하기 위한 Linux 환경의 데모 버전만 구현된 상태이다.
4.3. 디바이스 레벨 벤치마크(Device Level Benchmarks)
4.3.1. IPEAK SPT-V30
Intel에서 개발한 SPT(Storage Performance Tool)은 디스크의 성능을 측정하고 분석하기 위한 합성 마이크로 벤치마크로 다음과 같은 5개의 유틸리티로 구성되어 있다.
1) AnalyzeDisks는 하드 디스크, CD 드라이브와 같은 저장장치의 전반적인 성능에 대한 정보를 분석하여 보여준다. 특정 드라이브를 선택하여 분석을 하고 나면, 그 드라이브에 대한 읽기/쓰기 서비스 시간, 읽기/쓰기 탐색 프로파일, 읽기/쓰기 버퍼링 속도, 프리페칭(prefetching), 읽기 CPU 활용도, 읽기 큐잉등을 그래프로 나타낸다.
2) Win32 Tracing Kit는 AnalyzeTrace, AnalyzeLocality나 RankDisk등에서 이용할 수 있도록, 디스크 동작 (읽기 또는 쓰기)의 트레이스를 추출하여 바이너리 파일 형태로 저장한다.
3) AnalyzeTrace는 앞에서 생성된 트레이스 파일(raw trace file)을 이용하여, 그 파일에 대한 전송 크기(transfer size), 큐 길이, 디스크 유휴 시간(disk idle times), 탐색 거리, 액세스 빈도, 서비스 시간, 전송 크기에 따른 처리 시간의 비율, 탐색 크기에 따른 처리 시간의 비율, 탐색 거리에 따른 데이터 전송량의 비율, 디스크 활용도, 디스크 액세스 순서, 이외의 여러 가지 통계를 보여준다.
4) AnalyzeLocality는 디스크 액세스간의 시간적/공간적 집약성(locality)를 분석하여 그래프로 나타내어준다.
5) RankDisk는 각 디스크의 평균 서비스 시간을 계산하여, 그래프에 막대 형태로 나타내어준다.
Windows 환경에서 사용 가능하다.
4.3.2. QBENCH
QBench는 합성 마이크로 벤치마크로 하드 디스크 드라이브에 순차적/랜덤 읽기/쓰기 동작을 수행하여, 액세스 시간과 전송 비율을 보고한다. 이 때, 사용자가 이용하려는 실제 작업 환경과 비슷한 환경을 나타내기 위해, 순차적/랜덤, 읽기/쓰기의 비율을 사용자가 조정할 수 있도록 하였다. 또한, 점점 발전해가는 디스크 드라이브 기술에 발맞추기 위해, 쓰기 캐싱, multiple zone recording 등도 고려하여 성능측정을 할 수 있도록 옵션을 두었다.
Dos환경에서 사용 가능하다.
5. 벤치마크 성능 비교 (Comparison of Benchmark Capabilities)
버퍼 캐시 고려 √ √ √ √ √ √ √
메타
데이터 접근성능
측정 √
순차적 액세스 고려 √ √ √ √ √ √ √ √ √ √
랜덤
액세스 고려 √ √ √ √ √ √ √
쓰기 성능 측정 √ √ √ √ √ √ √ √ √ √ √
읽기 성능 측정 √ √ √ √ √ √ √ √ √ √ √ √
블록크기 조정가능 여부 √ √ √
플랫폼 L,U L,W,N S,W W, L W U N L W L W D
분류 S/Mi S/Mi S/Mi S/Ma S/Mi S/Ma S/Mi S/Mi S/Mi S/Mi S/Mi S/Mi
벤치마크 Bonnie++ Iozone Postmark IOMeter Winbench IOStone LADDIS CLYDE HD Tach SPEK IPEAK SPT-V30 Qbench
파일
시스템
레벨
벤치마크 블록
디바이스 레벨
벤치마크 디바이스 레벨
벤치마크
표 2 벤치마크 성능 비교
(L : Linux, U: Unix, W: Windows, D: Dos, N: NFS
A: Application, S: Synthetic, Ma: Macro, Mi: Micro)
6. 파일 시스템 레벨과 블록 디바이스 레벨의 성능 측정 (Performance Evaluation on File System Level and Block Device Level)
보통, 플래시 메모리는 파일 시스템을 구축한 후 파일을 통하여 입출력을 하기 때문에, 파일 시스템 레벨에서 플래시 메모리의 성능을 측정하는 것이 일반적이다. 하지만, 파일 시스템에서의 읽기, 쓰기는, 블록 디바이스에서 행하는 동작 외에도, 메타데이터 접근, 업데이트 등이 추가적으로 필요하고, 파일시스템의 관점에서 논리적으로 순차적인 접근이, 실제 디바이스 레벨에서는 물리적으로 순차적이지 않을 수도 있기 때문에, 어느 정도의 오버헤드(overhead)를 초래할 수 있다. 그러므로, 만일 파일 시스템 레벨과 블록 디바이스 레벨에서의 성능 측정 결과가 커다란 차이를 나타낸다면, 각 레벨의 성능을 따로 측정할 필요가 있고, 이 성능의 차이를 통해 파일 시스템에서의 오버헤드를 알아낼 수가 있을 것이다. 반면, 뚜렷한 차이가 보이지 않는다면, 블록 디바이스 레벨의 성능 측정은 생략하고, 파일 시스템 레벨의 성능 측정만으로도 충분하다고 할 수 있다. 이러한 관점에서, 다음과 같이 파일 시스템 레벨과 블록 디바이스 레벨에서의 간단한 입출력 성능을 측정해보고 결과를 분석해 보았다.
6.1. 성능 측정 방법
우리는 Linux 2.4 Kernel에서 아무런 파일 시스템을 구축하지 않은 채, 블록 디바이스에 직접 순차적 읽기, 쓰기를 해보고, ext2 파일 시스템을 올린 후 순차적 읽기, 쓰기를 하여 각각의 성능을 측정해 보았다. 이 때, 나타나는 결과가 플래시 메모리에만 해당되는 특정한 결과인지, 아니면 블록 디바이스의 일반적인 특성인지를 확인하기 위하여, 플래시 메모리뿐만 아니라, 하드 디스크에도 똑같은 방법으로 실험을 해 보았다. 쓰기 동작은 4Kbytes~16Mbytes의 블록 사이즈만큼씩 32Mbytes를 디바이스와 ext2 시스템의 파일에 쓰는 데 걸린 시간을, 읽기 동작은 똑같은 블록 사이즈를 이용하여 512Mbytes를 읽어오는 데 걸린 시간을 측정하였다. 사용한 메모리의 크기는 128Mbytes였다.
6.2. 측정 결과
아래의 그래프에서 확인할 수 있듯이, 블록 디바이스 레벨과 파일 시스템 레벨에서의 성능 차이는 하드 디스크 쓰기의 경우 5%내외, 하드 디스크 읽기와 플래시 메모리 쓰기, 읽기의 경우 3%내외로 큰 차이가 없었다. 쓰기의 경우는, 파일 시스템에서의 오버헤드로 파일 시스템 레벨의 성능이 블록 디바이스 레벨보다 약간 떨어졌다. 읽기의 경우는, 파일 시스템 레벨에서의 성능이 약간 더 좋았는데, 파일 시스템의 미리 읽기 버퍼(Read-ahead buffer)의 성능이 좋기 때문이라고 예상할 수도 있지만, 그냥 오차 범위 이내라고 생각하고 무시해도 무방하다고 본다.
하드 디스크의 파일 시스템 레벨에서의 Bonnie++로 측정한 쓰기, 읽기 성능은 아래 그림 5에 나타난 대로, 각각 23.719 Mbytes/sec, 35.058 Mbytes/sec였다. 그리고, Bonnie++의 블록 쓰기/읽기 단위인, 8Kbytes를 블록 크기로 하여 위에서 테스트한 대로 직접 512Mbytes file에 쓰고 읽었을 때는 27.972 Mbytes/sec, 35.753 Mbytes/sec의 성능을 보였다. 이를 통해, 우리가 이용한 테스트가 충분히 객관적인 정보를 제공한다는 것을 확인할 수 있다.
그림 1 하드 디스크 쓰기 성능 측정 결과
그림 2 하드 디스크 읽기 성능 측정 결과
그림 3 플래시 메모리 쓰기 성능 측정 결과
그림 4 플래시 메모리 읽기 성능 측정 결과
그림 5 Bonniee++을 이용한 하드 디스크 성능 측정
6.3. 결론
위에서 보았듯이, 파일 시스템 레벨과 블록 디바이스 레벨에서의 성능 차이는 무시할 수 있을 만큼 작으므로, 블록 디바이스 레벨에서의 성능 측정은 불필요하다. 우리가 살펴 본 벤치마크 중, 파일 시스템 레벨에서 가장 적절한 프로그램을 골라, 플래시 메모리의 성능을 측정해도 충분할 것이다.
7. Bonnie++
지금까지 살펴본 것처럼, Bonnie++는 무척 간단하지만, 파일 시스템의 성능측정에 필요한 충분한 정보를 제공해 주기 때문에, 플래시 메모리 성능 측정에 가장 적합하다고 할 수 있다. 파일 시스템 병목현상의 주요 원인이라고 할 수 있는 읽기, 쓰기 동작의 처리량을 측정함으로써, 파일 시스템이 디스크에 I/O를 요청했을 때 얼마나 빨리 얻을 수 있는가, 파일들이 파일 시스템에 얼마나 잘 배치되었는가 등에 대한 정보를 얻을 수 있다. 그리고, 읽기/쓰기 동작을 문자(character) 단위로, 또 블록 단위로 각각 실행함으로써, 시스템에 데이터 버퍼가 존재하는지 여부를 확인할 수 있다. 뿐만 아니라, 결과를 알기 쉽고 간단하게 출력해 준다는 장점이 있다.
위에서 조사한 벤치마크 중, 우리가 테스트할 리눅스 환경에서 사용 가능한 파일 시스템 레벨 벤치마크는 Bonnie++과 Iozone으로 압축되는데, Iozone의 가장 큰 장점이라고 할 수 있는 다양한 동작에 대한 I/O 성능 측정은, 몇 가지를 제외하고는(i.e. 건너뛰고 읽기, 거꾸로 읽기, mmap etc.) Bonnie++의 테스트 과정에 대부분 다 포함되어 있다고 할 수 있고, 제외된 동작들은 실제 파일 시스템의 성능에 그다지 큰 영향을 미치지 않는다고 할 수 있다. 그에 덧붙여, Bonnie++는 파일생성 테스트를 순차적인 방법과 랜덤한 방법으로 수행함으로써 메타 데이터 접근 성능을 측정할 수 있다는 커다란 강점이 있다.
7.1. 테스트 세부설명(Test Details)
7.1.1. 파일 입출력 테스트(File I/O Test)
7.1.1.1. 순차적인 출력(Sequential Output)
1) 문자 단위(Per character).
putc() stdio 매크로를 이용하여 파일에 출력한다. 쓰기를 담당하는 루프는 I-cache에 들어갈 수 있을 만큼 충분히 작아야 한다. CPU는 stdio 코드를 실행할 때와 OS가 파일이 저장될 공간을 할당해 줄 때 사용된다.
2) 블록 단위(Per block).
write(2) 명령어를 이용하여 파일을 생성한다. CPU는 OS가 파일이 저장될 공간을 할당해줄 때만 사용된다.
3) 다시 쓰기(Rewrite).
read(2) 명령어를 이용하여 파일을 BUFSIZ 만큼씩 읽고, dirty, lseek(2)와 write(2) 명령어를 이용하여 다시 쓰기를 해 준다. 이 때는, 새로 공간을 할당해 줄 필요도 없고, 행해지는 I/O operation이 모두 집약적이기 때문에, 파일시스템 캐시가 얼마나 효율적인지와 순수한 데이터 입출력 속도를 알아낼 수 있다.
7.1.1.2. 순차적인 입력(Sequential Input)
1) 문자 단위(Per character)
getc() stdio 매크로를 이용하여 파일을 읽는다. 출력의 경우와 마찬가지로 읽기를 담당하는 루프는 충분히 작아야 한다.
2) 블록 단위(Pre block)
read(2) 명령어를 이용하여 파일을 읽는다. 순수한 순차적 입력의 성능을 측정할 수 있는 테스트이다.
7.1.1.3. 랜덤 탐색(Random seeks)
이 테스트는 SeekProcCount 프로세스들을 (기본적으로 3개씩) 동시에 실행하여, bsd 시스템에서는 random()함수를 이용하여, sysV 시스템에서는 drand48()함수를 이용하여 지정된 랜덤한 위치로, 총 8000 번의 lseek()을 수행한다. lseek()을 수행한 후 read(2)를 이용하여 한 블록을 읽고, 10번 중의 1번 꼴로 write(2)를 수행한다. SeekProcCount 프로세스들은 탐색 요청이 항상 대기하고 있다는 것을 보여주기 위해 착안되었다.
7.1.2. 파일 생성 테스트(File Creation Test)
파일 생성 테스트는 7개의 아라비아 숫자와 0~12개의 랜덤한 알파벳 문자로 구성된 이름을 가진 파일을 생성하여 테스트한다. 순차적 테스트(Sequential Test)는 숫자를 파일이름이 숫자로 시작하도록 하고, 랜덤 테스트는(Random Test)는 랜덤 문자로 파일이름이 시작하도록 하면 된다.
순차적 테스트는 파일을 숫자에 의해 정렬된 순서로 생성하고, readdir()로 얻은 순서대로(즉, 파일이 생성된 순서와 거의 일치할, 디렉토리에 파일이 저장된 순서대로) stat()하고 그 순서대로 삭제한다.
랜덤 테스트는 우선, 파일을 파일 시스템에 랜덤하게 보이게 될 순서로 생성한다(파일 이름의 마지막의 7 숫자는 정렬된 상태이다). 그런 후, 파일을 랜덤하게 골라 stat() 하고, 랜덤한 순서로 모든 파일을 삭제한다.
지정된 최대 크기가 0보다 크면, 파일이 생성될 때 랜덤한 양의 데이터를 각 파일에 쓰고, 각 파일을 stat() 할 때 쓰여진 데이터를 읽게 된다.
7.2. Bonnie++ 실행방법 및 옵션
7.2.1. Bonnie++ 실행방법
bonnie++ [-d dir] [-s size(Mb)[:chunk-size(b)]] [-n number-to-stat(*1024)[:max-size[:min-size][:num-directories]]] [-m machine-name] [-r ram-size-in-Mb] [-x number-of-tests] [-u uid-to-use:gid-to-use] [-g gid-to-use] [-q] [-f] [-b] [-p processes | -y]
2) Win32 Tracing Kit는 AnalyzeTrace, AnalyzeLocality나 RankDisk등에서 이용할 수 있도록, 디스크 동작 (읽기 또는 쓰기)의 트레이스를 추출하여 바이너리 파일 형태로 저장한다.
3) AnalyzeTrace는 앞에서 생성된 트레이스 파일(raw trace file)을 이용하여, 그 파일에 대한 전송 크기(transfer size), 큐 길이, 디스크 유휴 시간(disk idle times), 탐색 거리, 액세스 빈도, 서비스 시간, 전송 크기에 따른 처리 시간의 비율, 탐색 크기에 따른 처리 시간의 비율, 탐색 거리에 따른 데이터 전송량의 비율, 디스크 활용도, 디스크 액세스 순서, 이외의 여러 가지 통계를 보여준다.
4) AnalyzeLocality는 디스크 액세스간의 시간적/공간적 집약성(locality)를 분석하여 그래프로 나타내어준다.
5) RankDisk는 각 디스크의 평균 서비스 시간을 계산하여, 그래프에 막대 형태로 나타내어준다.
Windows 환경에서 사용 가능하다.
4.3.2. QBENCH
QBench는 합성 마이크로 벤치마크로 하드 디스크 드라이브에 순차적/랜덤 읽기/쓰기 동작을 수행하여, 액세스 시간과 전송 비율을 보고한다. 이 때, 사용자가 이용하려는 실제 작업 환경과 비슷한 환경을 나타내기 위해, 순차적/랜덤, 읽기/쓰기의 비율을 사용자가 조정할 수 있도록 하였다. 또한, 점점 발전해가는 디스크 드라이브 기술에 발맞추기 위해, 쓰기 캐싱, multiple zone recording 등도 고려하여 성능측정을 할 수 있도록 옵션을 두었다.
Dos환경에서 사용 가능하다.
5. 벤치마크 성능 비교 (Comparison of Benchmark Capabilities)
버퍼 캐시 고려 √ √ √ √ √ √ √
메타
데이터 접근성능
측정 √
순차적 액세스 고려 √ √ √ √ √ √ √ √ √ √
랜덤
액세스 고려 √ √ √ √ √ √ √
쓰기 성능 측정 √ √ √ √ √ √ √ √ √ √ √
읽기 성능 측정 √ √ √ √ √ √ √ √ √ √ √ √
블록크기 조정가능 여부 √ √ √
플랫폼 L,U L,W,N S,W W, L W U N L W L W D
분류 S/Mi S/Mi S/Mi S/Ma S/Mi S/Ma S/Mi S/Mi S/Mi S/Mi S/Mi S/Mi
벤치마크 Bonnie++ Iozone Postmark IOMeter Winbench IOStone LADDIS CLYDE HD Tach SPEK IPEAK SPT-V30 Qbench
파일
시스템
레벨
벤치마크 블록
디바이스 레벨
벤치마크 디바이스 레벨
벤치마크
표 2 벤치마크 성능 비교
(L : Linux, U: Unix, W: Windows, D: Dos, N: NFS
A: Application, S: Synthetic, Ma: Macro, Mi: Micro)
6. 파일 시스템 레벨과 블록 디바이스 레벨의 성능 측정 (Performance Evaluation on File System Level and Block Device Level)
보통, 플래시 메모리는 파일 시스템을 구축한 후 파일을 통하여 입출력을 하기 때문에, 파일 시스템 레벨에서 플래시 메모리의 성능을 측정하는 것이 일반적이다. 하지만, 파일 시스템에서의 읽기, 쓰기는, 블록 디바이스에서 행하는 동작 외에도, 메타데이터 접근, 업데이트 등이 추가적으로 필요하고, 파일시스템의 관점에서 논리적으로 순차적인 접근이, 실제 디바이스 레벨에서는 물리적으로 순차적이지 않을 수도 있기 때문에, 어느 정도의 오버헤드(overhead)를 초래할 수 있다. 그러므로, 만일 파일 시스템 레벨과 블록 디바이스 레벨에서의 성능 측정 결과가 커다란 차이를 나타낸다면, 각 레벨의 성능을 따로 측정할 필요가 있고, 이 성능의 차이를 통해 파일 시스템에서의 오버헤드를 알아낼 수가 있을 것이다. 반면, 뚜렷한 차이가 보이지 않는다면, 블록 디바이스 레벨의 성능 측정은 생략하고, 파일 시스템 레벨의 성능 측정만으로도 충분하다고 할 수 있다. 이러한 관점에서, 다음과 같이 파일 시스템 레벨과 블록 디바이스 레벨에서의 간단한 입출력 성능을 측정해보고 결과를 분석해 보았다.
6.1. 성능 측정 방법
우리는 Linux 2.4 Kernel에서 아무런 파일 시스템을 구축하지 않은 채, 블록 디바이스에 직접 순차적 읽기, 쓰기를 해보고, ext2 파일 시스템을 올린 후 순차적 읽기, 쓰기를 하여 각각의 성능을 측정해 보았다. 이 때, 나타나는 결과가 플래시 메모리에만 해당되는 특정한 결과인지, 아니면 블록 디바이스의 일반적인 특성인지를 확인하기 위하여, 플래시 메모리뿐만 아니라, 하드 디스크에도 똑같은 방법으로 실험을 해 보았다. 쓰기 동작은 4Kbytes~16Mbytes의 블록 사이즈만큼씩 32Mbytes를 디바이스와 ext2 시스템의 파일에 쓰는 데 걸린 시간을, 읽기 동작은 똑같은 블록 사이즈를 이용하여 512Mbytes를 읽어오는 데 걸린 시간을 측정하였다. 사용한 메모리의 크기는 128Mbytes였다.
6.2. 측정 결과
아래의 그래프에서 확인할 수 있듯이, 블록 디바이스 레벨과 파일 시스템 레벨에서의 성능 차이는 하드 디스크 쓰기의 경우 5%내외, 하드 디스크 읽기와 플래시 메모리 쓰기, 읽기의 경우 3%내외로 큰 차이가 없었다. 쓰기의 경우는, 파일 시스템에서의 오버헤드로 파일 시스템 레벨의 성능이 블록 디바이스 레벨보다 약간 떨어졌다. 읽기의 경우는, 파일 시스템 레벨에서의 성능이 약간 더 좋았는데, 파일 시스템의 미리 읽기 버퍼(Read-ahead buffer)의 성능이 좋기 때문이라고 예상할 수도 있지만, 그냥 오차 범위 이내라고 생각하고 무시해도 무방하다고 본다.
하드 디스크의 파일 시스템 레벨에서의 Bonnie++로 측정한 쓰기, 읽기 성능은 아래 그림 5에 나타난 대로, 각각 23.719 Mbytes/sec, 35.058 Mbytes/sec였다. 그리고, Bonnie++의 블록 쓰기/읽기 단위인, 8Kbytes를 블록 크기로 하여 위에서 테스트한 대로 직접 512Mbytes file에 쓰고 읽었을 때는 27.972 Mbytes/sec, 35.753 Mbytes/sec의 성능을 보였다. 이를 통해, 우리가 이용한 테스트가 충분히 객관적인 정보를 제공한다는 것을 확인할 수 있다.
그림 1 하드 디스크 쓰기 성능 측정 결과
그림 2 하드 디스크 읽기 성능 측정 결과
그림 3 플래시 메모리 쓰기 성능 측정 결과
그림 4 플래시 메모리 읽기 성능 측정 결과
그림 5 Bonniee++을 이용한 하드 디스크 성능 측정
6.3. 결론
위에서 보았듯이, 파일 시스템 레벨과 블록 디바이스 레벨에서의 성능 차이는 무시할 수 있을 만큼 작으므로, 블록 디바이스 레벨에서의 성능 측정은 불필요하다. 우리가 살펴 본 벤치마크 중, 파일 시스템 레벨에서 가장 적절한 프로그램을 골라, 플래시 메모리의 성능을 측정해도 충분할 것이다.
7. Bonnie++
지금까지 살펴본 것처럼, Bonnie++는 무척 간단하지만, 파일 시스템의 성능측정에 필요한 충분한 정보를 제공해 주기 때문에, 플래시 메모리 성능 측정에 가장 적합하다고 할 수 있다. 파일 시스템 병목현상의 주요 원인이라고 할 수 있는 읽기, 쓰기 동작의 처리량을 측정함으로써, 파일 시스템이 디스크에 I/O를 요청했을 때 얼마나 빨리 얻을 수 있는가, 파일들이 파일 시스템에 얼마나 잘 배치되었는가 등에 대한 정보를 얻을 수 있다. 그리고, 읽기/쓰기 동작을 문자(character) 단위로, 또 블록 단위로 각각 실행함으로써, 시스템에 데이터 버퍼가 존재하는지 여부를 확인할 수 있다. 뿐만 아니라, 결과를 알기 쉽고 간단하게 출력해 준다는 장점이 있다.
위에서 조사한 벤치마크 중, 우리가 테스트할 리눅스 환경에서 사용 가능한 파일 시스템 레벨 벤치마크는 Bonnie++과 Iozone으로 압축되는데, Iozone의 가장 큰 장점이라고 할 수 있는 다양한 동작에 대한 I/O 성능 측정은, 몇 가지를 제외하고는(i.e. 건너뛰고 읽기, 거꾸로 읽기, mmap etc.) Bonnie++의 테스트 과정에 대부분 다 포함되어 있다고 할 수 있고, 제외된 동작들은 실제 파일 시스템의 성능에 그다지 큰 영향을 미치지 않는다고 할 수 있다. 그에 덧붙여, Bonnie++는 파일생성 테스트를 순차적인 방법과 랜덤한 방법으로 수행함으로써 메타 데이터 접근 성능을 측정할 수 있다는 커다란 강점이 있다.
7.1. 테스트 세부설명(Test Details)
7.1.1. 파일 입출력 테스트(File I/O Test)
7.1.1.1. 순차적인 출력(Sequential Output)
1) 문자 단위(Per character).
putc() stdio 매크로를 이용하여 파일에 출력한다. 쓰기를 담당하는 루프는 I-cache에 들어갈 수 있을 만큼 충분히 작아야 한다. CPU는 stdio 코드를 실행할 때와 OS가 파일이 저장될 공간을 할당해 줄 때 사용된다.
2) 블록 단위(Per block).
write(2) 명령어를 이용하여 파일을 생성한다. CPU는 OS가 파일이 저장될 공간을 할당해줄 때만 사용된다.
3) 다시 쓰기(Rewrite).
read(2) 명령어를 이용하여 파일을 BUFSIZ 만큼씩 읽고, dirty, lseek(2)와 write(2) 명령어를 이용하여 다시 쓰기를 해 준다. 이 때는, 새로 공간을 할당해 줄 필요도 없고, 행해지는 I/O operation이 모두 집약적이기 때문에, 파일시스템 캐시가 얼마나 효율적인지와 순수한 데이터 입출력 속도를 알아낼 수 있다.
7.1.1.2. 순차적인 입력(Sequential Input)
1) 문자 단위(Per character)
getc() stdio 매크로를 이용하여 파일을 읽는다. 출력의 경우와 마찬가지로 읽기를 담당하는 루프는 충분히 작아야 한다.
2) 블록 단위(Pre block)
read(2) 명령어를 이용하여 파일을 읽는다. 순수한 순차적 입력의 성능을 측정할 수 있는 테스트이다.
7.1.1.3. 랜덤 탐색(Random seeks)
이 테스트는 SeekProcCount 프로세스들을 (기본적으로 3개씩) 동시에 실행하여, bsd 시스템에서는 random()함수를 이용하여, sysV 시스템에서는 drand48()함수를 이용하여 지정된 랜덤한 위치로, 총 8000 번의 lseek()을 수행한다. lseek()을 수행한 후 read(2)를 이용하여 한 블록을 읽고, 10번 중의 1번 꼴로 write(2)를 수행한다. SeekProcCount 프로세스들은 탐색 요청이 항상 대기하고 있다는 것을 보여주기 위해 착안되었다.
7.1.2. 파일 생성 테스트(File Creation Test)
파일 생성 테스트는 7개의 아라비아 숫자와 0~12개의 랜덤한 알파벳 문자로 구성된 이름을 가진 파일을 생성하여 테스트한다. 순차적 테스트(Sequential Test)는 숫자를 파일이름이 숫자로 시작하도록 하고, 랜덤 테스트는(Random Test)는 랜덤 문자로 파일이름이 시작하도록 하면 된다.
순차적 테스트는 파일을 숫자에 의해 정렬된 순서로 생성하고, readdir()로 얻은 순서대로(즉, 파일이 생성된 순서와 거의 일치할, 디렉토리에 파일이 저장된 순서대로) stat()하고 그 순서대로 삭제한다.
랜덤 테스트는 우선, 파일을 파일 시스템에 랜덤하게 보이게 될 순서로 생성한다(파일 이름의 마지막의 7 숫자는 정렬된 상태이다). 그런 후, 파일을 랜덤하게 골라 stat() 하고, 랜덤한 순서로 모든 파일을 삭제한다.
지정된 최대 크기가 0보다 크면, 파일이 생성될 때 랜덤한 양의 데이터를 각 파일에 쓰고, 각 파일을 stat() 할 때 쓰여진 데이터를 읽게 된다.
7.2. Bonnie++ 실행방법 및 옵션
7.2.1. Bonnie++ 실행방법
bonnie++ [-d dir] [-s size(Mb)[:chunk-size(b)]] [-n number-to-stat(*1024)[:max-size[:min-size][:num-directories]]] [-m machine-name] [-r ram-size-in-Mb] [-x number-of-tests] [-u uid-to-use:gid-to-use] [-g gid-to-use] [-q] [-f] [-b] [-p processes | -y]
그에 따른 결과가 각각 동작에 걸린시간(/sec), CPU 활용비율(%)로 출력되는데, 이 때 걸린 시간이 1초 미만이면 “+++++”로 출력된다. 이는 반올림상의 에러로 결과가 잘못될 수도 있기 때문이다.
7.2.2. Bonnie++ 사용 가능한 옵션
? -d
테스트에 사용할 디렉토리를 지정한다.
? ?s
IO 성능 측정에 사용할 파일의 크기를 Megabytes 단위로 지정할 수 있다. 파일 크기를 지정할 때 한 가지 주의할 점은, 파일 전체가 버퍼 캐시 안에 저장되지 않을 만큼, 파일이 충분히 커야 한다는 것이다. 파일이 버퍼 캐시에 모두 캐싱되어 버린다면, 디스크 액세스에 걸린 시간이 아닌 캐시 액세스에 걸린 시간을 측정하게 된다. 만일 지정된 파일 크기가 1Gbytes보다 크면, 각각의 크기가 1Gbytes인 파일 여러 개를 이용하여 테스트한다. 혹은, 각 파일의 크기를 직접 지정할 수도 있다. 이 때 각각은 콜론으로 구분해야 하고, 256과 1048576 사이의 2의 거듭제곱수여야 한다. 또는, 각 숫자의 끝에 ‘g’또는 ‘k’를 덧붙여 Gbytes 또는 Kbytes를 표현할 수도 있다.
? -n
파일 생성 테스트에서 생성할 파일의 개수를 지정한다. 지정된 숫자가 n이라고 할 때1024*n 개의 파일로 테스트를 한다. 0을 지정하게 되면, 이 테스트는 건너뛰게 된다.
테스트하는 파일의 기본 크기는 0byte로, -n 파일 개수:최대:최소:디렉토리 개수 의 형태로 테스트할 파일의 최대, 최소 크기를 정할 수 있다. 최대, 최소 크기를 지정하면(지정하지 않으면 최대, 최소 값은 둘 다 디폴트로 0이다), 정해진 최대, 최소 범위 내에서 랜덤하게 정해진다. 디렉토리 개수를 지정해주면, 지정한 수만큼의 하위 디렉토리에 고르게 분포하여 생성한다.
최대값을 -1로 지정하면, 파일 대신에 하드 링크(hard link)를 생성한다. 최대값을 -2로 지정하면, 파일 대신에 소프트 링크(soft link)를 생성한다.
? -m
현재 성능 측정에 사용되는 기계의 이름을 지정한다. 결과 출력 시에 표시되는 것 이외에 다른 용도는 없다.
? -r
RAM크기를 Megabyte 단위로 지정한다. 이 옵션을 주게 되면, 사용자가 지정한 다른 매개변수들이 이 RAM 크기에서도 적당한 지 점검하게 된다. 보통은 RAM 크기를 자체적으로 확인할 수 있기 때문에, 이렇게 지정해 줄 필요는 없다. RAM 크기를 0으로 주게 되면, 이미 지정된 다른 옵션들은 기본값으로 되돌려진다.
? -x
테스트의 실행 횟수를 지정한다. 지정된 횟수만큼 테스트를 마치거나, 프로세스가 죽을 때까지 CSV 형식으로 결과를 계속 출력한다.
? -u
벤치마크를 실행시키는 사용자를 지정한다. 루트(root) 권한으로 실행시킬 때는, 테스트하는 사용자를 지정해주어야 한다. 루트 권한으로 사용하는 것은 바람직하지 않기 때문에, 꼭 필요한 경우에만 ?u root 로 실행하도록 한다. 사용자 그룹을 지정하고 싶을 때는 사용자:그룹 의 형식으로 옵션을 지정해주면 된다. 사용자만 지정하고 그룹은 지정하지 않은 경우, 사용자가 속한 제1그룹으로 정해진다. 숫자로 사용자를 지정한 경우는, 그룹이 지정되지 않는다.
? -g
벤치마크를 사용하는 그룹id를 지정한다.
? -q
조용한(quiet) 실행 모드. 이 옵션을 지정하면, 주요 결과를 제외한 나머지 정보들은 출력되지 않는다.
? -f
빠른 실행 모드. 문자 단위I/O 테스트를 생략할 수 있다.
7.2.2. Bonnie++ 사용 가능한 옵션
? -d
테스트에 사용할 디렉토리를 지정한다.
? ?s
IO 성능 측정에 사용할 파일의 크기를 Megabytes 단위로 지정할 수 있다. 파일 크기를 지정할 때 한 가지 주의할 점은, 파일 전체가 버퍼 캐시 안에 저장되지 않을 만큼, 파일이 충분히 커야 한다는 것이다. 파일이 버퍼 캐시에 모두 캐싱되어 버린다면, 디스크 액세스에 걸린 시간이 아닌 캐시 액세스에 걸린 시간을 측정하게 된다. 만일 지정된 파일 크기가 1Gbytes보다 크면, 각각의 크기가 1Gbytes인 파일 여러 개를 이용하여 테스트한다. 혹은, 각 파일의 크기를 직접 지정할 수도 있다. 이 때 각각은 콜론으로 구분해야 하고, 256과 1048576 사이의 2의 거듭제곱수여야 한다. 또는, 각 숫자의 끝에 ‘g’또는 ‘k’를 덧붙여 Gbytes 또는 Kbytes를 표현할 수도 있다.
? -n
파일 생성 테스트에서 생성할 파일의 개수를 지정한다. 지정된 숫자가 n이라고 할 때1024*n 개의 파일로 테스트를 한다. 0을 지정하게 되면, 이 테스트는 건너뛰게 된다.
테스트하는 파일의 기본 크기는 0byte로, -n 파일 개수:최대:최소:디렉토리 개수 의 형태로 테스트할 파일의 최대, 최소 크기를 정할 수 있다. 최대, 최소 크기를 지정하면(지정하지 않으면 최대, 최소 값은 둘 다 디폴트로 0이다), 정해진 최대, 최소 범위 내에서 랜덤하게 정해진다. 디렉토리 개수를 지정해주면, 지정한 수만큼의 하위 디렉토리에 고르게 분포하여 생성한다.
최대값을 -1로 지정하면, 파일 대신에 하드 링크(hard link)를 생성한다. 최대값을 -2로 지정하면, 파일 대신에 소프트 링크(soft link)를 생성한다.
? -m
현재 성능 측정에 사용되는 기계의 이름을 지정한다. 결과 출력 시에 표시되는 것 이외에 다른 용도는 없다.
? -r
RAM크기를 Megabyte 단위로 지정한다. 이 옵션을 주게 되면, 사용자가 지정한 다른 매개변수들이 이 RAM 크기에서도 적당한 지 점검하게 된다. 보통은 RAM 크기를 자체적으로 확인할 수 있기 때문에, 이렇게 지정해 줄 필요는 없다. RAM 크기를 0으로 주게 되면, 이미 지정된 다른 옵션들은 기본값으로 되돌려진다.
? -x
테스트의 실행 횟수를 지정한다. 지정된 횟수만큼 테스트를 마치거나, 프로세스가 죽을 때까지 CSV 형식으로 결과를 계속 출력한다.
? -u
벤치마크를 실행시키는 사용자를 지정한다. 루트(root) 권한으로 실행시킬 때는, 테스트하는 사용자를 지정해주어야 한다. 루트 권한으로 사용하는 것은 바람직하지 않기 때문에, 꼭 필요한 경우에만 ?u root 로 실행하도록 한다. 사용자 그룹을 지정하고 싶을 때는 사용자:그룹 의 형식으로 옵션을 지정해주면 된다. 사용자만 지정하고 그룹은 지정하지 않은 경우, 사용자가 속한 제1그룹으로 정해진다. 숫자로 사용자를 지정한 경우는, 그룹이 지정되지 않는다.
? -g
벤치마크를 사용하는 그룹id를 지정한다.
? -q
조용한(quiet) 실행 모드. 이 옵션을 지정하면, 주요 결과를 제외한 나머지 정보들은 출력되지 않는다.
? -f
빠른 실행 모드. 문자 단위I/O 테스트를 생략할 수 있다.
? ?b
테스트하는 대상이 메일 서버나 데이터베이스 서버와 같이, 실시간으로 싱크(sync)작업이 필요한 경우는 ?b 옵션을 주어 쓰기가 일어날 때마다 fsync()를 실행하게 할 수 있다.
? -p
테스트에 사용하는 프로세스(process)의 개수를 지정한다. 여러 개의 프로세스를 동기적으로 작동하게 하기 위하여 필요한 세마포어(semaphore)를 생성하기 위함이다. ?y 옵션으로 세마포어를 사용하도록 정해진 프로세스들은 동시에 테스트를 실행한다. 세마포어를 없애기 위해서는 -1 값을 사용한다.
? -y
각 테스트는 세마포어를 얻은 후에 실행하도록 한다.
7.3. Bonnie++를 이용한 실제 테스트 결과
8. 결론 (Conclusion)
본 문서는 벤치마크의 기본적인 기능과 그 구체적인 예를 살펴보았다.
그 중 가장 간단하면서도, 파일 시스템의 기본적인 성능 측정에 적합한 Bonnie++을 이용하여, 현재 수행하고 있는 플래시 메모리의 성능을 측정해 볼 수 있다.
테스트하는 대상이 메일 서버나 데이터베이스 서버와 같이, 실시간으로 싱크(sync)작업이 필요한 경우는 ?b 옵션을 주어 쓰기가 일어날 때마다 fsync()를 실행하게 할 수 있다.
? -p
테스트에 사용하는 프로세스(process)의 개수를 지정한다. 여러 개의 프로세스를 동기적으로 작동하게 하기 위하여 필요한 세마포어(semaphore)를 생성하기 위함이다. ?y 옵션으로 세마포어를 사용하도록 정해진 프로세스들은 동시에 테스트를 실행한다. 세마포어를 없애기 위해서는 -1 값을 사용한다.
? -y
각 테스트는 세마포어를 얻은 후에 실행하도록 한다.
7.3. Bonnie++를 이용한 실제 테스트 결과
8. 결론 (Conclusion)
본 문서는 벤치마크의 기본적인 기능과 그 구체적인 예를 살펴보았다.
그 중 가장 간단하면서도, 파일 시스템의 기본적인 성능 측정에 적합한 Bonnie++을 이용하여, 현재 수행하고 있는 플래시 메모리의 성능을 측정해 볼 수 있다.
댓글목록
등록된 댓글이 없습니다.