![FreeBSD 10 上的 zfs](https://linux22.com/image/700718/FreeBSD%2010%20%E4%B8%8A%E7%9A%84%20zfs.png)
我遇到了一个我认为非常奇怪的性能问题
我有一个应用程序,它处理一些数据并创建大约 100GB 的文件。它运行良好,之后我可以将文件从机器上 scp 下来。本地磁盘是 ZFS,也许这就是问题所在。
但是,如果我在复制文件之前运行另一个对文件进行 mmap 并交换文件字节的实用程序,则文件:1) 从固态磁盘传输速度会慢得多,可能只有 50mb/s(或更差),systat -iostat 会显示更高的磁盘事务级别。2) 机器的有线内存会爆满,以容纳 70+ GB 的 ARC。70GB 的 arc 似乎很荒谬,因为这大约是本地磁盘存储的四分之一。如果在传输后删除文件,ARC 会丢失,但有线内存似乎不会丢失。有什么想法吗?
答案1
mmap()
非 Solaris 平台上的 ZFS用于写入数据时性能似乎很差。
解决 zfs 上 mmap 性能不佳的问题
我在 Solaris 10u9 的 zfs 上运行的基于 mmap 的数据库(mongodb)的性能不佳。
...
那是在 Solaris 的旧版本上。这很重要,因为来自 FreeBSD 邮件列表的 2016 年 7 月主题(强调添加):
简而言之:ZFS 被附加在内核上,并且从未正确集成到 VM 页面管理中,这导致使用 mmap() 进行写入 IO 的任何设备的性能都非常差。在 Opensolaris 再次闭源后,Oracle Solaris 通过出色的 VM 分配器重写解决了这个问题。
如果不彻底重写 VM 系统,这个问题就无法解决。
和这次跟进:
... 自最初导入以来,几乎没有采取任何措施来改善集成,而且我不知道有谁能胜任这项任务并对此感兴趣。因此,在可预见的未来,mmap() 的性能可能“注定”会下降。
因此该问题在 Solaris 上已得到修复,但在 FreeBSD 上尚未修复。
如果您需要更快的mmap()
性能,我建议您大幅限制 ZFS ARC 的大小。这应该可以减少mmap()
使用的页面缓存和 ARC 之间的一致性问题的影响。可能提高性能。不过,也许不会。但值得一试。只是不要太小,否则你的 ARC 限制将被忽略。