Câu trả lời:
Tôi thường sử dụng hdparm
để điểm chuẩn ổ cứng của tôi. Bạn có thể điểm chuẩn cả đọc trực tiếp và đọc lưu trữ. Bạn sẽ muốn chạy các lệnh một vài lần để thiết lập một giá trị trung bình.
Đây là một bài đọc trực tiếp.
$ sudo hdparm -t /dev/sda2
/dev/sda2:
Timing buffered disk reads: 302 MB in 3.00 seconds = 100.58 MB/sec
Và đây là một bộ nhớ đệm.
$ 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.
Tôi cũng đã sử dụng dd
cho loại thử nghiệm này là tốt. Một sửa đổi tôi sẽ thực hiện cho lệnh trên là thêm bit này vào cuối lệnh của bạn , ; rm ddfile
.
$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"; rm ddfile
Điều này sẽ loại bỏ ddfile
sau khi lệnh đã hoàn thành. LƯU Ý: ddfile
là một tệp tạm thời mà bạn không cần phải giữ, đó là tệp dd
được ghi vào ( of=ddfile
), khi nó đặt ổ cứng của bạn đang tải.
Nếu bạn cần kiểm tra nghiêm ngặt hơn về ổ cứng của mình, bạn có thể sử dụng Bonnie ++ .
hdparm
cũng thích, cho điểm chuẩn nhanh chóng. Nhược điểm duy nhất là nó chỉ có điểm chuẩn đọc băng thông và hiệu suất của nhiều loại thiết bị khối (ví dụ RAID, iSCSI) có thể rất bất đối xứng. Để so sánh hiệu suất 'trước' và 'sau' trên cùng một hộp, dd
cũng hoạt động tốt.
hdparm
+ dd
hoặc chỉ bonnie++
hoặc tất cả 3.
(Đây là một câu hỏi rất phổ biến - bạn có thể thấy các biến thể của nó trên https://stackoverflow.com/q/1198691 , https://serverfault.com/q/219739/203726 và https://askubfox.com/q / 87035/740413 )
Có phương pháp nào tốt hơn [so với dd] cho [đĩa chuẩn] không?
Có nhưng họ sẽ mất nhiều thời gian hơn để chạy và yêu cầu kiến thức về cách diễn giải kết quả - không có một con số nào sẽ cho bạn biết mọi thứ trong một lần vì những điều sau đây ảnh hưởng đến loại bài kiểm tra bạn nên chạy:
Và như vậy.
Dưới đây là danh sách ngắn các công cụ dễ chạy nhất ở phía trên và khó hơn / kỹ lưỡng hơn / tốt hơn ở gần phía dưới:
Greg - lấy mã FIO của Jens. Nó thực hiện đúng mọi thứ, bao gồm viết nội dung giả ngẫu nhiên thực tế, cho biết nếu đĩa thực hiện một số "khử trùng lặp" (hay còn gọi là "tối ưu hóa cho điểm chuẩn):
[ https://github.com/axboe/fio/ ]
Bất cứ điều gì khác là nghi ngờ - hãy quên đi bonnie hoặc các công cụ truyền thống khác.
Nguồn: bình luận để lại trên Google Plus cho Greg Kroah-Hartman bởi Linus Torvalds .
Nếu bạn không thể bận tâm đọc tất cả những điều này, tôi chỉ khuyên dùng công cụ IOPS . Nó sẽ cho bạn biết tốc độ trong thế giới thực tùy thuộc vào kích thước khối.
Mặt khác - khi thực hiện một điểm chuẩn IO tôi sẽ xem xét những điều sau đây:
Sử dụng CPU
Bạn sẽ sử dụng khối nào : Nếu bạn muốn đọc / ghi 1 GB từ / vào đĩa, việc này sẽ nhanh chóng nếu bạn thực hiện một thao tác I / O. Nhưng nếu ứng dụng của bạn cần ghi thành từng đoạn 512 byte trên đĩa cứng trong các phần không tuần tự (được gọi là I / O ngẫu nhiên mặc dù nó không ngẫu nhiên) thì nó sẽ trông khác. Bây giờ, cơ sở dữ liệu sẽ thực hiện I / O ngẫu nhiên cho khối lượng dữ liệu và I / O tuần tự cho khối lượng nhật ký do tính chất của chúng . Vì vậy, trước tiên bạn cần phải trở nên rõ ràng những gì bạn muốn đo. Nếu bạn muốn sao chép các tệp video lớn khác với nếu bạn muốn cài đặt Linux.
Kích thước khối này đang ảnh hưởng đến số lượng thao tác I / O bạn làm. Nếu bạn thực hiện, ví dụ 8 thao tác đọc (hoặc ghi tuần tự, không trộn lẫn), bộ lập lịch I / O của HĐH sẽ hợp nhất chúng. Nếu không, bộ đệm của bộ điều khiển sẽ thực hiện hợp nhất. Thực tế không có sự khác biệt nếu bạn đọc 8 khối liên tiếp 512 byte hoặc một đoạn 4096 byte. Một ngoại lệ - nếu bạn quản lý để thực hiện đồng bộ hóa IO trực tiếp và đợi 512 byte trước khi bạn yêu cầu 512 byte tiếp theo. Trong trường hợp này, tăng kích thước khối cũng giống như thêm bộ đệm.
Ngoài ra, bạn cần lưu ý rằng có IO đồng bộ hóa và không đồng bộ: Với IO đồng bộ hóa, bạn sẽ không đưa ra yêu cầu IO tiếp theo trước khi trả lại yêu cầu hiện tại. Với IO async, bạn có thể yêu cầu ví dụ 10 khối dữ liệu và sau đó đợi khi chúng đến. Chủ đề cơ sở dữ liệu không rõ ràng thường sẽ sử dụng IO đồng bộ hóa cho log và async IO cho dữ liệu. Công cụ IOPS đảm nhiệm việc đó bằng cách đo tất cả các kích thước khối có liên quan bắt đầu từ 512 byte.
Bạn sẽ đọc hay viết : Thông thường đọc nhanh hơn viết. Nhưng lưu ý rằng bộ nhớ đệm hoạt động khá khác nhau để đọc và ghi:
Đối với ghi, dữ liệu sẽ được bàn giao cho bộ điều khiển và nếu nó lưu trữ, nó sẽ xác nhận trước khi dữ liệu nằm trên đĩa trừ khi bộ đệm đã đầy. Sử dụng công cụ iozone, bạn có thể vẽ các biểu đồ đẹp của các hiệu ứng bộ đệm (hiệu ứng bộ đệm CPU và hiệu ứng bộ đệm bộ đệm). Bộ nhớ cache trở nên kém hiệu quả hơn đã được viết.
Để đọc, dữ liệu đọc được giữ trong bộ đệm sau lần đọc đầu tiên. Lần đọc đầu tiên mất nhiều thời gian nhất và bộ nhớ đệm sẽ ngày càng hiệu quả hơn trong thời gian hoạt động. Bộ nhớ cache đáng chú ý là bộ đệm CPU, bộ đệm hệ thống tệp của hệ điều hành, bộ đệm của bộ điều khiển IO và bộ đệm của bộ lưu trữ. Công cụ IOPS chỉ đo các lần đọc. Điều này cho phép nó "đọc khắp nơi" và bạn không muốn nó viết thay vì đọc.
Bạn sẽ sử dụng bao nhiêu luồng : Nếu bạn sử dụng một luồng ( sử dụng dd cho điểm chuẩn đĩa ), bạn có thể sẽ có hiệu suất kém hơn nhiều so với một số luồng. Công cụ IOPS tính đến điều này và đọc trên một số chủ đề.
Độ trễ quan trọng đối với bạn như thế nào : Nhìn vào cơ sở dữ liệu, độ trễ IO trở nên cực kỳ quan trọng. Bất kỳ lệnh SQL chèn / cập nhật / xóa nào cũng sẽ được ghi vào nhật ký cơ sở dữ liệu ("log" trong biệt ngữ cơ sở dữ liệu) trên cam kết trước khi được thừa nhận. Điều này có nghĩa là cơ sở dữ liệu hoàn chỉnh có thể đang chờ hoạt động IO này hoàn thành. Tôi chỉ ra ở đây cách đo thời gian chờ trung bình (đang chờ) bằng công cụ iostat .
Việc sử dụng CPU quan trọng như thế nào đối với bạn : CPU của bạn có thể dễ dàng trở thành nút cổ chai đối với hiệu suất của ứng dụng. Trong trường hợp này, bạn phải biết bao nhiêu chu kỳ CPU bị đốt cháy trên mỗi byte đọc / ghi và tối ưu hóa theo hướng đó. Điều này có thể có nghĩa là quyết định / chống lại bộ nhớ flash PCIe tùy thuộc vào kết quả đo của bạn. Một lần nữa, công cụ i điều chỉnh có thể cung cấp cho bạn một ước tính sơ bộ về việc sử dụng CPU bằng các hoạt động IO của bạn.
Nếu bạn đã cài đặt PostgreSQL, bạn có thể sử dụng điểm chuẩn pg_test_fsync tuyệt vời của họ . Về cơ bản nó kiểm tra hiệu suất ghi đồng bộ của bạn.
Trên Ubuntu bạn tìm thấy nó ở đây: /usr/lib/postgresql/9.5/bin/pg_test_fsync
Điều tuyệt vời về nó là công cụ này sẽ cho bạn thấy lý do tại sao SSD doanh nghiệp đáng giá hơn $.
postgresql-contrib
gói.
Bạn có thể sử dụng fio
- công cụ tạo IO đa luồng . Nó được đóng gói bởi một số bản phân phối, ví dụ Fedora 25, Debian và OpenCSW.
Công cụ fio rất linh hoạt, nó có thể dễ dàng được sử dụng để đánh giá các kịch bản IO khác nhau - bao gồm cả các kịch bản đồng thời. Gói đi kèm với một số tệp cấu hình ví dụ (ví dụ /usr/share/doc/fio/examples
:). Nó đo lường chính xác mọi thứ, tức là nó cũng in độ lệch chuẩn và thống kê định lượng cho một số số liệu. Điều mà một số công cụ đo điểm chuẩn phổ biến khác không quan tâm.
Một ví dụ đơn giản (một chuỗi các kịch bản đơn giản: đọc / ghi X tuần tự / ngẫu nhiên):
$ 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
Cuộc gọi:
# 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
[..]
Lưu ý rằng [global]
phần này có mặc định toàn cầu có thể được ghi đè bởi các phần khác. Mỗi phần mô tả một công việc, tên phần là tên công việc và có thể được tự do lựa chọn. Theo mặc định, các công việc khác nhau được bắt đầu song song, do đó, ví dụ trên rõ ràng tuần tự hóa việc thực hiện công việc bằng
wait_for
khóa. Ngoài ra, fio sử dụng kích thước khối 4 KiB - cũng có thể thay đổi. Ví dụ trực tiếp sử dụng thiết bị thô cho các công việc đọc và ghi, do đó, đảm bảo rằng bạn sử dụng đúng thiết bị. Công cụ này cũng hỗ trợ sử dụng tệp / thư mục trên các hệ thống tệp hiện có.
Các hdparm
tiện ích cung cấp một chuẩn mực đọc rất đơn giản, ví dụ như:
# hdparm -t -T /dev/sdz
Nó không phải là sự thay thế cho một công cụ đo điểm chuẩn hiện đại như fio, nó chỉ nên được sử dụng để kiểm tra tính hợp lý đầu tiên. Ví dụ: để kiểm tra xem ổ USB 3 bên ngoài có bị nhận nhầm là thiết bị USB 2 hay không (bạn sẽ thấy ~ 100 MiB / s so với ~ 30 tốc độ MiB / s sau đó).
Như được chỉ ra ở đây , bạn có thể sử dụng gnome-disks
(nếu bạn sử dụng Gnome).
Nhấp vào ổ đĩa mà bạn muốn kiểm tra và nhấp vào "Tùy chọn phân vùng bổ sung" (các bánh xe). Sau đó Benchmark Partition
. Bạn sẽ nhận được đọc / ghi trung bình tính bằng MB / s và thời gian truy cập trung bình tính bằng mili giây. Tôi thấy rằng rất thoải mái.
Đó là một chút thô, nhưng điều này làm việc trong một nhúm:
find <path> -type f -print0 | cpio -0o >/dev/null
Bạn có thể thực hiện một số điều thú vị với kỹ thuật này, bao gồm lưu trữ tất cả các tệp /lib
và /usr/bin
tệp. Bạn cũng có thể sử dụng điều này như một phần của nỗ lực đo điểm chuẩn:
find / -xdev -type f -print0 |
sort -R --from0-file=- |
timeout "5m" cpio -0o >/dev/null
Tất cả tên tệp trên root được tìm thấy, sắp xếp ngẫu nhiên và sao chép chúng vào bộ đệm trong tối đa 1 phút. Đầu ra từ cpio cho bạn biết có bao nhiêu khối đã được sao chép. Lặp lại 3 lần để có trung bình khối mỗi phút. (Lưu ý, thao tác tìm / sắp xếp có thể mất nhiều thời gian - lâu hơn nhiều so với bản sao. Sẽ tốt hơn khi lưu bộ đệm tìm / sắp xếp và sử dụng split
để lấy mẫu tệp.)