我在很多地方看到吞吐量= bs * iops应该是真的。 例如，以128k块大小写入可以支持190 IOPS的SAS磁盘，应该可以达到〜23 MBps- 23.75(MBs) = 128(BS)*190(SAS-15 IOPS)/1024的吞吐量。
现在，当我在一个虚拟机上对一个怪物NetApp filer进行testing时，我得到了以下结果：
# dd if=/dev/zero of=/tmp/dd.out bs=4k count=2097152 8589934592 bytes (8.6 GB) copied, 61.5996 seconds, 139 MB/s
要查看使用iostat和esxtop的虚拟机的IO速率，他们都显示大约250 IOPS。
所以据我的理解，吞吐量应该是〜1000k： 1000(KBs) = 4(BS)*250(IOPS) 。
8GB的dd是RAM的两倍，所以在这里没有页面caching。
我错过了什么？
谢谢！
你缺less的是上下文。 IOPS是完全随机的。 副本不是随机的，而是顺序的。 当磁头移动时，硬盘变慢 – IOPS基本上假设，正确测量，随机分布在整个磁盘（或至less是其中的大部分）上的IO。
是的，复制光盘时速度会快很多。 SADLY这是完全不相干的，除非你的正常使用只能由一个用户一次复制。
这就好比测量一级方程式赛车的最高速度，然后假设这是一场比赛中的平均速度 – 糟糕的马厩，公式1赛道有弯道，赛车大部分都慢了很多。
因此，如果你不做完全退化的模式（在技术术语中），即一次只有一个拷贝操作，那么IO将是随机的（特别是虚拟机 – 一个可能是连续的，20个是同一个盘是随机的），头部大部分时间都在移动，而不是进行IO操作。
8GB的dd是内存大小的两倍
它仍然是可悲的，是不是？ 这个光盘怎么样？ （gb只是一小部分，所以与随机场景相比，“随机”部分是非常less的运动（以长度衡量）;）实际上没有随机运动从零源复制，所以只能写，不能运动头部。 坏的;）
在上面：
反对一个怪物NetApp文件pipe理器
任何想法这些大型SAN项目能够优化您的IO多less？ 它有多lesscaching？ 一个“怪物”文件pipe理器将是最高的模型之一，它有自己的caching使用16千兆以上的ememory。 如果它是一个怪物，你的文件是可悲的 – 维基百科读取2010年（！）有192GB内存的顶部线;）甚至没有意识到缓冲8GB的时候。 重复数据删除（是否实时发生？）可能会消除几乎所有的写入操作。 你确定你甚至测量了基于磁盘的IOPS？
有一个名为SQLIO的应用程序，不用担心这个名字实际上与SQL无关，它只是由Microsoft的SQL Server团队编写的，它可以让你用随机IO（读或写）testing你的磁盘，并看到只是多less负载的磁盘可以处理。 你可以从微软的网站下载。
如果要使用throughput = block size * IOPS ，则必须使用正在计算的I / O操作的块大小，而不是文件系统的块大小，而不是块设备的块大小。
139MB / s可能比你真正得到的要高一些，因为当测量停止时I / O可能会继续。 块caching可能仍然冲洗。 所以看起来最合理的解释是，你计算的底层I / O操作的大小是512KB。
I / O操作的块大小必须是块设备块大小的几倍。 我相信你说这是128KB。 所以512KB（4块）操作当然是可能的。
512 * 250 = 128MB / s