얼마 전 IODrive를 지엔오테크롤로지의 협찬을 받아서 일주일 동안 IO관련 테스트를 진행하였습니다.

서버용 제품으로, 벤더에서 제공하는 스펙만 본다면 기존에 테스트 했던 버텍스 또는 엠트론 보다 월등히 뛰어난 IOPS 수치를 보여주고 있습니다. 또한 특이한 것은 다른 SSD와 다르게 SATA 인터페이스가 아닌 PCI-E 인터페이스를 채택 하였습니다.
역시 서버용 제품이라, 가격은 생각보다 비쌌지만 서버에서 사용하는 엔터프라이즈 SAS디스크의 가격도 수십 만원에서 수백 만원 정도하기에, 적은 공간에 아주 많은 IOPS를 요구하는 비즈니스라면 일반 DISK를 사용하는 것 보다 적은 비용으로 구현 할 수 있을 것 입니다.  

이번에 테스트한 제품은 IODrive 80GB 입니다.

스펙 상으로는 읽기, 쓰기에 대략 10만 IOPS을 제공해 준다고 하며, 최대 bandwidth는 읽기 700MB/s, 쓰기는 550MB/s 을 정도 입니다.
이 정도의 Bandwidth는 일반 서버용 DISK 몇 장만 RAID를 구성하면 충분히 뽑아 낼 수 있기에 비싼 가격과 적은 용량을 가진 SSD만의 작업이라고 볼 수 없습니다.

하지만 랜덤 IOPS에서는 이야기가 달라집니다.
보통 15K rpm 엔터프라이즈 SAS 인터페이스 DISK도 300~400정도의 IOPS를 보여주고 있기에, IODrive가 제공하는 IOPS만큼을 디스크로 구성 하기 위해서는 대략 250장 정의 DISK가 필요하게 됩니다. 이렇게 비교해 보면 SSD의 랜덤 IOPS가 얼마나 많은 IOPS를 제공해 주는지 알 수 있습니다.

[ioDrive 스펙]

[IODrive 모습]

• 테스트 시작

처음 IO테스트를 진행할 때 80GB제품 두 개를 RAID0으로 묶어서 테스트할 예정이었으나, 하드웨어 문제가 있어 부득이하게 싱글로 테스트를 진행하였습니다.

 간단한 테스트한 머신 스펙은 아래와 같습니다.

• CPU : Intel Xeon E54xx * 2 (Quad-Core)
• MEMORY: 2GB

테스트는 총 4가지로 테스트 하였습니다.

1. SQLIO
2. IOMeter
3. SQL Server – Index Scan vs Index Lookup
4. SQL Server – 물리적 조각화에 따른 SCAN성능 비교

• 테스트 1 : SQLIO

  SQLIO는 단일형태의 IOPS를 산정할 수 있는 도구 입니다.
  SQL Server에서 주로 사용되는 8KB랜덤, 256KB 순차 읽기/쓰기로 테스트를 진행하였습니다. 간단히 결과를 알아본다면 랜덤 읽기의 경우 대략 65,000정도 / 쓰기 46,000정도의 IOPS를 보여주고 있습니다. 대략 초당 전송속도(Bandwidth)로 환산해 본다면 대략 500MB정도입니다.

   이 정도의 수치라면 기존 엔터프라이즈 디스크와 비교하면 읽기의 경우 대략 220배 정도 쓰기의 경우 150배 정도 많은 IOPS를 제공해 주고 있습니다.
  아래 표에서는 보여지지 않지만 대부분의 IO응답시간은 1ms이하로 매우 빠른 속도를 보여 주었습니다.
  혹시 위 벤더에서 제공하는 스펙과 차이가 많이 난다고 생각하신다면, 위 테스트는 4K단위로 테스트 하였고, 여기서는 8K단위 테스트 했기 때문입니다.

• 테스트 2 : IOMETER

  SQL Server를 사용하는 서비스에 대해 IO-Sub System에 대한 성능 측정을 해야 한다면,SQL Server를 기반으로 테스트를 진행하면 가장 효과적이고 정확한 테스트 결과를 볼 수 있을 것입니다. 하지만 SQL Server 의 IO패턴을 자유자재로 조작할 수 없기에 이렇게 테스트 쉬운 작업이 아닐 것입니다.  

  이번에 테스트하는 IOMETER는 여러 가지 IO패턴을 만들 수 있는 기능이 있어 SQL Server의 IO패턴을 비슷하게 흉내 낼 수 있습니다. 그래서 이번에는 SQL Server의 IO패턴을 비슷하게 구현하여 IO 성능 테스트를 진행하였습니다.  

  우선 테스트를 하기 전 SQL Server의 IO패턴에 대해서 알아볼 필요가 있습니다.
  SQL Server의 IO패턴은 트랜잭션 로그를 제외하면 IO 패턴은 크게 두 가지로 볼 수 있습니다.

  • Buffer Pool(이하 BP)에 없는 데이터를 읽기 위한 Read IO
  • BP에서 디스크로 플러시 되지 않은 Dirty page를 디스크로 쓰는 checkpoint프로세스

   [디스크에서 분당 만 페이지씩 쓰기 작업]
  

우선 디스크에서 테스트한 결과를 살펴보면,

테스트 환경은 15K SAS 디스크 10장 (RAID10) 구성되었으며, 분당 만 페이지씩 쓰기 IO가 발생하게 됩니다. 간단히 그래프를 살펴보면 평균 읽기는 대략 3700쯤 되다가 쓰기IO가 수행되면 읽기 IO가 대략 2000정도 까지 떨어지는 현상을 보입니다. 쓰기 캐시가 장착된 모델이라 쓰기 시점에 쓰기 응답시간은 매우 빠르나 읽기 응답시간은 느려지는 것을 확인 할 수 있습니다.    

     [SSD에서 10초당 만 페이지씩 쓰기 작업]
   

SSD 에서의 테스트의 경우 위에서 테스트한 SQLIO로 생각 이상의 수치를 보여주었기에, 위 디스크와 다르게 10초당 만 페이지씩 쓰기 작업을 하였습니다.  
간단히 그래프를 살펴보면 평균읽기는 42000정도 되다가 쓰기IO가 수행되면, 읽기IO가 대략 33000정도 까지 떨어지는 현상을 보입니다. PCI-E 인터페이스 이고 제품에도 따로 Write Back 캐시 역할을 해 줄 수 있는 것이 없기에, 쓰기IO 작업 시 위와 디스크에서 테스트한 결과와 다르게 쓰기 응답시간이 느려지는 것을 볼 수 있습니다. 하지만 느려져도 1ms정도이기에 문제가 있는 수치라고 볼 수 없습니다. 또 하나 위 디스크와 다른 부분은 읽기 응답시간입니다. 쓰기 IO가 발생해도 꾸준히 대략 0.4ms 이하 수준을 보여주고 있습니다.

• 테스트 3 : SQL Server – Index Scan vs Index Lookup

 대량의 데이터를 읽어야 하는 경우라면, 인덱스를 룩업하는 것보다 인덱스를 스캔하는 것이 빠르며, 그 속도 차이는 수배에서 수십 배 빨랐습니다. SSD는 위 테스트에서 살펴보았듯이, 많은 랜덤 IOPS를 제공해 주고 있으며, 응답시간 또한 기존디스크에서 볼 수 없는 속도를 내주게 됩니다. 그렇다면 SSD환경에서 모든 데이터를 읽어야 하는 경우에 룩업으로 처리시 어느 정도 성능을 보여줄지 궁금합니다.  

아래 테스트는 7GB정도의 데이터를 입력 후 인덱스 힌트를 사용하여 인덱스 스캔과 인덱스 룩업에 대해 응답시간을 비교하였습니다.  

간단히 결론을 알아 본다면 SCAN작업은 10초, 룩업 작업은 15초 정도에 끝났습니다.

역시나 SCAN이 Lookup보다 빨랐습니다. 하지만 시간이 1.5배 정도밖에 차이가 나지 않은 점을 주목해야 할 것 입니다.  

SELECT COUNT(*) FROM TBL with(index(1),nolock)
/*
테이블'tbl'. 검색수9, 논리적읽기수1002491, 물리적읽기수14078, 미리읽기수1002490, LOB 논리적읽기수0, LOB 물리적읽기수0, LOB 미리읽기수0. 
SQL Server 실행시간:

CPU 시간= 2485밀리초, 경과시간= 10404밀리초
*/

SELECT COUNT(col2) FROM tbl WITH(INDEX(2),nolock)
/*
테이블'tbl'. 검색수9, 논리적읽기수12043916, 물리적읽기수2790, 미리읽기수1006198, LOB 논리적읽기수0, LOB 물리적읽기수0, LOB 미리읽기수0.
테이블'Worktable'. 검색수0, 논리적읽기수0, 물리적읽기수0, 미리읽기수0, LOB 논리적읽기수0, LOB 물리적읽기수0, LOB 미리읽기수0.

CPU 시간= 31797밀리초, 경과시간= 15898밀리초
*/

• 테스트 4 : SQL Server – 물리적 조각화에 따른 SCAN성능 비교

  예전에 테스트한 물리적 조각화에 따라 SCAN 성능이 SSD환경에서는 어떨지 궁금해서 테스트 하였습니다. SSD는 기존의 디스크와 다르게 어떠한 데이터를 읽더라도 모두 동일한 시간에 읽을 수 있습니다. 하지만 기존 DISK는 물리적인 회전을 통해 데이터를 읽어야 하기에 데이터가 쓰여진 위치에 따라 응답시간이 차이가 발생하였습니다.
  그래서 같은 파일을 인접한 곳에 저장하는 조각모음이 필요했었습니다.
  하지만 SSD는 데이터가 어디에 있든 모두 동일한 시간으로 데이터를 가져올 수 있기에 따로 조각모음이 필요  없다고 합니다.

  디스크 환경에서 테스트한 스크립트를 이용하여 SSD에 동일하게 테스트를 진행하였습니다. 아래 수치를 보면 SSD는 물리적 조각화에 의해 전혀 성능적 영향을 받지 않았다고 볼 수 있습니다.
  어느 정도의 차이는 있지만, 테스트 환경에 따라 이 정도의 오차는 충분히 무시할 수 있는 수치로 보여집니다.
  SSD를 사용하면 더 이상 물리적 조각화로 인해 조각모음은 필요 없어 보입니다.

  뭐. SSD에 물리적 조각화라는 말이 안 어울리죠?

USE [master]
GO
CREATE DATABASE [TEST] ON PRIMARY
( NAME = N'TEST', FILENAME = N'F:\DBData\TEST.mdf' , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB )
LOG ON ( NAME = N'TEST_log', FILENAME = N'D:\DBlog\TEST_log.ldf' , MAXSIZE = 2048GB , FILEGROWTH = 10%)

CREATE DATABASE [TEST1] ON PRIMARY
( NAME = N'TEST1', FILENAME = N'F:\DBData\TEST1.mdf' , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB )
LOG ON ( NAME = N'TEST1_log', FILENAME = N'D:\DBlog\TEST1_log.ldf' , MAXSIZE = 2048GB , FILEGROWTH = 10%)

CREATE DATABASE [TEST2] ON PRIMARY
( NAME = N'TEST2', FILENAME = N'F:\DBData\TEST2.mdf' ,SIZE=5GB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB )
LOG ON ( NAME = N'TEST2_log', FILENAME = N'D:\DBlog\TEST2_log.ldf' , SIZE = 5GB , MAXSIZE = 2048GB , FILEGROWTH = 10%)

DECLARE @I VARCHAR(100)
SET @I= '4'
WHILE 1=1
BEGIN 
    EXEC ('ALTER DATABASE TEST MODIFY FILE(NAME = ''TEST'',SIZE='+@I+')') 
    EXEC ('ALTER DATABASE TEST1 MODIFY FILE(NAME = ''TEST1'',SIZE='+@I+')')

     SET @I=@I+1
IF @I=5000 BREAK
END

/*
테스트를위해4000만건대략5GB 정도의데이터를입력한다.
*/

SELECT TOP 40000000
row_number() over(order by (select 1)) as col1
,cast('' as char(100)) col2
INTO test..tbl
FROM master.dbo.spt_values A,master.dbo.spt_values A1,master.dbo.spt_values A2,master.dbo.spt_values A3

SELECT TOP 40000000
row_number() over(order by (select 1)) as col1
,cast('' as char(100)) col2
INTO test2..tbl
FROM master.dbo.spt_values A,master.dbo.spt_values A1,master.dbo.spt_values A2,master.dbo.spt_values A3

exec sp_msforeachtable 'checkpoint 1'
dbcc dropcleanbuffers

SET STATISTICS TIME ON
SET STATISTICS IO ON

-- 조각화 상태
SELECT COUNT(*) FROM test.dbo.tbl
테이블 'tbl'. 검색 수 9, 논리적 읽기 수 579712, 물리적 읽기 수 7258, 미리 읽기 수 579711, LOB 논리적 읽기 수 0, LOB 물리적 읽기 수 0, LOB 미리 읽기 수 0.
CPU 시간 = 10359밀리초, 경과 시간 = 6005밀리초

-- 조각화 상태 아님
SELECT COUNT(*) FROM test2.dbo.tbl
테이블 'tbl'. 검색 수 9, 논리적 읽기 수 579712, 물리적 읽기 수 7190, 미리 읽기 수 579711, LOB 논리적 읽기 수 0, LOB 물리적 읽기 수 0, LOB 미리 읽기 수 0.
CPU 시간 = 9891밀리초, 경과 시간 = 5991밀리초

SET STATISTICS TIME OFF
SET STATISTICS IO OFF

송 혁, SQL Server MVP
sqler.pe.kr // sqlleader.com
hyoksong.tistory.com

업무용으로 SLC SSD를 사용하다 기존 디스크를 다시 사용하니 너무 느리게 느껴져 요즘 한참 SSD쪽에서 이슈가 되고 있는
OCZ사의 Vertex를 구매하였습니다. OS 부팅 등 전체적인 체감 속도는 이전에 사용하던 SSD보다 좋아 졌습니다.

관련하여 기존에 테스트한 SLC SSD와 어느 정도 성능 차이가 있는지 IOPS 테스트를 진행하였으며 재미있는 결과를 얻었습니다.

기존에 테스트한 SLD SSD는 8KB 랜덤 쓰기 작업이 100 조차 되지 않아 SQL Server 에서 사용하기에는 꽤 무리가 있어 보였는데
이번에 테스트한 Vertex 제품의 경우 8KB 랜덤 쓰기 작업이 1600정도로 일반 엔터프라이즈용 15Krpm 디스크 보다 4배 이상
좋은 성능을 가지는 것을 확인 하였습니다.

또한 OCZ에서 서버용으로 SLC 기반의 SSD를 발표하였고, IBM 서버 제품 군에는 내부 디스크로 INTEL SSD를 장착할 수 있기에 
적은 용량에 대단히 많은 IOPS를 요구하는 서비스라면 충분히 고려해 볼 수 있을 것입니다.

이번에도 테스트는 총 4가지로 하였습니다.
- 랜덤 8KB 읽기 (thread 2 / outstanding 4)
- 랜덤 8KB 쓰기 (thread 2 / outstanding 4)
- 순차 1024KB 읽기 (thread 2 / outstanding 4)
- 순차 1024KB 쓰기 (thread 2 / outstanding 4)

[IOPS]

[MB/s]

송 혁, SQL Server MVP
sqler.pe.kr // sqlleader.com
hyoksong.tistory.com

플래터가 물리적으로 움직이는 기존의 디스크 보다 적은 전력, 적은 소음, 빠른 성능을 장점으로 내세우며 많은 이슈가 되고 있는 SSD에 대해서 간단한 성능 테스트를 하였습니다.

CPU 및 메모리는 날이 갈수록 고 클럭으로 발전하지만, 디스크는 15Krpm이 나온지 오래 되었지만 아직도 비슷한 스펙의 디스크를 사용하고 있습니다.

아직까지는 SSD의 GB당 가격이 비싸기에 대중적으로 사용하고 있지는 않지만, 조만간 대중적으로 사용할 제품이라고 생각되며, DB시스템 환경에서 하드웨어 리소스 중 가장 많이 문제가 되는 것 중에 하나인 IO 문제를 해결할 수 있는 가장 좋은 대안이라고 생각됩니다.
 

다행히 예전부터 계속 써보고 싶던 SSD를 거북엄마님께서 1달간 대여해주셔서 관련 테스트를 해볼 수 있게 되었습니다.
(감사합니다. 잘 써서 무사히 돌려 보내겠습니다.)

서버에서 사용하는 컨트롤러가 아닌 일반 PC의 보드 내장 컨트롤러이기에 테스트 결과 중 일부는 잘못될 수도 있습니다.

아래는 테스트한 SSD 생산 업체에서 제공하는 스펙입니다.

랜덤 IOPS가 16000정도에 달하며, 응답시간은 0.1msec라고 합니다.

보통의 15K 디스크가 300정도의 IOPS를 보여주는 것에 비교하면 대략 50배 이상 성능이 좋은 것을 볼 수 있습니다.

또한 응답시간이 1msec도 안 걸리 것도  SSD만의 장점이라고 볼 수 있습니다.

그럼 과연 어느 정도의 속도를 보여줄 지 Microsoft에서 제공하는 SQLIO라는 IO성능 도구로 테스트 하였습니다.

테스트는 총 4가지로 하였습니다.

- 랜덤 8KB 읽기 (thread 2 / outstanding 4)

- 랜덤 8KB 쓰기 (thread 2 / outstanding 4)

- 순차 1024KB 읽기 (thread 2 / outstanding 4)

- 순차 1024KB 쓰기 (thread 2 / outstanding 4)

테스트 결과는,

순차 읽기, 쓰기 작업은 100 IOPS 즉 초당 전송속도가 100MB정도입니다.

위 스펙에서 보여지고 있는 수치와 동일한 것을 알 수 있습니다.

하지만 중요한 건 랜덤IO 작업입니다. OLTP환경에서는 대부분의 IO가 랜덤으로 동작하게 됩니다.

물론 Write Cache를 지원하는 컨트롤러를 사용하게 되면 어느 정도 랜덤 쓰기 작업을 순차 작업으로도 변경가능하긴 합니다.

아무튼 이러한 외부 요인을 생각하지 않는다면 DB시스템에서 사용하기에 조금 무리가 있는 결과를 보여주었습니다.

랜덤 읽기의 경우 대략 6800 IOPS를 보여주고 있습니다. 스펙보다는 적지만 일반 디스크 수십 장으로 구성하여야지만 나타낼 수 있는 성능입니다.

하지만 랜덤 쓰기 IOPS의 경우 57을 보여주고 있습니다. 테스트한 제품이 SLC기반의 SSD이기에 쓰기 작업도 좋은 성능을 보여줄 것이라고 판단하였지만 예상과는 전혀 다른 결과를 보여주었습니다.

서버에서 사용하는 컨트롤러를 사용하였다면 다른 결과를 보여줄 수 있겠지만, 아래의 데이터만 본다면

일반적인 OLTP환경에서는 약간 쓰기가 부담스러워 보입니다.

EMC, 최근에는 HP에서도 SAN제품에 SSD를 장착 할 수 있는 제품을 발표하였고, 점점 SSD가격도 내려가고 있습니다.

몇 년 후면 지금 보다 더욱 빠른 SSD를 사용하는 DB가 많아질 것 입니다.

그런 날이 빨리 오기를 기대해 봅니다.