6.2.3 读写速率
文章插图
表3：两个GFS集群的性能度量
表3中显示了持续时间不同的读写速率 ， 两个集群在做这些测试前都已经运行了大概一个星期的时间 。（这两个集群是因为GFS更新到新版本而进行重启 。）
自从重启后，平均写速率一直小于30MB/s 。当我们做这些测试时，B正在进行速率为100MB/s的大量写操作，因为写操作被传送到三个副本上，所以将产生300MB/s的网络负载 。
读速率要达到高于写速率 。如我们设想的那样，整个工作由更多的读操作组成 。两个集群都在进行繁重的读操作，特别是，集群A在前些周维持了580MB/s的读速率 。它的网络配置能够支持750MB/s的速率，所以它有效的利用了它的资源 。集群B支持的极限读速率为1300MB/s，但是，它的应用只用到了380MB/s 。
6.2.4 Master复制表3也显示了发往Master的操作速率 ， 每秒有200-500个操作 。Master可以轻松的应对这个速率，因此Master的处理性能不是瓶颈 。
在早期的GFS版本中 ， Master有时会成为瓶颈 。它花费大多数时间连续的浏览大的目录（可能含有几百几千个文件）来查找指定的文件 。我们已经改变了Master的数据结构，使用二分查找在命名空间中进行查找，以此提高效率 。它也能轻松的支持每秒数千次的文件访问 。如果需要 ， 我们能通过在命名空间数据结构之前放置名字查询缓存的方法来进一步提高速度 。
6.2.5 恢
推荐阅读
- JAVA的File对象
- Codeforces 1670 E. Hemose on the Tree
- 二 沁恒CH32V003: Ubuntu20.04 MRS和Makefile开发环境配置
- 驱动开发：内核监控FileObject文件回调
- 齐博X1-栏目的调用2
- Blazor组件自做十一 : File System Access 文件系统访问 组件
- How to get the return value of the setTimeout inner function in js All In One
- System.IO.FileSystemWatcher的坑
- Docker | dockerfile构建centos镜像，以及CMD和ENTRYPOINT的区别
- prometheus监控实战