15. Is there benefit from having more memory?

|출처|  http://www.mysqlperformanceblog.com/2010/11/19/is-there-benefit-from-having-more-memory/

꽤 흥미로운 주제로 인하여, 2010년 4월 포스트를 다시 올립니다.
특히 SSD VS 메모리에 관한 내용입니다.  
http://www.mysqlperformanceblog.com/2010/04/08/fast-ssd-or-more-memory/

당신은  빠른 SSD 와 메모리 추가 중 어떤 것을 구입할 것인가?

 전통적인 scale-out solution이  MySQL에서 인기 있었던 동안, 우리가 지금까지 확장할 때 고려한 사항은 ? 

- 싼 메모리, 빠른 스토리지, 더 좋은 전력 효율
 
확실히 선택의 여지는 지금 여기 있습니다.

저는 Fusion-IO cards 사용에 대한 주 고객 회의가 있었습니다.
많은 pages read/second 처리를 위하여 SSD를 구입한 흥미로운 선택을 한 사람을 보았습니다.
저는 이러한 선택 대신에 메모리를 구입하고, write를 위한 저장 장치를 사용하는 것을 선호합니다.

만약 위의 같은 경우에 제가 생각하는 벤치 마킹은:

-Percona-XtraDB-9.1 release

-Sysbench OLTP workload with 80 million rows (about 18GB worth of data+indexes)

-XFS Filesystem mounted with nobarrier option.

-Tests run with:
  RAID10 with BBU over 8 disks
  Intel SSD X25-E 32GB
  FusionIO 320GB MLC

-각각의 테스트는 버퍼를 2G ~ 22G 사이에서 진행한다. (메모리에 맞게 비교하여 성능을 테스트하려면).

-Hardware was our Dell 900

우리는 RAID10 저장 장치에 대한 기준을 확립하여 테스트를 시작하였습니다.
Y축은  transactions/second (점점 증가), X 축은 innodb_buffer_pool_size의 크기입니다

이 벤치 마크에 대한 세 가지 흥미로운 특징 :

1. 화살표 A는 데이터가 버퍼 풀(최고의 성능)에 완전히 부합하는 경우입니다.
   이것은 메모리의 최고 증가 지점을 넘어서 충돌하기 전을 지적하는 것이 중요합니다.

2. 화살표 B는 데이터가 버퍼 풀의 크기를 초과하기 시작하는 지점 입니다.
   이것은 많은 고객에게 가장 고통스러운 지점입니다
   메모리가 오직  10 % 정도 감소된 동안 성능은 2.6 배 떨어졌습니다!
   이것은 "지난주에는 모든 것이 괜찮았는데?" 라는 말과 똑같습니다.
   저는 메모리를 추가하는 것이 지금의 상황에서 가장 좋다고 제안합니다.

3. 화살표 C는 데이터가 버퍼 풀의 약 세배입니다. 
   이것은 흥미로운 지점을 확대하는 것입니다.
   당신은 메모리의 비용을 감당하지 못할 수도 있기 때문에, 이런 경우에는 SSD가 잘 맞을 수 있습니다 :

이 그래프에서 위의 C지점은   Fusion-IO card로 인하여 5배의  (또는 인텔 SSD는 2배) 성능이 향상됩니다.
memory를 통하여 같은 개선을 얻으려면, 60% 혹은 250%의 메모리를 추가하여 5배의 성능 향상을 기대할 수 있습니다.


당신의 C 지점이 RAM이 32GB일때의, 데이터는 100GB 라는 흥미로운 상황을 상상해 보세요

-다른 32G RAM을  쉽게 추가할 수 있을까요? (귀하의 메모리 슬롯은 이미 채워지지 않았습니까?)
-SSD를 설치할 예산이 있습니까?(SSD의 용량은 상대적으로 작기 때문에, 여전히 더 필요 할 수가 있습니다.
  8 Intel SSD devices 사용하는 어플라이언스는 시장에 이미 있습니다.)
-2 배 또는 5 배 향상으로 충분 할까? 당신이 필요한 만큼의 메모리를 살 여유가 있다면, 더 많은 향상을 기대할 수 있습니다.

가능하면 데이터들이 한 곳으로 집중되도록 워크로드가 설계되었습니다.
하지만 주요 교훈은 여기에 데이터의 "활성 세트"의 크기를 과소 평가하지 않을 것입니다.
오로지 로깅 테이블에 작은 비율로 정렬이 이루어지는 데이터를 추가하는 사람들에게는 관련이 없겠지만,
하지만 이런 경우가 아닐 때는 그것은 상당히 높을 수 있습니다.

주의 : 이 그래프는 이러한 결과는 sysbench 유니폼에 대해서만 유효합니다
         귀하의 특정 워크로드에서 지점 B와 C가 다르게 위치할 수 있습니다.



메모리의 확장이 성능 향상에 이익이 될 것인가?


저 때의 저는 요정 같이 작은 dataset을 사용했습니다,
그로 인하여 그러면 "우리가 메모리 128GB 이상을 사용해도 됩니까?"와 같은 더 많은 질문들을 받게 되었습니다.
우리는 빠른 SSD(solid state drive)를 사용할 경우에도, 여전히  메모리 증가에 대해 고려 하고 있으며,
혹은 이러한 구성은 최상의 성능을 제공합니다.

이 주소는 우리가 실험실에서 쓰고 있는 Cisco UCS C250 server 입니다.
(memory 384GB, FusionIO 320GB MLC)
O_DIRECT setting으로 인해 O/S 캐쉬는 사용하지 않습니다.

이것은 더 많은 메모리를 사용할수록 효과를 볼 수 있습니다.

                                                                          <그래프의 결과>

                        이 수치는 위키 벤치마킹 입니다.

이제 120GB와 250GB의 수치를 자세히 살펴보겠습니다.

Buffer_pool	read-only, tps	read-write, tps
120GB	1866.87	2547.69
250GB	5656.62 (ratio 3x)	7633.38 (ratio 2.99)

우리는 빠른 스토리지 중 하나에 데이터를 저장함에도 불구하고,
2배의 메모리 증가가 3배의 성능 향상을 가져온 것을 볼 수 있습니다.

그래서 최상의 성능을 얻기 위한 우리의 조언은 여전히 동일합니다.
당신은 메모리가 운영중인 데이터 세트에 맞도록 노력 해야 합니다.
그리고 요즘은 이미 300GB + RAM 시스템 구성이 가능합니다.