하드 디스크 성능을 확인하는 방법

하드 드라이브의 성능을 확인하는 방법 (터미널 또는 GUI를 통해). 쓰기 속도 읽기 속도. 캐시 크기와 속도. 임의의 속도.

터미널 방법

hdparm 시작하기 좋은 곳입니다.

sudo hdparm -Tt /dev/sda

/dev/sda:
Timing cached reads:   12540 MB in  2.00 seconds = 6277.67 MB/sec
Timing buffered disk reads: 234 MB in  3.00 seconds =  77.98 MB/sec

sudo hdparm -v /dev/sda 정보도 제공합니다.

dd 쓰기 속도에 대한 정보를 제공합니다.

드라이브에 파일 시스템이 없으면 ( 만 )을 사용하십시오 of=/dev/sda.

그렇지 않으면 / tmp에 마운트 한 후 테스트 출력 파일을 삭제하십시오.

dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output

10240+0 records in
10240+0 records out
83886080 bytes (84 MB) copied, 1.08009 s, 77.7 MB/s

그래픽 방법

1. 시스템-> 관리-> 디스크 유틸리티로 이동하십시오.
   • 또는 명령 줄에서 Gnome 디스크 유틸리티를 실행하여 gnome-disks
2. 왼쪽 창에서 하드 디스크를 선택하십시오.
3. 이제 오른쪽 창에서“벤치 마크 – 드라이브 성능 측정”버튼을 클릭하십시오.
4. 차트가있는 새 창이 열리고 버튼이 두 개 있습니다. 하나는 "읽기 전용 벤치 마크 시작"이고 다른 하나는 "읽기 / 쓰기 벤치 마크 시작"입니다. 아무 버튼이나 클릭하면 하드 디스크 벤치마킹이 시작됩니다.

디스크 I / O를 벤치마킹하는 방법

조

더 원하는 것이 있습니까?

Suominen이 맞습니다. 일종의 동기화를 사용해야합니다. 그러나 더 간단한 방법이 있습니다. conv = fdatasync가 작업을 수행합니다.

dd if=/dev/zero of=/tmp/output conv=fdatasync bs=384k count=1k; rm -f /tmp/output
1024+0records in
1024+0 records out
402653184 bytes (403 MB) copied, 3.19232 s, 126 MB/s

/dev/urandom소프트웨어 기반이며 돼지만큼 느리기 때문에 사용하지 않는 것이 좋습니다 . 램 디스크에서 임의의 데이터를 청크하는 것이 좋습니다. 하드 디스크 테스트에서는 모든 바이트가 그대로 기록되므로 (dd와 함께 ssd에서도) 무작위로 중요하지 않습니다. 그러나 순수한 0 또는 임의의 데이터로 중복 제거 된 zfs 풀을 테스트하면 성능 차이가 큽니다.

다른 관점은 동기화 시간 포함이어야합니다. 모든 최신 파일 시스템은 파일 작업에서 캐싱을 사용합니다.

메모리가 아닌 디스크 속도를 실제로 측정하려면 캐싱 효과를 제거하기 위해 파일 시스템을 동기화해야합니다. 다음과 같이 쉽게 수행 할 수 있습니다.

time sh -c "dd if=/dev/zero of=testfile bs=100k count=1k && sync"

그 방법으로 출력을 얻습니다.

sync ; time sh -c "dd if=/dev/zero of=testfile bs=100k count=1k  && sync" ; rm testfile 
1024+0 records in
1024+0 records out
104857600 bytes (105 MB) copied, 0.270684 s, 387 MB/s

real    0m0.441s
user    0m0.004s
sys 0m0.124s

디스크 데이터 전송률은 104857600 / 0.441 = 237772335 B / s-> 237MB / s입니다.

캐싱보다 100MB / s 이상 낮습니다.

행복한 벤치마킹

디스크 읽기 및 쓰기 속도를 실시간으로 모니터링하려면 iotop 도구를 사용할 수 있습니다 .

이는 특정 응용 프로그램이나 작업에서 디스크가 어떻게 수행되는지에 대한 정확한 정보를 얻는 데 유용합니다. 출력은 프로세스 당 읽기 / 쓰기 속도와 서버의 총 읽기 / 쓰기 속도를 보여줍니다 top.

iotop을 설치하려면

sudo apt-get install iotop  

그것을 실행하려면 :

sudo iotop

정확성을 원하면을 사용해야합니다 fio. 설명서 ( man fio)를 읽어야 하지만 정확한 결과를 얻을 수 있습니다. 정확성을 위해서는 측정하려는 대상을 정확하게 지정해야합니다. 몇 가지 예 :

큰 블록 이 있는 순차 읽기 속도 (드라이브 사양에서 볼 수있는 숫자에 가까워 야 함) :

fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=read --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting

큰 블록을 사용한 순차적 쓰기 속도 (드라이브 사양에서 볼 수있는 숫자에 가까워 야 함) :

fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=write --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting

랜덤 4K는 QD1을 읽습니다 (확실히 알지 않는 한 실제 성능에 중요한 숫자 임)

fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randread --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --fsync=1 --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting

동기화 된 랜덤 4K 읽기 및 쓰기 QD1 ( 동기화 에서 예상 할 수있는 최악의 경우, 일반적으로 사양서에 나열된 숫자의 1 % 미만) :

fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randrw --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --fsync=1 --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting

--size파일 크기를 늘리려면 인수를 늘리십시오. 더 큰 파일을 사용하면 드라이브 기술과 펌웨어에 따라 숫자가 줄어들 수 있습니다. 판독 헤드가 그렇게 많이 이동할 필요가 없기 때문에 작은 파일은 회전 미디어에 대해 "너무 좋은"결과를 제공합니다. 장치가 거의 비어있는 경우 드라이브를 거의 채울만큼 큰 파일을 사용하면 각 테스트에서 최악의 동작이 발생합니다. SSD의 경우 파일 크기는 그다지 중요하지 않습니다.

그러나 일부 저장 매체의 경우 파일 크기는 짧은 시간 동안 작성된 총 바이트 수만큼 중요하지 않습니다. 예를 들어, 일부 SSD는 사전 소거 된 블록의 성능이 훨씬 빠르거나 쓰기 캐시로 사용되는 작은 SLC 플래시 영역을 가지고 있으며 SLC 캐시가 가득 차면 성능이 변경 될 수 있습니다. 다른 예로, Seagate SMR HDD의 성능은 약 20GB PMR 캐시 영역을 갖지만 일단 가득 차면 SMR 영역에 직접 쓰면 원래 성능에서 10 %로 성능이 저하 될 수 있습니다. 이 성능 저하를 확인하는 유일한 방법은 먼저 20GB 이상을 가능한 빨리 쓰는 것입니다. 물론 이것은 모두 워크로드에 달려 있습니다. 쓰기 액세스가 장치에 내부 캐시를 정리할 수 있도록 지연 시간이 길어지면 테스트 시퀀스가 ​​짧을수록 실제 성능이 더 잘 반영됩니다. 많은 IO를 수행해야하는 경우 두 가지 모두를 증가시켜야합니다.--io_size그리고 --runtime매개 변수. 일부 미디어 (예 : 대부분의 플래시 장치)는 이러한 테스트를 통해 추가 마모가 발생합니다. 제 생각에는 이러한 종류의 테스트를 처리 할만큼 장치가 부족한 경우 어떤 경우에도 가치있는 데이터를 보유하는 데 사용해서는 안됩니다.

또한 일부 고품질 SSD 장치에는 내부 SLC 캐시에 동일한 주소 공간 (예 : 테스트 파일)에 도달 할 경우 테스트 중에 다시 작성되는 데이터를 대체 할 수있는 스마트가 충분한 지능형웨어 레벨링 알고리즘이있을 수 있습니다. 총 SLC 캐시보다 작습니다). 이러한 장치의 경우 파일 크기가 다시 중요해지기 시작합니다. 실제 워크로드가 필요한 경우 실제로 실제로 볼 수있는 파일 크기로 테스트하는 것이 가장 좋습니다. 그렇지 않으면 숫자가 너무 좋아 보일 수 있습니다.

참고 fio첫 번째 실행에 필요한 임시 파일을 생성합니다. 영구 저장 장치에 데이터를 기록하기 전에 데이터를 압축하여 치트를 쓰는 장치에서 너무 많은 숫자를 얻지 않도록 임의의 데이터로 채워집니다. 임시 파일은 fio-tempfile.dat위의 예제에서 호출 되어 현재 작업 디렉토리에 저장됩니다. 따라서 먼저 테스트하려는 장치에 마운트 된 디렉토리로 변경해야합니다.

SSD가 양호하고 더 높은 숫자를 보려면 --numjobs위의 값을 늘리십시오 . 이는 읽기 및 쓰기의 동시성을 정의합니다. 위의 예제는 모두 단일 스레드 프로세스 읽기 및 쓰기에 관한 테스트로 numjobs설정되었습니다 1(아마도 대기열 세트로 가능 iodepth). 하이 엔드 SSD를 (예를 들어 인텔 Optane)도 증가없이 높은 번호를 받아야 numjobs많은 (예 : 4최고 사양 번호를 얻을 충분해야한다)하지만 일부 "기업"SSD는 갈 필요 32- 128사양 번호를 얻을 수 있기 때문에 이들의 내부 지연 시간 장치는 더 높지만 전체 처리량은 제정신입니다.

보니 ++는 내가 리눅스에서 알고있는 최고의 벤치 마크 유틸리티이다.

(현재 Windows 기반 머신을 테스트하기 위해 bonnie ++와 함께 작업 할 때 Linux livecd를 준비 중입니다!)

캐싱, 동기화, 임의 데이터, 디스크의 임의 위치, 작은 크기의 업데이트, 큰 업데이트, 읽기, 쓰기 등을 관리합니다. usbkey, 하드 디스크 (로터리), 솔리드 스테이트 드라이브 및 램 기반 비교 파일 시스템은 초보자에게 매우 유익 할 수 있습니다.

우분투에 포함되어 있는지는 모르겠지만 소스에서 쉽게 컴파일 할 수 있습니다.

http://www.coker.com.au/bonnie++/

쓰기 속도

$ dd if=/dev/zero of=./largefile bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 4.82364 s, 223 MB/s

블록 크기는 실제로 상당히 큽니다. 64k 또는 4k와 같은 작은 크기로 시도 할 수 있습니다.

읽기 속도

다음 명령을 실행하여 메모리 캐시를 지우십시오.

$ sudo sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"

이제 쓰기 테스트에서 작성된 파일을 읽으십시오.

$ dd if=./largefile of=/dev/null bs=4k
165118+0 records in
165118+0 records out
676323328 bytes (676 MB) copied, 3.0114 s, 225 MB/s

보니 ++ 사용법에 대한 힌트

bonnie++ -d [TEST_LOCATION] -s [TEST_SIZE] -n 0 -m [TEST_NAME] -f -b -u [TEST_USER] 
bonnie++ -d /tmp -s 4G -n 0 -m TEST -f -b -u james

조금 더 : SIMPLE BONNIE ++ EXAMPLE .

f3-플래시 사기 방지

무결성을 확인하고, 가짜 플래시 드라이브를 감지하고 성능을 테스트하십시오.

이 답변에 대한 자세한 내용 .