注意
本文档适用于 Ceph 开发版本。
分布式文件系统的应用最佳实践
CephFS 是 POSIX 兼容的,因此应该可以与任何期望 POSIX 文件系统的现有应用程序一起工作。然而,因为它是一个网络文件系统(与例如 XFS 不同)并且具有高度一致性(与例如 NFS 不同),因此应用程序作者可能会受益于了解一些后果。
以下几节描述了分布式文件系统在某些方面可能与本地文件系统有显著不同的性能行为。
ls -l
当你运行“ls -l”时,ls
程序stat
。
这通常远远超出了应用程序实际需要的范围,并且对于大目录来说可能很慢。如果你真的不需要每个文件的所有这些元数据,那么使用一个简单的ls
.
对正在扩展的文件进行 ls/stat
如果另一个客户端当前正在扩展列表中的文件,那么一个ls -l
可能需要异常长的时间来完成,因为真的需要知道目录中每个文件的确切大小,那就不要这样做!
这也适用于任何直接对从另一个节点追加的文件发出stat
系统调用的应用程序代码。
非常大的目录
你真的需要那个 10,000,000 文件目录吗?虽然目录碎片化使 CephFS 能够处理它,但它始终不如将你的文件分成更适度的目录效率高。
即使是标准的用户空间工具在处理非常大的目录时也可能变得相当慢。例如,ls
的默认行为是给出按字母顺序排列的结果,但是readdir
系统调用不会给出有序的结果(这通常是真的,不仅仅是 CephFS)。所以当你ls
在一个包含百万个文件的目录上时,它正在将一个包含百万个名称的列表加载到内存中,对列表进行排序,然后将它写入显示。
硬链接
硬链接在文件系统内部维护对相同数据的两个引用方面有一定的成本。在 CephFS 中,存在特定的性能成本,因为对于普通文件,inode 嵌入在目录中(即查找路径后没有额外的 inode 获取)。
工作集大小
MDS 作为存储在 RADOS 中的元数据的缓存。对于元数据适合于该缓存的工作负载,元数据性能差异很大。
如果你的工作负载中的文件数量多于缓存中可以容纳的数量(使用mds_cache_memory_limit
设置配置),那么请确保你进行适当的测试:不要用少量文件测试你的系统,然后期望在迁移到大量文件时获得相当的性能。
你需要文件系统吗?
请记住 Ceph 还包括一个对象存储接口。如果你的应用程序需要存储大量的扁平文件集合,你只是逐个读取和写入整个文件,那么你可能会更愿意使用Object Gateway
由 Ceph 基金会带给您
Ceph 文档是一个社区资源,由非盈利的 Ceph 基金会资助和托管Ceph Foundation. 如果您想支持这一点和我们的其他工作,请考虑加入现在加入.