slm*_*slm 59 linux hard-disk benchmark
我已经看到使用以下命令对一个人的 HDD 进行基准测试dd：
$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"
还有比这更好的方法吗？
slm*_*slm 67
我通常用来hdparm对我的硬盘进行基准测试。您可以对直接读取和缓存读取进行基准测试。您需要多次运行命令以建立平均值。
这是直接阅读。
$ 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在命令完成后删除。注意： ddfile是一个不需要保留的临时文件，它dd是写入 ( of=ddfile)的文件，当它使您的 HDD 处于负载状态时。
如果您需要对硬盘进行更严格的测试，您可以使用Bonnie++。
Ano*_*non 27
（这是一个非常热门的一个问题-你可以看到它的变化/sf/ask/83908401/，https://serverfault.com/q/219739/203726和https://askubuntu.com/q /87035/740413 )
是否有[比 dd] 更好的方法来[基准磁盘]？
是的，但它们需要更长的时间才能运行，并且需要了解如何解释结果 - 没有一个数字可以一次性告诉您所有信息，因为以下因素会影响您应该运行的测试类型：
等等。
这是一个简短的工具列表，其中最容易在顶部运行，而在底部附近较难/更彻底/更好：
Greg - 获取 Jens 的 FIO 代码。它做正确的事情，包括写入实际的伪随机内容，显示磁盘是否进行了一些“重复数据删除”（也称为“针对基准进行优化）：
[ https://github.com/axboe/fio/ ]
其他任何事情都值得怀疑 - 忘记 bonnie 或其他传统工具。
资料来源：Linus Torvalds 在 Google Plus 上对 Greg Kroah-Hartman 的评论。
Tho*_*erk 11
如果您懒得阅读所有这些，我建议您使用IOPS 工具。它会根据块大小告诉您实际速度。
否则 - 在进行 IO 基准测试时，我会查看以下内容：
CPU利用率
您将使用哪个块大小：如果您想从/向磁盘读/写 1 GB，如果您执行一次 I/O 操作，这将很快。但是，如果您的应用程序需要在整个硬盘中以非顺序片（称为随机 I/O，尽管它不是随机的）的形式写入 512 字节的块，这看起来会有所不同。现在，由于其性质，数据库将对数据卷进行随机 I/O，对日志卷进行顺序 I/O 。所以，首先你需要弄清楚你想要测量什么。如果您想复制与安装 Linux 不同的大型视频文件。
此块大小会影响您执行的 I/O 操作数。如果您执行例如 8 个顺序读取（或写入，只是不混合）操作，操作系统的 I/O 调度程序将合并它们。如果没有，控制器的缓存将进行合并。如果您读取 8 个 512 字节的连续块或一个 4096 字节的块，实际上没有区别。一个例外 - 如果您设法进行直接同步 IO 并在请求下一个 512 字节之前等待 512 字节。在这种情况下，增加块大小就像添加缓存。
此外，您应该知道有同步和异步 IO：使用同步 IO，您不会在当前请求返回之前发出下一个 IO 请求。使用异步 IO，您可以请求例如 10 块数据，然后在它们到达时等待。不同的数据库线程通常将同步 IO 用于日志，将异步 IO 用于数据。IOPS 工具通过测量从 512 字节开始的所有相关块大小来解决这个问题。
你会读还是写：通常阅读比写作快。但请注意，缓存对读取和写入的工作方式完全不同：
对于写入，数据将被移交给控制器，如果它缓存，除非缓存已满，否则它将在数据在磁盘上之前确认。使用iozone工具，您可以绘制精美的缓存效果高原图（CPU 缓存效果和缓冲区缓存效果）。写入的越多，缓存的效率就越低。
对于读取，读取数据在第一次读取后保存在缓存中。第一次读取花费的时间最长，并且在正常运行期间缓存变得越来越有效。值得注意的缓存是 CPU 缓存、操作系统的文件系统缓存、IO 控制器的缓存和存储的缓存。IOPS 工具仅测量读取。这允许它“到处读取”并且您不希望它写入而不是读取。
您将使用多少线程：如果您使用一个线程（使用 dd 进行磁盘基准测试），与使用多个线程相比，性能可能会差很多。IOPS 工具会考虑到这一点并读取多个线程。
延迟对您来说有多重要：查看数据库，IO 延迟变得非常重要。任何插入/更新/删除 SQL 命令都将在确认之前在提交时写入数据库日志（数据库术语中的“日志”）。这意味着完整的数据库可能正在等待此 IO 操作完成。我在这里展示了如何使用iostat 工具测量平均等待时间 (await) 。
CPU 利用率对您来说有多重要：您的 CPU 很容易成为应用程序性能的瓶颈。在这种情况下，您必须知道每个字节读/写消耗多少 CPU 周期并优化到该方向。这可能意味着根据您的测量结果决定是否使用 PCIe 闪存。同样，iostat 工具可以通过 IO 操作粗略估计 CPU 利用率。
您可以使用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 与 ~ 30 MiB/s 的速率）。
小智 8
如果你已经安装了 PostgreSQL，你可以使用他们优秀的pg_test_fsync基准测试。它基本上测试您的写入同步性能。
在 Ubuntu 上，您可以在这里找到它： /usr/lib/postgresql/9.5/bin/pg_test_fsync
关于它的好处是，该工具将向您展示为什么企业级 SSD 值得多花一美元。