我在我的许多DCL脚本中使用词法f $搜索，但是直到目录中有大约10k个文件供DCL搜索才从未遇到任何问题...现在在这种情况下f $ search变慢了从大量的文件中搜索，我怀疑还有一些性能影响....所以想知道如果目录中有大量文件或者还有其他原因导致f $搜索变得很慢如果是，那么可能的原因是什么？ 如果需要任何其他信息，请告诉我。
答案 0 :(得分：2)
是的，对大型目录的f $搜索可能很慢。 由于活动的原因，它可能导致速度缓慢，或者由于外部目录活动而导致速度变慢。 目录是简单的顺序文件，按字母顺序记录文件名。它们开始“密集”，但随着时间的推移变得“稀疏”。如果在中间的块中添加了一个新名称，并且该块太满了，则该目录的其余部分将被移动以腾出空间..这可能需要数百个IO并阻塞F $ SEARCH。如果删除了块中的最后一个条目，则其余条目将被移除。 shuffle曾经一次是一个块，现在（6.2？）成为32个块（mcr sysgen show acp_maxread） 一切都取决于。请提供更相关的“减速”说明 - OpenVMS版本 - 搜索模式：通配符或特定（更好）？ - 重新启动每个搜索或使用上下文循环（更好！） - 典型的名称模式？前4或5个字符的大量变化是最好的。
相关的绩效数据，可能来自T4，或至少来自MONI FILE和MONI FCP的指示？
祝你好运！ 海因答案 1 :(得分：0)
考虑申请变更。一个目录中的10K文件，通常更好的是文件中的记录而不是目录中的文件。目录子系统实际上并不意味着以这种方式使用。 （抱歉没有直接帮助）。 较新版本的VMS允许使用更多数量的块预先分配目录（$ CREATE / DIR / ALLOCATION = nnnnn）。这可以提供帮助。
对于补救，您可以创建一个具有相当大分配的new.dir（查看旧目录的大小），然后将文件从旧目录重命名为新目录。
$ create/dir/alloc=500 disk:[new]
$ rename [old]*.*;* disk:[new]*.*;*
然后删除旧目录（应为空）并将新目录重命名为旧目录。
显然，如果没有进程正在创建或访问目录中的文件，则只执行上述操作。