답변:
나는 보통 hdparm내 HDD를 벤치마킹 하는 데 사용 합니다. 직접 읽기와 캐시 된 읽기 모두를 벤치마킹 할 수 있습니다. 평균값을 설정하기 위해 명령을 두 번 실행하려고합니다.
다음은 직접 읽은 것입니다.
$ sudo hdparm -t /dev/sda2
/dev/sda2:
Timing buffered disk reads: 302 MB in 3.00 seconds = 100.58 MB/sec
그리고 여기 캐시 된 읽기가 있습니다.
$ sudo hdparm -T /dev/sda2
/dev/sda2:
Timing cached reads: 4636 MB in 2.00 seconds = 2318.89 MB/sec
-t Perform timings of device reads for benchmark and comparison
purposes. For meaningful results, this operation should be repeated
2-3 times on an otherwise inactive system (no other active processes)
with at least a couple of megabytes of free memory. This displays
the speed of reading through the buffer cache to the disk without
any prior caching of data. This measurement is an indication of how
fast the drive can sustain sequential data reads under Linux, without
any filesystem overhead. To ensure accurate measurements, the
buffer cache is flushed during the processing of -t using the
BLKFLSBUF ioctl.
-T Perform timings of cache reads for benchmark and comparison purposes.
For meaningful results, this operation should be repeated 2-3
times on an otherwise inactive system (no other active processes)
with at least a couple of megabytes of free memory. This displays
the speed of reading directly from the Linux buffer cache without
disk access. This measurement is essentially an indication of the
throughput of the processor, cache, and memory of the system under
test.
나도 dd이런 유형의 테스트에도 사용했습니다. 위의 명령을 수정하면 명령 끝에이 비트를 추가 할 수 있습니다 ; rm ddfile.
$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"; rm ddfile
ddfile명령이 완료된 후 를 제거합니다 . 참고 : HDD를로드 할 때 ddfile보관할 필요가없는 임시 파일입니다 dd( of=ddfile).
HDD에 대한보다 엄격한 테스트가 필요한 경우 Bonnie ++를 사용할 수 있습니다 .
hdparm빠른 벤치 마크뿐만 아니라. 유일한 단점은 읽기 대역폭 만 벤치 마크하고 여러 유형의 블록 장치 (예 : RAID, iSCSI)의 성능이 매우 비대칭적일 수 있다는 것입니다. 같은 상자에서 '이전'과 '이후'성능을 비교할 dd때도 잘 작동합니다.
hdparm이상 dd또는 bonnie++3 개 이상을 사용해야합니다.
(이것은 매우 인기있는 질문입니다 -https://stackoverflow.com/q/1198691 , https://serverfault.com/q/219739/203726 및 https://askubuntu.com/q 에서 변형을 볼 수 있습니다 / 87035 / 740413 )
[dd]보다 [benchmark disks]보다 나은 방법이 있습니까?
예. 그러나 실행하는 데 시간이 오래 걸리고 결과를 해석하는 방법에 대한 지식이 필요합니다. 다음과 같이 실행해야하는 테스트 유형에 영향을 미치기 때문에 모든 것을 한 번에 알려주는 단일 번호는 없습니다.
등등.
다음은 상단에서 가장 쉽게 실행하고 하단에서 더 어렵고 철저한 / 더 나은 도구를 제공하는 간단한 도구 목록입니다.
Greg-Jens의 FIO 코드를 얻습니다. 디스크가 "중복 제거"(일명 "벤치 마크 최적화")를 수행하는지 보여주는 실제 의사 랜덤 컨텐츠 작성을 포함하여 올바르게 수행합니다.
[ https://github.com/axboe/fio/ ]
의심스러운 점은 보니 또는 기타 기존 도구를 잊어 버리십시오.
출처 : Linus Torvalds의 Greg Kroah-Hartman에게 Google Plus에 댓글을 남겼습니다 .
이 모든 것을 읽을 수 없다면 IOPS 도구를 추천합니다 . 블록 크기에 따라 실제 속도를 알려줍니다.
그렇지 않으면-IO 벤치 마크를 수행 할 때 다음 사항을 살펴볼 것입니다.
CPU 활용
사용할 블록 크기 : 디스크에서 1GB를 읽고 쓰려면 I / O 작업을 한 번 수행하면 빠릅니다. 그러나 응용 프로그램이 하드 디스크 전체에 512 바이트 청크를 비 순차적 조각으로 작성해야하는 경우 (임의는 아니지만 임의 I / O라고 함) 다르게 표시됩니다. 이제 데이터베이스는 특성상 데이터 볼륨에 대한 임의 I / O 및 로그 볼륨에 대한 순차 I / O를 수행합니다 . 따라서 먼저 측정하려는 대상을 명확하게해야합니다. Linux를 설치하려는 경우와 다른 큰 비디오 파일을 복사하려는 경우.
이 블록 크기는 수행하는 I / O 작업 수에 영향을줍니다. 예를 들어 8 개의 순차적 읽기 (또는 쓰기가 아닌 혼합) 작업을 수행하면 OS의 I / O 스케줄러가이를 병합합니다. 그렇지 않으면 컨트롤러의 캐시가 병합을 수행합니다. 512 바이트의 연속 블록 8 개 또는 4096 바이트의 청크 1 개를 읽는 경우 실제로 차이가 없습니다. 한 가지 예외-직접 동기화 IO를 수행하고 512 바이트를 기다렸다가 다음 512 바이트를 요청하는 경우. 이 경우 블록 크기를 늘리는 것은 캐시를 추가하는 것과 같습니다.
또한 동기화 및 비동기 IO가 있음을 알고 있어야합니다. 동기화 IO를 사용하면 현재 요청이 반환되기 전에 다음 IO 요청을 발행하지 않습니다. 비동기 IO를 사용하면 예를 들어 10 청크의 데이터를 요청한 다음 도착할 때까지 기다릴 수 있습니다. 별개의 데이터베이스 스레드는 일반적으로 로그에 동기화 IO를 사용하고 데이터에 비동기 IO를 사용합니다. IOPS 도구 는 512 바이트에서 시작하여 모든 관련 블록 크기를 측정하여이를 처리합니다.
읽고 쓸 것인가 : 일반적으로 읽는 것보다 쓰기가 빠릅니다. 그러나 캐싱은 읽기와 쓰기에 대해 다른 방식으로 작동합니다.
쓰기의 경우 데이터가 컨트롤러로 전달되고 캐시 된 경우 캐시가 가득 차지 않은 경우 데이터가 디스크에 저장되기 전에 확인됩니다. 도구 iozone 을 사용하면 아름다운 캐시 효과 (CPU 캐시 효과 및 버퍼 캐시 효과)의 아름다운 그래프를 그릴 수 있습니다. 더 많이 쓸수록 캐시의 효율성이 떨어집니다.
읽기의 경우 읽기 데이터는 첫 번째 읽기 후에 캐시에 보관됩니다. 첫 번째 읽기는 시간이 오래 걸리고 가동 시간 동안 캐싱이 더욱 효과적입니다. 주목할만한 캐시는 CPU 캐시, OS 파일 시스템 캐시, IO 컨트롤러 캐시 및 스토리지 캐시입니다. IOPS 도구 는 읽기만 측정합니다. 이렇게하면 "모든 곳에서 읽을 수 있습니다"라는 대신 읽기 대신 쓰기를 원하지 않습니다.
사용할 스레드 수 : 하나의 스레드 ( 디스크 벤치 마크에 dd 사용 )를 사용하면 여러 스레드보다 성능이 훨씬 떨어집니다. IOPS 도구 는이를 고려하여 여러 스레드를 읽습니다.
대기 시간이 얼마나 중요한지 : 데이터베이스를 보면 IO 대기 시간이 엄청나게 중요해집니다. 삽입 / 업데이트 / 삭제 SQL 명령은 승인되기 전에 커밋시 데이터베이스 저널 (데이터베이스 링고의 "log")에 기록됩니다. 이는 전체 데이터베이스가이 IO 작업이 완료되기를 기다리는 중임을 의미합니다. 여기 에 iostat 도구를 사용하여 평균 대기 시간 (대기)을 측정하는 방법을 보여줍니다 .
CPU 사용률의 중요성 : CPU가 응용 프로그램 성능의 병목 현상이되기 쉽습니다. 이 경우 바이트 읽기 / 쓰기 당 얼마나 많은 CPU주기가 소모되는지 알고 해당 방향으로 최적화해야합니다. 이는 측정 결과에 따라 PCIe 플래시 메모리를 결정하거나 의미합니다. 또한 iostat 도구 를 사용하면 IO 작업을 통해 CPU 사용률을 대략적으로 추정 할 수 있습니다.
PostgreSQL을 설치 한 경우 우수한 pg_test_fsync 벤치 마크를 사용할 수 있습니다 . 기본적으로 쓰기 동기화 성능을 테스트합니다.
우분투에서는 여기에서 찾을 수 있습니다. /usr/lib/postgresql/9.5/bin/pg_test_fsync
이것에 대한 가장 큰 장점은이 도구가 기업용 SSD가 추가로 가치가있는 이유를 보여줄 것이라는 점입니다.
postgresql-contrib패키지 로 제공 됩니다.
당신은 사용할 수 있습니다 fio- 멀티 스레드 IO 생성 도구를 . Fedora 25, Debian 및 OpenCSW와 같은 여러 배포판으로 패키지되어 있습니다.
fio 도구는 매우 유연하여 동시 시나리오를 포함한 다양한 IO 시나리오를 쉽게 벤치마킹하는 데 사용할 수 있습니다. 패키지에는 몇 가지 구성 파일 예가 포함되어 있습니다 (예 :) /usr/share/doc/fio/examples. 그것은 물건을 올바르게 측정합니다. 즉, 일부 그림에 대한 표준 편차 및 정량적 통계를 인쇄합니다. 다른 인기있는 벤치마킹 도구가 신경 쓰지 않는 것
간단한 예 (일련의 간단한 시나리오 : 순차 / 임의 X 읽기 / 쓰기) :
$ cat fio.cfg
[global]
size=1g
filename=/dev/sdz
[randwrite]
rw=randwrite
[randread]
wait_for=randwrite
rw=randread
size=256m
[seqread]
wait_for=randread
rw=read
[seqwrite]
wait_for=seqread
rw=write
호출:
# fio -o fio-seagate-usb-xyz.log fio.cfg
$ cat fio-seagate-usb-xyz.log
[..]
randwrite: (groupid=0, jobs=1): err= 0: pid=11858: Sun Apr 2 21:23:30 2017
write: io=1024.0MB, bw=16499KB/s, iops=4124, runt= 63552msec
clat (usec): min=1, max=148280, avg=240.21, stdev=2216.91
lat (usec): min=1, max=148280, avg=240.49, stdev=2216.91
clat percentiles (usec):
| 1.00th=[ 2], 5.00th=[ 2], 10.00th=[ 2], 20.00th=[ 7],
| 30.00th=[ 10], 40.00th=[ 11], 50.00th=[ 11], 60.00th=[ 12],
| 70.00th=[ 14], 80.00th=[ 16], 90.00th=[ 19], 95.00th=[ 25],
| 99.00th=[ 9408], 99.50th=[10432], 99.90th=[21888], 99.95th=[38144],
| 99.99th=[92672]
bw (KB /s): min= 7143, max=371874, per=45.77%, avg=15104.53, stdev=32105.17
lat (usec) : 2=0.20%, 4=15.36%, 10=6.58%, 20=69.35%, 50=6.07%
lat (usec) : 100=0.49%, 250=0.07%, 500=0.01%, 750=0.01%
lat (msec) : 4=0.01%, 10=1.20%, 20=0.54%, 50=0.08%, 100=0.03%
lat (msec) : 250=0.01%
cpu : usr=1.04%, sys=4.79%, ctx=4977, majf=0, minf=11
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued : total=r=0/w=262144/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency : target=0, window=0, percentile=100.00%, depth=1
randread: (groupid=0, jobs=1): err= 0: pid=11876: Sun Apr 2 21:23:30 2017
read : io=262144KB, bw=797863B/s, iops=194, runt=336443msec
[..]
bw (KB /s): min= 312, max= 4513, per=15.19%, avg=591.51, stdev=222.35
[..]
이 [global]섹션에는 다른 섹션에 의해 재정의 될 수있는 전역 기본값이 있습니다. 각 섹션은 작업을 설명하고 섹션 이름은 작업 이름이며 자유롭게 선택할 수 있습니다. 기본적으로 다른 작업이 병렬로 시작되므로 위의 예제는 wait_for키를 사용 하여 작업 실행을 명시 적으로 직렬화합니다
. 또한 fio는 4 KiB의 블록 크기를 사용하며이 블록 크기도 변경할 수 있습니다. 이 예제는 읽기 및 쓰기 작업에 원시 장치를 직접 사용하므로 올바른 장치를 사용해야합니다. 이 도구는 기존 파일 시스템에서 파일 / 디렉토리 사용을 지원합니다.
이 hdparm유틸리티는 다음과 같은 매우 간단한 읽기 벤치 마크를 제공합니다.
# hdparm -t -T /dev/sdz
fio와 같은 최첨단 벤치마킹 도구를 대체하는 것이 아니라 첫 번째 타당성 검사에 사용해야합니다. 예를 들어, 외장 USB 3 드라이브가 USB 2 장치로 잘못 인식되는지 확인하려면 (~ 100 MiB / s vs. ~ 30 MiB / s 속도)
약간 조잡하지만 조금씩 작동합니다.
find <path> -type f -print0 | cpio -0o >/dev/null
모든 /lib및 /usr/bin파일 캐싱을 포함하여이 기술을 사용하여 몇 가지 흥미로운 작업을 수행 할 수 있습니다 . 벤치마킹 노력의 일부로 이것을 사용할 수도 있습니다.
find / -xdev -type f -print0 |
sort -R --from0-file=- |
timeout "5m" cpio -0o >/dev/null
루트의 모든 파일 이름은 무작위로 정렬되어 발견되며 최대 1 분 동안 캐시에 복사됩니다. cpio의 출력은 복사 된 블록 수를 알려줍니다. 분당 평균 블록 수를 얻으려면 3 번 반복하십시오. 찾기 / 정렬 작업은 복사 시간보다 훨씬 오래 걸릴 수 있습니다. 찾기 / 정렬을 캐시하고 split파일 샘플을 얻는 데 사용 하는 것이 좋습니다 .