我遇到了一个我认为非常奇怪的性能问题
我有一个应用程序，它处理一些数据并创建大约 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 限制将被忽略。