![吞吐量=BS*IOPS?](https://linux22.com/image/581482/%E5%90%9E%E5%90%90%E9%87%8F%3DBS*IOPS%EF%BC%9F.png)
我在很多地方都看到吞吐量 = bs * iops 应该是正确的。例如,以 128k 块大小写入可以支持 190 IOPS 的 SAS 磁盘应该能获得 ~23 MBps 的吞吐量 -
23.75(MBs) = 128(BS)*190(SAS-15 IOPS)/1024
。
现在,当我在虚拟机中针对庞大的 NetApp 文件服务器进行测试时,我得到了以下结果:
# dd if=/dev/zero of=/tmp/dd.out bs=4k count=2097152
8589934592 bytes (8.6 GB) copied, 61.5996 seconds, 139 MB/s
为了查看虚拟机的 IO 速率,我使用了 iostat 和 esxtop,它们都显示大约 250 IOPS。
所以据我理解吞吐量应该是~1000k
1000(KBs) = 4(BS)*250(IOPS)
:。
8GB 的 dd 当然是 RAM 的两倍,所以这里没有页面缓存。
我错过了什么?
谢谢!
答案1
您缺少的是上下文。IOPS 是完全随机的。复制不是随机的,而是连续的。当磁头移动时,硬盘会变慢 - IOPS 基本上假设,经过适当测量,IO 随机分布在整个磁盘盘片上(或至少是其中很大一部分)。
是的,复制光盘时速度会快很多。遗憾的是,除非您的正常使用情况是每次仅由一个用户复制,否则这完全无关紧要。
这就像测量一级方程式赛车的最高速度,然后假设这是比赛期间的平均速度——赛道状况不佳,一级方程式赛道有弯道,赛车的速度大多要慢得多。
因此,如果您不执行完全退化的模式(技术术语),即一次只进行一次复制操作,则 IO 将是随机的(尤其是虚拟机 - 一个可能是连续的,20 个击中同一个光盘是随机的)并且头部大部分时间都在移动,而不是执行 IO 操作。
8GB 的 dd 是 RAM 大小的两倍
这仍然很可悲,不是吗?光盘有多大?(gb 只是一小部分,因此与现实世界的情况相比,“随机”部分的运动(以长度衡量)非常少;)实际上,当您从零源复制时,没有随机运动,所以它只是写入,从不移动磁头。糟糕;)
在上面:
对抗庞大的 NetApp 文件服务器
知道这些大型 SAN 项目能够优化您的 IO 到什么程度吗?它有多少缓存?“怪物”文件管理器将是顶级型号之一,它拥有 16+ GB 的内存供其自身缓存使用。如果它真的是怪物,那么您的文件就太可怜了 - 维基百科显示 2010 年的顶线 (!) 拥有 192GB 内存;)缓冲 8GB 时甚至没有意识到。而且重复数据删除(它是实时发生的吗?)可能会消除几乎所有的写入操作。您确定您甚至测量了基于磁盘的 IOPS 吗?
答案2
有一款名为 SQLIO 的应用程序,别担心它的名字,它实际上与 SQL 无关,它只是由 Microsoft 的 SQL Server 团队编写的,它可以让您使用随机 IO(读取或写入)测试磁盘,并查看磁盘可以处理多少负载。您可以从 Microsoft 的网站下载它。
答案3
如果您要使用throughput = block size * IOPS
,则必须使用您正在计算的 I/O 操作的块大小,而不是文件系统的块大小,而不是块设备的块大小。
139MB/s 可能比您实际得到的结果略高,因为测量停止时 I/O 可能仍在继续。块缓存可能仍在刷新。因此,最合理的解释似乎是您正在计算的底层 I/O 操作的大小为 512KB。
I/O 操作的块大小必须是块设备块大小的某个倍数。我相信你说的是 128KB。因此 512KB(4 个块)操作肯定是可能的。
512 * 250 = 128MB/秒