Home 리뷰 회원 리뷰

✔ 뷰어로 보기

2015.09.04 16:58

CPU, SSD IOPS, MySQL Engine Version/Type에 따른 처리 속도 벤치마킹 테스트

heorm

조회 수 2436 추천 수 2 댓글 1

단축키

Prev이전 문서

Next다음 문서

가 크게 작게 위로 아래로 댓글로 가기 인쇄

단축키

Prev이전 문서

Next다음 문서

가 크게 작게 위로 아래로 댓글로 가기 인쇄

(주)빌트온 기술연구소 작성 (주)아이티엔조이 장비 협조

*본 리뷰는 ITCM의 새로운 보금자리 ASRock Rack EP2C602-4L/D16 서버 운영 일지 -1편- 후속 칼럼 입니다.

Content

1. 개요

2. 테스트

2.1. 단일 질의 테스트

2.2. MyISAM 다중 질의 읽기 테스트

2.3. MyISAM과 InnoDB의 다중 질의 읽기 테스트

2.4. MyISAM과 InnoDB의 다중 쓰기 질의 테스트

2.5. MyISAM과 InnoDB의 Read/Write 다중 질의 테스트

3. 결론

1. 개요

대량의 데이터를 처리하는데 있어서 하드웨어 장비와 DBMS의 조합은 응답 속도의 향상을 가져올 수 있다. 물론 하드웨어와 소프트웨어 모두를 올바르게 튜닝 하는 것 역시 중요하다. 이 문서는 하드웨어와 DBMS의 조합에 따른 성능이 응답 속도에 어떠한 영향을 주는지에 대한 벤치마킹을 하는 것으로 초기 테스트 의도는 다음과 같다.

높은 SSD의 IOPS가 응답 속도 향상을 가져다 줄 것이다.
MySQL최신 버전이 기존 버전에 비해서 높은 응답 속도 향상을 가져다 줄 것이다.
CPU의 처리 속도가 응답 속도 향상을 가져다 줄 것이다.

1-3에 대한 테스트를 하기 위해서 다음과 같은 고려 사항은 반드시 필요하다.

1개의 질의 결과가 빠른가?
n개의 질의 결과가 빠른가?
동시 접근을 통해 질의한 n개의 질의 결과가 빠른가?

이를 테스트 하기 위해서 우리는 다음과 같은 시스템을 구성하였으며 테스트를 진행하였다.

Test bed A 이하 A

CPU

Intel(R) Xeon(R) CPU E31220 @ 3.10GHz

Core : 4

CPU Mhz : 1600.000

Cache Size : 8192 KB

Memory

16 GB

SSD

itcm 100,000 IOPS

Timing O_DIRECT cached reads: 898 MB in 2.00 seconds = 448.62 MB/sec

Timing O_DIRECT disk reads: 256 MB in 0.51 seconds = 497.22 MB/sec

Test bed B 이하 B

* ASRock Rack EP2C602-4L/D16 서버 운영 일지에 공개된 서버 입니다. -> 구성 정보 확인

CPU	Intel(R) Xeon(R) CPU E52630 v2 @ 2.60GHz Core : 6 Cpu Mhz : 2599.928 Cache Size : 15360KB
Memory	64GB
SSD #1	Intel SSD DC P3600 Serise(SSDPEDME800G4) 400,000 IOPS Timing O_DIRECT cached reads: 2692 MB in 2.00 seconds = 1346.23 MB/sec Timing O_DIRECT disk reads: 3976 MB in 3.00 seconds = 1325.25 MB/sec
SSD #2	PLEXTOR 128G(PX0128M5S) 80,000 IOPS Timing O_DIRECT cached reads: 526 MB in 2.01 seconds = 262.31 MB/sec Timing O_DIRECT disk reads: 784 MB in 3.00 seconds = 261.04 MB/sec

2. 테스트

2.1 단일 질의 테스트

A, B시스템과 MySQL Version그리고 MySQL Engine에 따른 테스트를 진행한다.

테스트 환경

레코드 수 : 2,934,412건

SELECT SQL_NO_CACHE COUNT(DISTINCT history_code) as cnt from guide_over_00 as b

where b.id='itcm' and '20150501 00:00:00'<=b.ltime and '20150530 23:59:59'>=b.rtime;

총 10회 테스트( 테스트 결과를 신뢰하기 위해 파일 시스템은 EXT4로 고정함)를 진행한다.

응답 시간 / 단위 : 초(Seconds)

구분	가	나	다	라	마
회차	A	B	B	B	B
회차	5.1 MyISAM	5.1 MyISAM	5.6 MyISAM	5.6 MyISAM (performance_schema=0, key_cache_block_size=4096)	5.6 InnoDB
1	7.61	9.33	10.14	9.37	9.61
2	7.66	9.33	10.13	9.36	9.61
3	7.65	9.33	10.14	9.36	9.62
4	7.80	9.34	10.14	9.36	9.45
5	7.68	9.33	10.13	9.36	9.58
6	7.66	9.34	10.14	9.36	9.57
7	7.60	9.34	10.13	9.37	9.58
8	7.88	9.33	10.13	9.36	9.66
9	7.67	9.34	10.13	9.36	9.66
10	7.64	9.33	10.13	9.36	9.67

테스트 결과 (가)의 경우가 MyISAM 5.1임에 불구하고 가장 좋은 성능을 보였다. MySQL 5.6의 MyISAM은 (나)와 (다)를 비교할 때 MySQL 5.1에 비해서 오히려 성능이 안좋다. 다행히 MySQL 5.6 MyISAM의 경우 (라)에서 보는 바와같이 추가적인 튜닝 이후에는 5.1 MyISAM과 비슷한 성능까지는 올라왔다.

InnoDB의 단일 쿼리 테스트의 성능은 튜닝을 충분히 설정한 환경에서 MySQL이 동일한 5.6버전일 때 (라)와 (마)에서 보여주는 바와 같이 MyISAM에 비하여 응답 속도가 다소 늦었다.

단일 쿼리 처리에서는 CPU의 처리 속도가 중요하다는 것을 보여줬다. SSD의 IOPS의 차이에 따른 응답 속도는 단일 질의에서는 어떤 것이 빠르다고 장담할 수 없으나 IOPS가 높다고 좋은 응답성을 보장하지는 않는다. 반대로 다중 질의에서는 성능에 차이가 발생할 수 있다.

2.2 MyISAM 다중 질의 읽기 테스트

하나의 임의 테이블을 생성하여 Index를 설정하지 않고 1,048,576개의 데이터를 임의로 구성하였다.

그리고 이를 mysqlslap을 통해서 동시 접근을 수행하여 테스트 한다.

테스트 환경

create table read_test (v varchar(32));

레코드 수 : 1,048,576건

mysqlslap nodefaults createschema=shield concurrency=32 iterations=10 query="SELECT SQL_NO_CACHE * FROM read_test

WHERE v!='' LIMIT 1040000,100;"

하나의 연결(connection)이 1개의 질의를 처리하는데 걸리는 평균 시간 / 단위 : 초(Seconds)

구분	가	나	다
회차	A	B	B
	5.1 MyISAM (EXT4)	5.1 MyISAM (XFS)	5.1 MyISAM (EXT4)
1	1.179	0.485	0.493
2	1.282	0.484	0.488
3	1.193	0.491	0.494
4	1.274	0.484	0.489
5	1.155	0.488	0.488
6	1.249	0.493	0.487
7	1.137	0.492	0.486
8	1.137	0.496	0.486
9	1.177	0.487	0.487
10	1.165	0.488	0.493

동시에 접근하는 경우 동일한 MySQL 5.1의 MyISAM에서 테스트 했을 때 (가)보다는 (나)와 (다)가 더 좋은 성능을 보였다.

아무리 CPU의 속도가 단일 쿼리에서는 높은 응답을 보장하지만 병렬 처리에서는 CPU속도 뿐만 아니라 Core의 수와 CPU Cache의 크기가 병렬 처리에서 크게 영향을 미친다는 것을 알 수 있다.

병렬 처리는 CPU Core와 Cache가 높을 수록 좋은 결과를 낸다. 또한 IOPS가 높은 SSD의 경우 병렬처리에서 균일한 응답성을 보장할 수 있다. IOPS가 낮다면 높은 응답성을 보장하는데 한계가 있다. 이 한계는 병렬 처리율이 높을수록 심할 것으로 예상된다. (나), (다) 처럼 CPU의 Core가 높아서 좋은 결과가 나온 것 인지 SSD의 IOPS가 높아서 좋은 결과가 나온 것 인지에 대해서는 확신할 수 없다.

2.3 MyISAM과 InnoDB의 다중 질의 읽기 테스트

동일한 환경의 B장비에서 MySQL 5.6에 대하여 MyISAM과 InnoDB에 대하여 읽기 질의를 다중으로 시행한다. File System Type은 Ext4로 고정한다.

테스트 환경

mysqlslap nodefaults createschema=shield concurrency=16 iterations=3 query="SELECT SQL_NO_CACHE COUNT(DISTINCT history_code) as cnt from guide_over_00 as b where b.id='itcm' and '20150501 00:00:00'<=b.ltime and '20150530

23:59:59'>=b.rtime;"

하나의 연결(connection)이 하나의 질의를 처리하는데 걸리는 시간 / 단위 : 초(Seconds)

회차	5.1 MyISAM(INTEL SSD)	5.1 MyISAM(PLEXTOR SSD)	5.6 MyISAM(INTEL SSD)	5.6 InnoDB(INTEL SSD)
1	33.450	34.903	32.644	22.937
2	33.261	34.170	34.225	23.139
3	33.123	34.244	34.267	23.012

InnoDB가 동시 접근에는 좋은 응답성을 보였다. 일반적으로 알려진 MyISAM의 Table Lock발생으로 응답성이 느릴 것으로 예상하였으나

MyISAM도 좋은 수준의 응답성을 보였다. 이는 MyISAM의 특징 가운데 하나로 Read Lock이 걸린 경우 동일한 Read Lock의 진입은 허용하기 때문인 것으로 나타났다. 그리하여 읽기/쓰기를 동시에 진행하여 추가 성능을 테스트 하기로 한다.

다중 읽기 질의에서 IOPS의 성능에 따른 테스트로 MySQL 5.1 MyISAM 기반에서 INTEL SSD(400,000 IOPS)와 PLEXTOR SSD(80,000 IOPS)에서는 근소하게 INTEL SSD가 좋은 성능을 보였다. 만약 동시 접속이 16이 아닌 더 높아진다면 IOPS가 높은 INTEL SSD가 더 좋은 성능을 낼 것으로 예측 가능하다. 그러나 MySQL 5.6 MyISAM으로 INTEL SSD에서 테스트한 성능은 MySQL 5.1 MyISAM의 INTEL SSD에 비해 약간 느렸다. 이를 통해서 MySQL이 버전이 올라가면서 MyISAM의 동시 접근에 대한 처리는 그렇게 좋은 성능을 내지 못하며 그렇다고 MySQL 5.1에 비하여 성능이 너무 떨어진다고 할 수 없는 수치라 볼 수 있다. MyISAM을 사용한다면 MySQL 5.1에서 MySQL 5.6으로 마이그레이션 한다고 해서 문제될 것도 없지만 성능 향상이 있을 것이라는 막연한 기대는 하지 않는 게 좋을 것이다.

다만, 이 지표를 본다면 MySQL 5.6의 InnoDB는 같은 읽기 데이터를 동시에 병렬 처리한다고 해도 MyISAM에 비해서 좋은 성능을 내고 있음을 알 수 있다. 단일 질의 테스트만 본다면 무의미하기 때문에 꼭 병렬 처리의 성능을 측정하는 것이 왜 중요한지를 보여주는 지표이다.

같은 하드웨어 환경에서 InnoDB가 동시 읽기 질의에서 MyISAM보다 좋다. (반드시 모든 다중 InnoDB 읽기 질의가 MyISAM에 비하여 좋다고 할 수 없을지 모른다. 그러나 충분히 부하가 있는 다중 읽기 질의에서는 InnoDB가 좋다고 할 수 있다.) IOPS가 높은 SSD는 동시 병렬 처리량이 증가할 수록 견고한 응답성을 보여주며 반대로 IOPS가 낮은 SSD는 동시 병렬 처리량이 증가할 수록 응답성이 떨어질 것이다.

(더 좋은 동시 접속을 통해 테스트를 진행하는 것이 SSD IOPS 에 따른 확실한 벤치마킹이 가능하나 추가 테스트는 진행하지 않는다. 별도의 테스트를 추가 진행하는 것은 당연히 의미 있는 실험일 수 있다.)

2.4 MyISAM과 InnoDB의 다중 쓰기 질의 테스트

MyISAM와 InnDB의 다중 쓰기 질의 테스트를 진행한다.

테스트 환경

create table write_test_myisam (v varchar(32) not null, index (v)) ENGINE=MyISAM DEFAULT CHARSET=utf8; create table write_test_innodb (v varchar(32) not null, index (v)) ENGINE=InnoDB DEFAULT CHARSET=utf8;

mysqlslap nodefaults createschema=shield concurrency=16 iterations=10000 query="INSERT INTO write_test_myisam (v)

VALUES (md5(rand()));"

mysqlslap nodefaults createschema=shield concurrency=16 iterations=10000 query="INSERT INTO write_test_innodb (v)

VALUES (md5(rand()));"

하나의 연결(connection)에서 하나의 질의에 대한 가장 오래 걸린 질의 시간 / 단위 : 초(Seconds)

회차	레코드수	5.6 MyISAM	5.6 InnoDB
1	160,000	0.002	0.013
2	320,000	0.003	0.008
3	480,000	0.002	0.008
4	640,000	0.004	0.008
5	800,000	0.002	0.011
6	960,000	0.002	0.019
7	1,120,000	0.003	0.008

쓰기의 동시 접근 성능은 MyISAM이 좋은 것으로 나타났다. 그러나 이는 레코드량이 불과 몇 백만건에 불과하고 필드가 1개 밖에 없기 때문에 평균적으로 성능이 좋다고 할 수 없다. 대량의 데이터가 있는 상태에서 테스트를 진행하거나 관련된 다른 벤치마킹 자료를 참고하는 것이 필요하다.

결론은 MyISAM은 동시 쓰기에 좋은 성능을 보인다. 그러나 대량의 데이터가 이미 존재하는 경우 시간이 흐를 수록 MyISAM이 느리다는

평가가 존재한다.

참고 : BackupDB를 복구하는 경우 MyISAM은 월등히 좋은 성능을 보인다. 그러나 InnoDB에는 이러한 DB복구에서 RowLock을 일시적으로 해제하여 쓰기 성능의 단점을 보완하고 있다.

2.5 MyISAM과 InnoDB의 Read/Write 다중 질의 테스트

2.3와 2.4의 테스트를 동시에 하는 것으로 각 세션은 한번은 쓰기, 한번은 질의를 통해서 이를 동시에 접속하여 시행한다.

테스트는 모두 B에서 Ext4 파일 시스템으로 진행한다.

테스트 환경

test.sql

======

INSERT INTO write_test_myisam (v) VALUES (md5(rand()));

SELECT SQL_NO_CACHE COUNT(DISTINCT v) FROM write_test_myisam;

mysqlslap nodefaults createschema=shield concurrency=10 iterations=500 query=test.sql

하나의 연결(Connection)이 2개의 Read/Write질의에 대한 평균 응답 시간 / 단위 : 초(Seconds)

회차	레코드수	5.6 MyISAM	5.6 InnoDB
1	5,000	0.083	0.026
2	10,000	0.294	0.069
3	15,000	0.543	0.110
4	20,000	0.777	0.152

읽기와 쓰기가 동시에 발생하는 다중 질의 환경에서는 InnoDB가 MyISAM에 비하여 월등히 좋은 성능을 보여줬다. 비록 MyISAM이 일정 레코드 이하에서는 InnoDB에 비하여 높은 수준의 쓰기(Insert)응답을 보여준다고 해도 Table Lock의 한계를 벗어나지 못하여 읽기와 쓰기가 동시에 진행되는 환경에서는 레코드 수가 높을 수록 응답성도 느렸다.

비록 쓰기/읽기 2개의 평균 질의에 대한 응답속도가 4회차 MyISAM과 InnoDB의 평균 응답 속도는 각각 0.777, 0.152초가 나온다 하더라도 이것이 하나의 연결(connection)이 500개의 반복을 처리하는데 걸리는 시간은 0.777 x 500(=339초), 0.152 x 500(=76초)으로 이 수치는 당연히 InnoDB가 월등히 좋은 성능을 보여준다는 것을 알 수 있다.

서비스에서 위와 같은 부하가 큰 읽기 질의가 매번 발생하지는 않을 것이다. 그것을 감안하더라도 병렬처리의 읽기/쓰기가 동시에 진행되는 환경에서는 단일 질의의 순간 속도가 빠른 MyISAM보다는 병렬 처리의 평균 시간이 빠른 InnoDB를 선택하는 것이 동시 접근 서비스에 유리하다.

3. 결론

● 고성능의 SSD는 I/O가 빈번한 다중 접속 환경의 서비스에 적합하거나 또는 높은 수준의 고퀄리티 스트리밍에 적합.

○ 고성능 SSD를 달았는데 왜 좋은 DB의 응답성이 확보되지 않느냐고 하는 것은 데이터량 보다는 CPU에 투자하는 것이 바람직함. 또는 DB의 구조를 변경하는 것이 오히려 도움이됨.

○ 고비용 고가용성의 PCIe는 가상화 서비스, IPTV Vod스트리밍 같은 높은 동시접속, 높은 I/O사양 요구의 환경에 적합.

● SSD에서 XFS가 EXT4보다 안 좋은 응답성을 보일 줄 알았으나 의외로 비슷하거나 약간 좋은 결과를 보여줌.

○ HDD와 SSD에 따라 파일 시스템을 어떤 것을 선택하느냐 또 각 특성을 이해하고 적절한 설정을 하느냐에 따라 성능이 달라질 수 있음.

● 빠른 CPU의 성능은 단일 질의의 응답성을 향상시킴.

○ 빠른 CPU가 병렬 처리에도 좋다는 것은 절대로 아님.

○ 빠르게 처리하면 다음 작업도 빠르게 처리할 수 있다는 것은 MultipleThreading환경에서는 일정 한계를 벗어나면 Core의 수가 많을 수록 유리함.

● CPU의 높은 Core와 Cache는 병렬처리의 응답성을 향상시킴.

○ 궁극적으로 빠른 CPU, 높은 Core와 Cache는 비용을 증가시키나 그 만큼 동시 처리의 빠른 응답성을 제공.

● InnoDB는 MyISAM에 비하여 동시 처리(병렬처리)에 강함.

○ Oracle에서는 MySQL의 기본엔진을 InnoDB로 바꿈. (즉 InnoDB를 밀겠다는 의지?)

● MySQL 5.1에 비하여 MySQL 5.6은 단일 쿼리의 처리 속도는 오히려 나빠짐. 그러나 동시 처리(병렬처리)는 오히려 좋아짐.

○ 단순히 Heavy한 질의를 수행한 결과로 MySQL 5.6이 나쁘다고 말 할 수 없음. 동시 접근 테스트를 하면 응답성은 반대로 MySQL 5.6이 더 좋음.

● MyISAM은 MySQL 5.1에 비하여 5.6로 가면서 단일 질의 성능이 저하됨.

○ 단, 병렬 처리할 것이 아니라면 MySQL 5.1의 MyISAM은 동일한 하드웨어 구성에서 단일 쿼리의 응답 속도가 가장 좋다.

○ http://dbahire.com/testingthefastestwaytoimportatableintomysqlandsomeinteresting57performanceresults/

● MySQL은 MyISAM이 되었든 InnoDB가 되었든 튜닝이 중요함.

○ http://www.mysqlkorea.com/gnuboard4/bbs/board.php?bo_table=develop_04&wr_id=3

○ https://www.percona.com/blog/2006/09/29/whattotuneinmysqlserverafterinstallation/

○ http://dbahire.com/testingthefastestwaytoimportatableintomysqlandsomeinteresting57performanceresults/

● OLTP와 OLAP의 서비스를 이해하는 것이 중요함. 이에 따라 DB의 설치 구조에 큰 영향을 미침.

○ 실시간 처리가 중요한 OLTP(OnLine Transaction Prosessing)

■ 은행, 메신저, 게임

○ 대량의 분석 연산 작업이 중요한 OLAP(OnLine Anaytical Processing)

■ 패턴 분석, 이용자 구매 동향 분석, 로그 분석 등

● 하드웨어가 좋아져도(Saleup) 좋은 성능의 서비스를 낼 수 없다면 다음을 고려해봐야 함.

○ 유저가 많이 이용하는 부분에 메모리 캐시를 도입함.

○ DB테이블에 대하여 파티셔닝을 하거나 소프트웨어적인 Sharding을 도입할 것.

○ Active User와 Passive User를 구분하는 것도 좋은 방법.

○ 처리가 오래 걸리는 분석이 필요한 연산의 서비스에는 비동기 통신을 이용.

■ 서버가 처리하고 클라이언트는 처리가 완료될 때까지 대기하거나 주기적으로 Polling하는 것이 도움이 됨.

■ 단, 대기할 때 Timeout이 있다면 실패날 수 있으므로 Polling을 하여 유저에게 선택권(Cancel)을 주는 것이 바람직함.

○ 물리적인 분산처리도 시도하는 것이 좋음. (Saleout)

■ 단, 너무나 좋은 하드웨어라 Saleup의 한계가 아닌 소프트웨어의 한계가 있을 수 있기 때문에 이러한 경우 물리적 분산이 아닌 프로세스를 분산하는 것도 좋음. (10대의 중급 하드웨어 장비로 서비스 할 것인가? 아니면 1대의 HighEng장비로 10개의 프로세스를 동작시켜 서비스 할 것인가?)

■ OLTP서비스라면 충분히 분산처리가 가능하여 좋은 응답속도를 제공할 수 있음.

■ OLAP라면 분산처리에 한계가 존재하는 대용량 데이터가 발생할 가능성이 큼. 처리 시간이 오래 걸릴 때 이에 대한 대처와 유입하는 쓰기 데이터를 어떻게 처리할 것인가에 대한 설계가 잘되어 있어야함.

글쓴이 님의 최신글