![I/O 性能基准测试 Linux](https://linux22.com/image/534946/I%2FO%20%E6%80%A7%E8%83%BD%E5%9F%BA%E5%87%86%E6%B5%8B%E8%AF%95%20Linux.png)
刚刚用 iSCSI 设置好了一个穷人版 SAN,想对其进行基准测试。除了以下之外,还有哪些 Linux 的良好 I/O 性能基准测试:
hdparm -tT /dev/sda1
如何获取 IOPS 测量值?
谢谢。
答案1
我建议使用邦尼++用于磁盘性能测试。它是专门为做这种事情而设计的。
答案2
至少在 Linux 上,所有综合基准测试答案都应该提到菲奥- 它确实是一把瑞士军刀 I/O 生成器。
其功能简要概述:
- 它可以生成对设备或文件的 I/O
- 使用多种不同的方法提交 I/O
- 同步、psync、vsync
- 本机/posix aio、mmap、splice
- 将 I/O 排队至指定深度
- 指定提交 I/O 的大小
- 指定 I/O 类型
- 顺序/随机
- 如果 I/O 是随机的,你可以指定要使其偏向哪种分布,以使其更加真实
- 读/写或两者的混合
- 记录的 I/O
blktrace
可以重放
- 顺序/随机
它提供的统计数据涵盖
- 生成的 I/O 数量(以 MB 为单位)
- 平均带宽
- 提交/完成延迟的最小值、最大值、平均值和标准差
- 每秒输入/输出次数
- 平均队列深度
这功能和输出列表不断地。
它最终不会生成一个代表一切的统一数字,但如果你认真了解存储性能,你就会知道单个数字无法解释你需要知道的一切。甚至 Linus Torvalds 也认为 fio 很好:
[G]et Jens 的 FIO 代码。它做对了 [...] 其他一切都值得怀疑 - 忘记 bonnie 或其他传统工具吧。
Brendan Gregg(Netflix 性能工程师)也对 fio 给予了积极评价:
我最喜欢的其他基准测试是 fio@axboe[...]
PS:你打算在网站/论文等上发布使用 fio 进行的基准测试吗?别忘了关注https://github.com/axboe/fio/blob/master/MORAL-LICENSE!
答案3
我建议你阅读这两篇帖子/文章:
http://www.linuxinsight.com/how_fast_is_your_disk.html http://www.linuxforums.org/forum/red-hat-fedora-linux/153927-iscsi-raid1-lvm-setup-poor-write-performance.html
尤其:
首先,我建议您使用更准确、更可控的工具来测试性能。hdparm 旨在更改 IDE 设备参数,它所做的测试非常基础。在 LVM 和 iSCSI 上的复合设备上使用 hdparm 时,您也无法知道发生了什么。此外,hdparm 不测试写入速度,这与读取速度无关,因为两者都有不同的优化(写回缓存、预读和预取算法等)。
我更喜欢使用老旧而又好用的 dd 命令,它允许您精细控制块大小、测试长度和缓冲区缓存的使用。它还会为您提供一份简短而漂亮的传输速率报告。您还可以选择测试缓冲区缓存性能。
另外,请注意这里涉及到几个层,包括文件系统。hdparm 仅测试对 RAW 设备的访问。
测试命令我建议使用以下命令进行测试:
a) 对于原始设备、分区、LVM 卷、软件 RAID、iSCSI LUN(启动器端)。1M 的块大小足以测试大多数现代设备的批量传输速度。对于 TPS 测试,请使用 4k 等小尺寸。更改计数以进行更真实的测试(我建议进行长时间测试以测试持续速率对瞬时干扰的影响)。“odirect”标志避免使用缓冲区缓存,因此测试结果应该是可重复的。
读取测试:dd if=/dev/zero of=/dev/ bs=1M count=1024 oflag=direct 写入测试:dd if=/dev/ of=/dev/null bs=1M count=1024 iflag=direct
具有 512x1M 块的 dd 的示例输出:已复制 536870912 字节(537 MB),10.1154 秒,53.1 MB/s
写入测试具有破坏性!!!!您应该在设备上创建文件系统之前执行此操作!!!!在原始设备上,请注意分区表将被删除。在这种情况下,您应该强制内核重新读取分区表以避免出现问题(使用 fdisk)。但是,整个设备和单个分区上的性能应该相同。
b) 对于文件系统,只需将设备更改为挂载点下的文件名即可。 读取测试:dd if=/dev/zero of=/mount-point/test.dat bs=1M count=1024 oflag=direct 写入测试:dd if=/mount-point/test.dat of=/dev/null bs=1M count=1024 iflag=direct
请注意,即使访问文件,我们也不会使用缓冲区缓存。
c) 对于网络,只需在服务器之间的两个方向上测试原始 TCP 套接字。注意防火墙阻止 TCP 端口 5001。
服务器 1# dd if=/dev/zero bs=1M count=1024 | netcat 5001 服务器 2# netcat -l -p 5001 | dd of=/dev/null
测试层现在您有一个工具可以测试每个层的磁盘性能。只需按照以下顺序操作即可:
a) 测试 iSCSI 服务器上的本地磁盘性能。b) 测试 iSCSI 目标和启动器之间的网络 TCP 性能。c) 测试 iSCSI 启动器上的 iSCSI LUN 上的磁盘性能(这是 iSCSI 协议的最终原始性能)。d) 测试 LVM 逻辑卷上的性能。e) 测试文件系统上大文件的性能。
造成丢失的层和下一层之间的性能差距应该很大。但我不认为这是 LVM。我怀疑是文件系统层。
现在针对可能出现的问题提出一些建议:
a) 您没有描述是否在 iSCSI LUN 上定义了剥离的 LVM 卷。如果在 iSCSI 目标上使用同步写入,剥离可能会造成瓶颈(请参阅下面的 atime 问题)。请记住,默认的 iSCSI 目标行为是同步写入(无 RAM 缓存)。b) 您没有描述文件的访问模式类型:-大量数据的长顺序传输(100 MB)?-小块随机访问序列?-许多小文件?
我可能错了,但我怀疑您的系统可能受到“ATIME”问题的影响。“atime”问题是“关于 Linux 内核设计的原始想法”的结果,过去几年我们一直深受其害,因为人们热衷于参与操作系统的设计,但对性能和设计决策的影响却不熟悉。
简单说一下。近 40 年来,UNIX 每次对文件执行单个读/写操作时都会更新 inode 的“上次访问时间”。缓冲区缓存保存暂时不会传播到磁盘的数据更新。然而,在 Linux 设计中,每次对 inode 的 ATIME 的更新都必须同步且立即更新到磁盘。只需意识到在 iSCSI 协议之上的操作流中交错同步传输的含义。
要检查这是否适用,只需进行以下测试: - 不使用缓存,读取一个长文件(至少 30 秒)。当然是用 dd!!! - 同时,用“iostat -k 5”监控 I/O。
如果在读取数据时观察到少量但连续的写入操作流,则可能是 inode 更新。
解决方案:Linux 的情况变得非常奇怪,他们为一些文件系统(XFS、EXT3 等)添加了挂载选项,以禁用 atime 的更新。当然,这使得文件系统语义与 POSIX 标准不同。一些观察文件上次访问时间的应用程序可能会失败(主要是电子邮件阅读器和服务器,如 pine、elm、Cyrus 等)。只需使用选项“noatime,nodiratime”重新挂载文件系统即可。最近的发行版中还有一个“norelatime”,可以减少 inode 的“atime”过时。
请记录下这些测试的结果和您的调查结果。
答案4
磁盘基准测试:
$ dd if=/dev/zero of=/tmp/zero bs=1k count=100k
网络基准测试:
$ yes | pv | ssh $host "cat > /dev/null"