我不得不拥有这个目录结构/ var / www / $ WEBSITE / $ DIR1 / $ DIR2 / $ FILES
对于每个$ FILES，大约有50,000个XHTML页面。
我正在运行切诺基，它有新的前端caching支持。 但是我有点内存有限，所以我无法caching整个事情。 我相信我可以caching上市，这是最糟糕的部分。
我可以在文件系统方面做些什么？ 我通常使用ext4（我的服务器使用ext3），但我知道ReiserFS是这种情况的首选。 我可能只是在ReiserFS中挂载$ WEBSITE。 我真的不希望重新分配的东西，并愿意解决这个问题。
我可以在文件系统的某个地方做一个交错的子目录，只需将它们全部符号链接到$ DIR2？ 这会不会有助于使这种恶劣的情况performance更好，从ext3减less痛苦？
我真的不想要任何RDB，我会考虑一个NOSQL选项如果我能以某种方式从它创build一个人造文件系统。 这将是一个很酷的select，只是不确定它甚至存在。 可能是FUSE相关的东西存在？
整个网站已经存在了，基本上只是一个奇特的目录列表。 文件被写入一次，然后从那里读取。 从这一点来看，每个目录下的文件数目不会增加。
50,000个文件不应该足以在Linux上引起严重的速度问题。 你提到caching列表，所以我认为你正在对文件进行一些处理，而不是简单的服务。 我会寻找如何处理文件的问题。
我build议XFS有一个可能的例外：如果您经常需要从该目录树中删除大量文件，则在XFS中删除性能不是很好。 尽pipe如此，新的delaylog挂载参数已经有所改进。
除此之外，XFS甚至不会在目录中有5万个文件。
你可以试试XFS。 我在XFS文件系统上运行大型目录，效果很好。 ls ， du和其他文件操作明显好于ext3。 不pipe怎样，为了可伸缩性，开发一个更干净的目录结构可能是有意义的。
[root@bootylicious /data/print]# ls -1 | wc -l 431801
我find了解决我的问题
我的财务总监performance让我感到不舒服只有~5000个文件，这就是为什么我发布这个问题。 我通常会使用Ext4，并使用XFS; 这一直是一个坚实的执行者; 但是我已经在Ext3上安装了所有东西。
Ext4默认情况下启用了Htree索引，这将使得这不成问题。 Ext3支持Htree索引，dir_index; 但是，我的FS没有启用。
# I Checked Ext features, no dir_index $ tune2fs -l /dev/xvda | grep features # Enabled dir_index $ tune2fs -O dir_index /dev/xvda
我重新启动后不得不fsck，但否则启用成功。 当我列出这些目录中的文件时，性能问题已经消失。 我可以避免实现基于NoSQL的VFS，gridfs-fuse; 我可以避免在完全分配的HD上resize/重新分区。
至于改变我的FS，我想尽可能避免这种磁盘操作。