内核如何处理新文件的创建

Question

我希望了解当用户/应用尝试在directorty中创建文件时内核的工作方式。

背景 - 我们有一个java应用程序，它通过JMS消费消息，处理它然后将XML写入出站队列+本地目录。昨天我们在写入目录时观察到了不正常的延迟。在'ls | wc -l'上我们找到了＆gt; 300,000个文件。快速调整了进程，发现它充满了互斥锁（超过3/4的调用是互斥的）。

所以我认为新文件创建需要时间，因为系统必须每次检查某些内容（例如文件名以确保可以创建具有特定名称的新文件）在300,000个文件中然后创建一个文件。

我清除了目录，应用程序恢复到正常服务级别。

我的问题

1. 我的分析是否正确（似乎应用程序在清除后开始正常运行）？
2. 更加重要的是，当您尝试在目录中创建新文件时，内核如何工作。
3. 可以将异常数量的互斥锁调用归因于目录中的大量文件吗？

非常感谢 Ĵ

Answer 1

请阅读有关Linux文件系统，i节点和d节点的信息。

http://en.wikipedia.org/wiki/Inode_pointer_structure

文件系统被组织成固定大小的块。如果你的目录相对较小，它适合直接块，事情很快。如果您的目录不是太大，它适合直接块和一些间接块，并且仍然相当快。如果您的目录变得太大，它会溢出到双重间接块中并变慢。

实际大小取决于文件系统和内核配置。

经验法则是将目录保持在12个块以下，具体取决于块大小。许多系统使用8K块;快速目录小于98,304字节。

文件条目大小为16 * 4字节（IIRC），因此计划每个目录不超过1500个文件作为实际上限。

Answer 2

具有大量条目的目录通常很慢 - 速度有多慢取决于底层文件系统。

常见的解决方案是创建目录层次结构，因此每个目录只有几百个条目。

Answer 3

Mutex系统调用是应用程序（可能是JVM或Java库中的某些内容）进行互斥调用的结果。

通过strace看不到的内核内部同步，因为这只会自行检查系统调用。

如果您使用的是使用目录索引的文件系统，那么包含大量文件的目录不应该变得低效;现在大部分都是（ext3可以选择，但现在通常启用）。

非索引目录（就像坏的旧文件系统上使用的目录 - ext2，vfat等）在很多文件中变得非常糟糕，并且你会看到“开放”系统调用需要更长的时间。