☰

전용 MySQL 서버에 대한 디스크 I/O 비교를 찾고 있습니다.

tag-icon • tag-icon mysql performance performance-tuning
전용 MySQL 서버에 대한 디스크 I/O 비교를 찾고 있습니다.

우리는 MySQL 클러스터의 용량을 늘리는 데 도움을 주기 위해 컨설턴트를 고용했고, 그가 한 첫 번째 일은(거의 유일한 일) 우리 서버의 디스크 I/O 속도를 측정하는 것이었습니다.

나는 우리가 가지고 있는 시스템과 유사한 시스템의 디스크 i/o를 비교하고 싶습니다.

  • 당사의 MySQL 서버는 SCSI SAN(Raid 5)을 갖춘 32비트 VMWare ESX 3.5에서 실행되는 가상 서버이며, 가상 서버 자체는 Debian Etch 및 MySQL 버전 5.0.32를 실행하고 있습니다.

MySQL 상자에서 다음 명령을 실행하면 다음과 같은 결과가 나타납니다(컨설턴트가 "매우 느림"이라고 설명함).

time dd if=/dev/zero of=OUT.tmp bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 71.3347 seconds, 14.7 MB/s
real    1m13.596s
user    0m0.052s
sys 0m56.932s

time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 21.8202 seconds, 48.1 MB/s
real    0m21.902s
user    0m0.012s  
sys 0m7.948s

이러한 결과가 실제로 "매우 느립니다"입니까?

나는 다른 사람들이 전용 MySQL 상자에서 이 2개의 명령을 통해 얻은 결과를 비교하고 싶습니다. 특히 32비트 가상 머신인 경우 더욱 그렇습니다.

답변1

주의해야 할 점은 dd 명령이 OS의 파일 시스템 캐시를 우회하지 않는다는 것입니다. 즉, 다른 일이 어떻게 진행되고 있는지에 따라 다양한 결과를 얻을 수 있으며 출력 크기를 늘리면(따라서 fs 캐시가 소진됨에 따라 상당한 성능 변화가 있음을 알 수 있습니다)

출력 파일에서 파일 시스템 캐시를 우회하려면 "oflag=direct"를 추가하세요. 예:

time dd if=/dev/zero of=OUT.tmp bs=1M count=1000 oflag=direct

iflag=direct를 사용하여 읽기를 위해 파일 시스템 캐시를 우회할 수 있습니다.

또한 성능은 블록 크기에 따라 크게 달라집니다. 1M은 순차 쓰기 테스트에 있어서 꽤 좋은 절충안이지만 애플리케이션이 1M 블록을 작성하지 않는 한 실제 성능을 나타내지는 않습니다.

일반적으로 이러한 처리량 수치는 매우 형편없습니다. 단일 SATA 드라이브(예: Seagate ES.2 드라이브)는 드라이브 시작 시 최대 105MB/초의 순차 쓰기 속도를 낼 수 있으며 드라이브 시작 시 최대 60MB/초를 유지합니다. 전체 드라이브.

마지막으로, 일반적인 데이터베이스 "모범 사례"에서는 패리티 쓰기로 인한 상대적으로 높은 오버헤드로 인해 데이터베이스의 기본 시스템으로 RAID5/6을 피하라고 말합니다(실제 패리티 계산 자체는 아니며 하드웨어에서는 상당히 저렴하지만 새로운 패리티를 작성할 때 추가 읽기 및 쓰기를 수행해야 함)

답변2

내 mysql 서버의 결과는 다음과 같습니다. 가상머신이 아닌 64비트라서 실제로 얼마나 활용될지는 모르겠지만, 아주 상당한 차이가 있습니다.

time dd if=/dev/zero of=OUT.tmp bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 5.72139 s, 183 MB/s
0.00s user 1.55s system 27% cpu 5.725 total

time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 0.432328 s, 2.4 GB/s
0.00s user 0.45s system 103% cpu 0.436 total

답변3

대부분의 경우 무작위 io [ 예를 들어 다음과도 비교해야 합니다.보니++] 선형 읽기/쓰기뿐만 아니라. 아니면 로그를 가져와서 인덱싱되지 않은 거대한 테이블에 저장하는 하나의 빅 데이터 싱크일까요?

dd 'benchmark'에 대한 결과

szcapp1:/mnt/big/tmp# time dd if=/dev/zero of=OUT.tmp bs=1M count=1000
time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 4.26186 s, 246 MB/s

real    0m4.563s
user    0m0.001s
sys     0m2.255s
szcapp1:/mnt/big/tmp# time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 0.457162 s, 2.3 GB/s

real    0m0.459s
user    0m0.000s
sys     0m0.459s
szcapp1:/mnt/big/tmp#

Dell PowerEdge 2950의 64비트 Linux, 5x 데스크탑 500GB SATA 디스크의 Perc6 RAID 10. 16GB 램, 2x 쿼드 코어 2.66GHz. 하지만 이봐! 이것은 말이 되지 않습니다. 이 데이터는 RAID 컨트롤러 캐시 메모리의 1/4에 들어가고 나머지는 시스템 메모리에 들어갑니다.

결과가 정말 느립니다. [vmware 서버 2.0의 32비트 Linux 게스트] 이상의 Linux에서 실행 중인 vm의 결과:

vfeed0:/tmp# time dd if=/dev/zero of=OUT.tmp bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 15.996 s, 65.6 MB/s

real    0m16.043s
user    0m0.016s
sys     0m13.117s
vfeed0:/tmp# time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 0.49413 s, 2.1 GB/s

real    0m0.505s
user    0m0.000s
sys     0m0.500s
vfeed0:/tmp#

읽기 성능은 가짜라는 점을 명심하십시오. 캐시에서 읽습니다. 게스트의 캐시가 아닌 경우 분명히 vmware 호스트의 캐시에서 읽습니다.

답변4

원래 질문과 다소 다릅니다. 그러나 "RAID 5가 느립니다"에 대한 SAN 공급업체의 대응은 RAID 1 또는 RAID 10으로 변환하는 것입니다. 또한 VMFS 정렬(PDF) 성능에 심각한 영향을 미칠 수 있습니다.

관련 정보