Home | 문태준 | 시스템어드민 메일링 | Sys Admin 세미나
Skip to end of metadata
Go to start of metadata

chunk size 판단하기

실제 테스팅이 아닌 관련자료를 참고하여 raid 0에 대한 추론을 적는다.

disk i/o를 이야기할때 random/sequential 을 이야기하는데 실제 이것을 어떻게 판단해야 할까? 벤치마킹 테스팅에서는 두개의 환경을 만들 수 있지만 실제 서비스환경에서는 구분이 용이하지 않을 것으로 판단이 된다. dbms의 경우는 random 액세스이고 UCC서비스의 경우는 특정 데이타에 몰리는 경향이 있으므로 sequential 일 것이다. 여기서 dbms에 대한 고려는 빼겠다. 다운로드, 스트리밍 서비스를 기준으로 판단을 하면 될 것이다.

굳이 분류를 하면
random = small io
sequential = big io
이렇게 나눌수는 있을 듯 하다.

sequential

최대의 처리량(디스크 전송률)을 끌어내는 것이 중요
i/o request 크기를 stripe width 크기와 맞춘다.
i/o request = stripe width = chunk size * 디스크 숫자

그러므로 chunk size = i/o request size / 디스크숫자

"Chunks - the hidden key to RAID performance" 자료에서는 big i/o 의 경우 small chunks 을 사용하라고 되어있으며 small 은 512B-8KB를 제시하고 있다. 여기서 작은 chunks 크기를 사용하라고 하는 것은 최대한 i/o 작업을 분산하라는 의미이다. 그런데 이것보다는 i/o reqeust 크기를 stripe width 와 맞추는 것이 더 적당할 것으로 판단이 된다. 한번의 i/o 요청을 각 디스크에서 분산하여 한번에 처리하기 때문이다.

참고로 RHEL 튜닝가이드에서는 stripe 크기가 데이타 블락 사이즈의 배수가 되어야한다는 말이 있다. os에서 저장의 최소단위가 블락이므로 일치하지 않으면 문제가 생길 것으로 예상은 된다.

random

seek time 최소화, iops 최대화
random access의 경우는 보통 작은 i/o 요청일 것이며 단일 i/o를 단일 디스크에서 처리하도록 한다. 그러므로 chunk size를 키우는게 좋을 것이다.
"Chunks - the hidden key to RAID performance" 자료에서는 small i/o 를 512B-4KB로 정리하고 있으며 big chunk size 는 64KB 이상을 언급하고 있다.
System Performance tuning 에서는 128KB 이상을 말하고 있다.

ibm redbook 자료

http://www.redbooks.ibm.com/abstracts/sg245287.html?Open
위의 자료에서 chunk size와 관련된 자료는 http://www.redbooks.ibm.com/redbooks/SG245287/wwhelp/wwhimpl/java/html/wwhelp.htm 에서 확인할 수 있다.

In general, the stripe size should be at least as large as the median disk I/O request size generated by server applications

위에서는 stripe size를 중간 disk i/o request size보다는 크게 하라고 말을 하고 있다. 그 이후에 나오는 자료는 주로 윈도우를 기준으로 설명을 하고 있는데 물리적인 디스크를 모니터링하면서 설명하고 있다. 논리적인 i/o request size는 물리적인 i/o request size를 합친 것으로 본다면 i/o reqeust size 와 stripe width를 맞추어준다는 앞의 내용과 연결이 될 수 있다. 이 부분은 실제로 확인을 해봐야 할 듯 하다.

블락사이즈 관련하여 위 자료에서는 윈도우에서 블락 사이즈를 키울 것을 추천하고 있다.
11.17.8 Review disk controller stripe size and volume allocation units http://www.redbooks.ibm.com/redbooks/SG245287/wwhelp/wwhimpl/java/html/wwhelp.htm

Some server purposes might warrant a smaller allocation unit size where the system will be accessing many small files or records however with file sizes, file systems and disk storage every increasing today our testing has found setting an allocation unit size of 64 KB delivers sound performance and I/O throughput under most circumstances.

http://www.demandtech.com/Resources/Papers/Simplified%20disk%20tuning(large%20footprint).pdf
Simplified disk tuning windows 자료에서 block size 가 커지면서 IOPS가 떨어지면서 read, write iops 가 거의 비슷한 수준에 도달한 자료가 있다. 약간 배치되는 내용이다. 무엇이 맞을지는????

커널설정

커널설정

  • read-ahead 는 sequentail access 에서 유용하다. 그리고 특정한 데이타만 집중해서 접근할 경우에도 유용하지 않을까?? hotspot...
  • 리눅스, 윈도우에서 noatime 은 모두 유용할 것이다.

파일시스템

  • ext2가 ext3보다 write 성능이 좋다는 자료가 있는데 RHEL의 튜닝 가이드를 보면 "ext3의 저널링이 하드 드라이트 헤드의 움직임을 최적화하기 때문에 대부분 ext2보다 더 높은 전송량을 보인다"라는 내용이 있다. 그냥 의문만 가지며 이번에 별도 테스팅을 하지는 않을 것이다.

벤치마킹 테스팅

유의사항

벤치마킹 테스트 결과를 보면 한개의 i/o만 발생을 시킨 경우는 실제 서비스했을때의 영향을 판단하기 힘들다. 테스팅 결과에서도 보듯이 단일 i/o 테스팅에서는 read-ahed 값을 늘리는 것이 지속적으로 효과가 있었지만 여러개의 프로세스를 실행했을때는 극도의 성능저하가 있었다.
그러므로 벤치마킹 테스팅을 한다고 하더라도 여러개의 i/o를 발생시키면서 성능테스팅을 해야 할 것이다.

벤치마킹 방법

  • sequential test / random test
  • chunk size / block size

위 실험을 하면서 tps(iops), 초당 전송량, average size of request (avgrq-sz) 등을 함께 모니터링해야 한다.
chunk size의 경우 위의 내용으로 판단을 해보면 숫자를 늘림으로써 좋아지는 것을 보는것이 아니라 거꾸로 가장 성능이 좋았을때의 i/o 요청크기와 stripe width 와 비교해보는 작업이 필요할 것이다.

모니터링 항목

윈도우, 리눅스 모두 항목은 비슷함

  • 초당 요청 : tps , r/s, w/s
  • 초당 전송량 : kB_read/s, kB_wrtn/s
  • 평균 요청 크기 : avgrq-sz
  • 평균 디스크 큐 길이 : avgqu-sz
  • 전체적인 시스템 자원 : cpu 사용량, %util, memory, 네트워크사용량

기타

  • NTFS 블락크기 : 512,1024,2048,4096,8192,16K,32K,64K
Labels
  • No labels