#1 楼
终端方法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
图解方法
转到系统->管理->磁盘实用程序。
或者通过运行
gnome-disks从命令行启动Gnome磁盘实用程序在左窗格中选择硬盘。
现在单击右窗格中的“基准-测量驱动器性能”按钮。
将打开一个包含图表的新窗口。您将找到两个纽扣。一种是“开始只读基准”，另一种是“开始读/写基准”。当您单击任何人按钮时，它将开始对硬盘进行基准测试。
如何对磁盘I / O进行基准测试
文章
您还有想要的吗？
评论
我建议在测试SSD时测试/ dev / urandom以及/ dev / zero作为dd的输入，因为数据的可压缩性会对写入速度产生巨大影响。
–伊恩·麦金农
2012年11月8日在16:23
我的Ubuntu 12.04 Unity上没有这样的“系统->”。或者至少我还没有找到它。而且我在系统设置中都没有看到该磁盘工具... O_o但是我最终设法运行了它：/ usr / bin / palimpsest
– Fran Marzoa
2012年11月30日22:00
请注意，从12.10开始，它简称为“磁盘”，可以通过Unity找到。
–Paul Lammertsma
14年2月14日在11:18
在Gnome上，它已移至应用程序->系统工具->首选项->磁盘实用程序。对于讨厌Unity的用户。
–肯·夏普
2014年3月13日15:12
这些天/ tmp文件系统经常使用ramdisk。因此，写入/ tmp似乎在测试您的内存，而不是磁盘子系统。
– Zoredache
2014年3月27日在16:44
#2 楼
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
评论
这是使用与其他命令/选项不同的答案。我认为这是一个值得发表的答案。
– Alaa Ali
13年8月18日在19:01
为什么使用384k作为块大小？
–迭戈·费尔南德斯·杜兰（DiegoFernándezDurán）
2014年6月2日14:39
@Diego没有理由。这只是一个例子。您可以使用其他任何东西。 （大约4k ... 1M之间）当然，更大的块大小将提供更好的性能。当然，当您使用大bs时，请减少计数数量，否则将需要一年时间才能完成。
–电话
2014年7月25日下午0:17
基准测试工具（例如iozone和sysbench的数量）要低得多，因此不可靠
– MSS
16年8月27日10:00
在使用零写入数据时要小心-一些文件系统和磁盘将具有特殊的路径（以及其他可压缩数据），这将导致人为地提高基准值。
–阿农
18年11月12日在7:38
#3 楼
如果需要准确性，则应使用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缓存已满，性能就会发生变化（例如具有20-50 GB SLC缓存的Samsung EVO系列） 。另一个示例是，Seagate SMR HDD具有大约20 GB的PMR高速缓存区域，具有相当高的性能，但是一旦装满，直接写入SMR区域可能会将性能从原始数据降低10％。看到这种性能下降的唯一方法是首先尽可能快地写入20+ GB，然后立即继续进行实际测试。当然，这全都取决于您的工作量：如果您的写访问是突发性的，并且具有较长的延迟（允许设备清理内部缓存），则较短的测试序列将更好地反映您的实际性能。如果需要执行大量IO，则需要同时增加
--io_size和--runtime参数。请注意，某些媒体（例如，最便宜的闪存设备）会受到此类测试的影响，因为闪存芯片的质量很差，足以很快磨损。我认为，如果任何设备的性能足以应付此类测试，则无论如何都不应使用它来保存任何有价值的数据。就是说，不要重复进行大笔写入测试1000次，因为所有闪存单元在写入时都会有一定程度的磨损。另外，某些高质量的SSD设备可能具有更智能的损耗平衡算法，其中内部SLC缓存具有足够的智能，可以替换测试中在相同地址空间（即是否测试到相同地址空间）中正在重写的数据。文件小于总SLC缓存（设备始终仅写入SLC缓存）。对于此类设备，文件大小再次开始变得重要。如果您需要实际的工作负载，则最好使用实际会看到的文件大小进行测试。否则，您的数字可能看起来太好。
请注意，
fio会在首次运行时创建所需的临时文件。它将填充随机数据，以避免从试图通过将数据写入永久存储之前压缩数据来欺骗基准的设备获得过多的数据。在上面的示例中，该临时文件将称为fio-tempfile.dat并存储在当前工作目录中。因此，您应该首先更改到要测试的设备上安装的目录。 fio还支持使用直接介质作为测试目标，但是我强烈建议您在尝试之前阅读手册页，因为当使用直接存储介质访问（例如，写入OS设备而不是测试设备）时，错字可能会覆盖整个操作系统。 如果您拥有良好的SSD，并且希望看到更多的数字，请在上面增加
--numjobs。这定义了读写的并发性。上面的示例都将numjobs设置为1，因此测试是关于单线程进程的读写（可能是将队列设置为iodepth）。高端SSD（例如Intel Optane 905p）即使不增加很多numjobs也应该获得高数量（例如4应该足以获得最高规格数），但是某些“企业” SSD要求范围在32-128范围内因为这些设备的内部延迟较高，但总体吞吐量却很疯狂。评论
我只是重新测试了一些设备。使用上述顺序读取测试（2MB块大小），我从Samsung SSD 850 EVO中获得了280 MB / s的速度，而从Intel 910 SSD中获得了1070 MB / s的速度。使用64k块大小和其他相同的命令行，我从850 EVO中获得了268 MB / s，从910 SSD中获得了1055 MB / s。至少对于这种类型的设备，使用2 MB的块大小似乎可以将结果提高1-5％，即使这会导致内核将请求拆分给硬件。我想即使使用内核优化，提交更多系统调用的开销也比在内核内部拆分更糟糕。
– Mikko Rantalainen
18年6月26日在7:07
经过进一步测试，似乎我使用小于max_sectors_kb的2的幂获得了最高的顺序吞吐量。我将上面的示例命令更改为使用1 MB的块大小，因为这似乎可以在实际的硬件上使用。而且我还测试了fsync对阅读没有影响。
– Mikko Rantalainen
18年6月26日在7:18
根据驱动器的连接方式，您可能会发现iodepth太低。您将必须观察Linux实际向设备发送的内容以及它在该设备上执行的深度...
–阿农
18年6月26日在20:28
我将iodepth设置为1以进行随机访问正是因为现实世界中的程序经常运行的算法/逻辑深度不能大于1。因此，如果这种深度“太低”，则您的I / O设备就不好了。的确，某些SSD设备将受益于深度大于32的深度。但是，您能否指出任何需要读取访问权限并能够保持IO深度大于32的实际工作负载？ TL; DR：如果您想通过高延迟设备重现一些疯狂的高读取基准数字，请使用iodepth = 256 --numjobs = 4，但不要期望看到这样的数字是真实的。
– Mikko Rantalainen
18年7月3日在7:46
大多数“现实世界”程序实际上并没有直接提交I / O（o_），更不用说异步了，因此我们所有的示例都处在异常的工作量中，以推动极限基准领域（正如他们所说，最好的基准是您的实际工作量）。话虽这么说，诸如运行多个繁忙的虚拟机之类的事情很容易就能产生疯狂的高深度工作负载，但是从磁盘角度来看，I / O常常看起来是随机的，这是一个简单的示例，说明可以从诸如此类的事物中看到巨大的加速NVMe。 PS：将数字设置得过高会降低吞吐量，因此有一个不错的选择...
–阿农
18年7月4日在18:33
#4 楼
我不建议使用/dev/urandom，因为它基于软件且运行缓慢。最好在随机磁盘上获取大块随机数据。在硬盘测试中，随机无关紧要，因为每个字节均按原样写入（在dd的ssd上也是如此）。但是，如果我们用纯零或随机数据测试去重复的zfs池，则会有巨大的性能差异。另一个观点必须是同步时间的包含。所有现代文件系统都在文件操作上使用缓存。
要真正衡量磁盘速度而不是内存，我们必须同步文件系统以摆脱缓存效果。可以很容易地做到：
time sh -c "dd if=/dev/zero of=testfile bs=100k count=1k && sync"
使用该方法，您将获得输出：磁盘数据速率仅为104857600 / 0.441 = 237772335 B / s-> 237MB / s
比缓存低100MB / s。
基准测试愉快，
/>
评论
使用零写入数据时要小心-一些磁盘（例如SSD）和某些文件系统将具有特殊情况下的路径。使用零缓冲区时，这会导致人为地导致较高的基准数字。其他高度可压缩的数据模式也会使结果失真。
–阿农
18-11-12在7:40
#5 楼
如果要实时监视磁盘的读写速度，则可以使用iotop工具。对于获取有关磁盘在特定应用程序或工作负载下的性能的信息很有用。输出将显示每个进程的读取/写入速度以及服务器的总读取/写入速度，类似于
top。安装
iotop：sudo apt-get install iotop
运行它：
sudo iotop
与更常规和理论上的测试相比，该工具有助于了解磁盘在特定工作负载下的性能。
#6 楼
bonnie ++是我知道的用于Linux的最终基准测试实用程序。（我目前正在准备在bonnie ++上工作的linux livecd，以使用它测试基于Windows的计算机！）
它负责缓存，同步，随机数据，磁盘上的随机位置，小尺寸更新，大更新，读取，写入等。比较USB密钥，硬盘（旋转），固态驱动器和硬盘。基于ram的文件系统对于新手可能非常有用。
我不知道它是否包含在Ubuntu中，但是您可以轻松地从源代码进行编译。
http： //www.coker.com.au/bonnie++/
评论
Bonnie在磁盘基准测试方面存在缺陷，可以轻松生成实际反映系统非磁盘方面的数字，因此如果您选择使用它，则需要格外小心。有关详细信息，请参见Brendan Gregg的Active Benchmarking：Bonnie ++。
–阿农
19年1月12日在5:52
#7 楼
写入速度$ 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
评论
在使用零写入数据时要小心-一些文件系统和磁盘将具有特殊的路径（以及其他可压缩数据），这将导致人为地提高基准值。
–阿农
18年11月12日在7:35
#8 楼
有关如何使用Bonnie ++的一些提示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 ++示例。
评论
在unix.stackexchange.com/questions/108838/…、stackoverflow.com/questions/1198691/…和serverfault.com/questions/219739/…上也提出了类似的问题。