1

我有一个包含几亿个文件（几 PB）的文件系统，我想获取 stat 将返回的几乎所有内容并将其存储在某种数据库中。现在，我们有一个 MPI 程序，它从中央队列和工作节点提供目录名称，这些工作节点通过 stat 调用来猛击 NFS（它可以在不费力的情况下处理这个问题）。然后工作节点点击 postgres 来存储结果。

虽然这有效，但速度很慢。在现代 30 节点集群上，单次运行将需要 24 小时以上。

有没有人对拆分目录结构而不是集中队列有任何想法（我的印象是，为此的确切算法是 NP 难的）？另外，我一直在考虑用 MongoDB 的自动分片和多个路由器替换 postgres（因为 postgres 目前是一个巨大的瓶颈）。

我几乎只是在寻找有关如何改进此设置的一般想法。

不幸的是，使用诸如 2.6 内核审计子系统之类的东西可能是不可能的，因为在每台命中该文件系统的机器上运行它（以政治方式）将是极其困难的。

如果重要的话，每台使用这个文件系统的机器（几千台）都在运行 linux 2.6.x。

这样做的实际主要目的是查找早于某个日期的文件，以便我们能够删除它们。我们还希望收集有关文件系统使用方式的一般数据。

4

2 回答 2

1

扩展我的评论。

将文件放在中心位置是最大的瓶颈之一。如果您不能以其他方式优化文件系统访问时间，那么最好的方法可能是让一个（或几个）工作人员进行stat调用。添加两个以上的工作人员不会提高性能，因为他们都在访问同一个文件系统。

正因为如此，我认为将工作人员放在文件系统所在的节点上（而不是通过 NFS 访问它）应该会给你带来很大的性能提升。

另一方面，可以通过更改数据库引擎来优化数据库写入。正如评论中所预期的那样，Redis键值模型更适合这样的任务（是的，它非常快）：您可以使用其哈希类型来存储stat使用完整路径名作为键的调用结果。

此外，redis 还将在不久的将来支持集群。

于 2011-08-04T22:10:31.440 回答
0

我们最终为此创建了自己的解决方案（使用 redis）。我们已将运行它的时间从大约 24 小时缩短到大约 2.5 小时。

于 2011-10-11T20:20:43.807 回答