有人知道 Windows 2008 上索引服务索引的最大大小是多少吗？我们遇到了各种问题，索引挂起，无法处理新文档。
我刚刚删除了目录并重新创建了它。我添加了 4 个应该是索引的文件夹，但还有 8 个要添加。对于正在索引的 4 个文件夹，索引已增加到约 3 GB。
到目前为止，索引服务已经正常运行了好几天。（敲敲木头。）我现在认为索引服务不喜欢它正在查看的网络共享发生故障转移。文件服务器是一个主动被动集群，所有网络共享都是其自身集群组内的集群资源（使用 Windows 2008 术语的集群应用程序）。索引服务也是其自身应用程序内的集群资源，因此它可以独立于文件共享进行故障转移。
据我所知，只有当其中一个节点发生故障转移时，索引服务才真正会出现恐慌（每次微软在节点重启时发布补丁时都会发生这种情况）。
我正在考虑在每个集群应用程序中放置一个脚本，强制索引服务离线，然后在任何受监控的网络共享发生故障转移时重新上线。如果我选择这种方式，我必须小心，当多个网络共享同时发生故障转移时，如果索引服务已处于故障转移过程中，它们不会开始出现故障。
答案1
您发布这个问题已经有一段时间了。您能更新一下您所看到的行为/性能吗？
我不想这么说，但我猜你对“自己进行基准测试并查看”感兴趣。我不知道索引服务有任何已发布的“限制”。事实上，现代“索引服务”的前身“Microsoft Index Server”被特别提及没有内置限制（请参阅http://msdn.microsoft.com/en-us/library/dd582938(office.11).aspx详细信息）到文档数量或目录大小。索引服务的行为是高度取决于被索引文档的类型和组成，因此没有一个简单的“最大尺寸”数字。
当您说“...有 ~500 个文件...”时，您指的是目录目录中散落的 500 多个文件吗？这听起来好像 CiSvc 出于某种原因没有进行合并。散落的绝大多数文件应该合并到主 Catalog.WCI 文件中并被删除。每天至少应该进行一次“主合并”，以将 CiDaemon 进程创建的所有影子索引合并到主索引中。Perfmon 可以向您展示有关内部发生情况的更多信息。
在 NT 4.0 时代，我们一直使用的索引大小经验法则是大约占被索引文档集大小的 40%。这与您正在索引的文件相符吗？
如果您不介意搜索不能跨越多个目录（除非您编写代码以在多个目录上提交相同的搜索并自行汇总结果），那么如果您开始遇到性能问题，您可以将语料库分成多个目录。
对我来说，听说你正在使用索引服务很有趣。它的历史悠久，可以追溯到 Windows NT 4.0 Option Pack——如果你认为它是“Cairo”计划的一部分，那么它的历史就更久远了方式回来了（当时的代号是 Tripoli）。你让我想起了“主合并”和“影子合并”以及我以为我已经忘记的旧“Microsoft Index Server”的各种小细节……>微笑<微软没有在产品上投入更多精力，这让我很难过，因为它很容易成为企业分布式搜索系统的基础。哦，好吧……我想这是一条未走的路。
编辑：
您处于一个我以前从未使用过索引服务的规模领域。当性能受到影响时，多个目录（甚至多个盒子上的多个索引服务实例）可能是您的下一个选择。希望您不需要去那里。
我不知道它是如何“知道”在共享故障转移时“恐慌”的，我敢说，要找出原因，需要查看源代码。这听起来像是“医生，我这样做会很疼。”“好吧，不要那样做。”之类的话。为此，您关于处理共享故障转移的计划可能是一个不错的选择。
30% 或更低的索引与语料库比率肯定比微软过去一直说的要好。听起来您正在索引的文件主要是文本，没有像 Office 文档那样缓存 OLE 属性的开销（我相信这是微软 40% 经验法则的基础）。（顺便说一句，如果您愿意，您可以让您的开发人员为这些不同类型的文件编写代码过滤器，并获得执行特定于属性的搜索的能力。向我显示来自 xxxx 的所有电子邮件等...呵呵。当然，这会增加属性缓存。）
目录中的 500 多个文件最终确实被清理并合并了，不是吗？
无论如何，当它“崩溃”时，它会做什么？它只是停止“查看”新文档并对其进行索引吗？
答案2
我想知道“一切”（http://www.voidtools.com/）可以替代索引服务（我发现它经常出现问题。尽管它与索引功能有所不同，但使用起来还是很愉快的。