有谁知道 Windows 2008 上索引服务索引的最大大小是多少？我们在索引挂起和不处理新文档方面遇到了各种问题。
我刚刚删除了目录并重新创建了它。我已经添加了 4 个应该是索引的文件夹，但还有 8 个要添加。正在索引的 4 个文件夹的索引已上升到 ~3 Gigs。
到目前为止，索引服务已经运行了好几天。（敲木头。）我现在认为索引服务不喜欢它正在查看的网络共享故障转移。文件服务器是主动被动集群，所有网络共享都是集群组内的集群资源（使用 Windows 2008 术语的集群应用程序）。索引服务也是它自己的应用程序中的一个集群资源，因此它可以独立于文件共享进行故障转移。
据我所知，索引服务只有在其中一个节点故障转移时才会真正出现恐慌发作（假设每次微软在节点重新启动时发布补丁时都会发生这种情况）。
我正在考虑在每个集群应用程序中放置一个脚本，该脚本强制索引服务脱机，然后在任何受监控的网络共享故障转移时重新联机。如果我走这条路，我必须小心，当多个网络共享故障转移时，如果索引服务已经在故障转移过程中，它们不会开始失败。
自从您发布此问题以来已经有一段时间了。您能否提供有关您所看到的行为/性能的更新？
我不想这么说，但我猜你会进入“自己做基准测试”的领域。我不知道索引服务有任何已发布的“限制”。事实上，作为现代“索引服务”的祖先的“Microsoft 索引服务器”被特别引用，它没有内置限制（参见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 选项包——如果你认为它是“开罗”倡议的一部分（当时的代号为 Tripoli），那就更进一步了。您正在记住“主合并”和“影子合并”以及我以为我已经忘记的旧“Microsoft索引服务器”的各种小细节......>微笑<让我感到难过的是微软没有作为一个产品，投入更多精力，因为它很容易成为企业分布式搜索系统的基础。哦，好吧……我想没有走的路。
编辑：
您处于我以前从未使用过索引服务的规模领域。当性能受到影响时，多个目录（甚至是多个盒子上的多个索引服务实例）可能是您的下一个去处。希望你不需要去那里。
我不确定当共享失败时它是如何“知道”到“恐慌”的，我敢说它需要查看源代码才能找出原因。这听起来像是“医生，我这样做的时候很痛”之一。“好吧，不要那样做。” 之类的东西。为此，您的计划 re：处理共享故障转移可能是一个不错的选择。
30% 或更低的索引与语料比绝对比微软过去一直说的计划要好。听起来您要索引的文件主要是文本，没有像 Office 文档那样缓存 OLE 属性的开销（我相信，这是微软 40% 的经验法则的基础）。（顺便说一句，如果你愿意的话，你可以让你的开发人员对这些不同类型的文件进行代码过滤，并获得进行特定属性搜索的能力。给我看来自 xxxx 的所有电子邮件，等等......呵呵。那当然，会增加属性缓存。）
目录中的 500 多个文件终于清理并合并了，不是吗？
无论如何，当它“恐慌”时会做什么？它是否只是停止“查看”新文档并为它们编制索引？
我想知道“一切”（http://www.voidtools.com/）是否可以取代索引服务（我发现它经常出现问题。一切都令人愉快，尽管它与索引不同。