有谁知道索引服务索引在Windows 2008上的最大大小是多less？ 我们在索引悬挂和处理新文档方面存在各种各样的问题。
我刚刚删除了目录，并重新创build它。 我已经添加了4个应该是索引的文件夹，但是还要添加8个。 这个索引已经上升到了大约3GS的4个被索引的文件夹。
到目前为止，索引服务已经保持运行了好几天了。 （敲木头。）我现在认为索引服务不喜欢当它正在查看的networking共享失败。 文件服务器是主动被动群集，所有networking共享都是自己群集组（使用Windows 2008术语的群集应用程序）内的群集资源。 索引服务也是它自己的应用程序中的一个集群资源，因此它可以独立于文件共享进行故障切换。
从我可以告诉索引服务只有一个节点故障时（真的有一个惊恐发作，每当微软发布补丁，当节点重新启动时发生这种情况）。
我正在考虑在每个集群应用程序中强制索引服务脱机，然后在任何受监视的networking共享故障切换时重新联机。 如果我走这条路线，我将不得不小心，当多个networking共享故障转移时，如果索引服务已经在进行故障转移，它们不会启动失败。
你发布这个问题已经有一段时间了。 你能否介绍一下你所看到的行为/performance？
我讨厌这样说，但是我猜测你已经“自己标杆”，看看“领土”了。 我不知道索引服务上有任何已发布的“限制”。 确实，现在“索引服务”的祖先“微软索引服务器”被特别引用，并没有内置的限制（参见http://msdn.microsoft.com/en-us/library /dd582938(office.11).aspx的详细信息）的文件数量，或者大概是目录大小。 索引服务的行为在很大程度上取决于索引文档的types和组成，因此不存在“最大大小”数字。
当你说“…有〜500个文件…”时，你是在谈论目录目录中的500多个文件吗？ 这听起来像CiSvc没有进行合并，出于某种原因。 绝大多数的文件应该被合并到主要的Catalog.WCI文件中并被删除。 每天至less应该发生一次“主合并”，将所有由CiDaemon进程创build的影子索引合并到主索引中。 Perfmon可以告诉你更多关于里面发生了什么事情。
我们在NT4.0天总是使用的索引大小的经验法则大约是索引文档集的大小的40％。 这是与您正在索引的文件叽叽喳喳？
如果你不介意search不能跨越多个目录（除非你编写代码在多个目录上提交相同的文件并自己聚合结果），如果你开始遇到性能问题，你可以把你的语料库分成多个目录。
听说您使用索引服务对我来说很有趣。 如果你认为它是“开罗”计划的一部分（当时的代号为“的黎波里”），那么这个计划是可敬的，一直追溯到Windows NT 4.0 Option Pack。 你正在记住“主合并”和“阴影合并”以及旧的“微软索引服务器”的各种小细节，我想我已经忘记了… …>微笑<这让我很伤心，微软没有把它作为一个产品投入更多的努力，因为它很容易成为企业分布式search系统的基础。 哦，好吧…我想，没有采取的path。
编辑：
你在一个规模的领土，我从来没有使用过索引服务。 多个目录（甚至多个索引服务在多个盒子上的多个实例）可能是perf受害者下一个去的地方。 希望你不需要去那里。
我不确定当股票失败时它是如何“知道”到“恐慌”的，我敢说，要看源头才能找出原因。 这听起来像是其中一个“医生，当我这样做的时候会感到痛苦”。 “好的，不要这样做。” 种类的东西。 为此，您的计划是：处理股票故障转移可能是一个好的方法。
索引到语料库的比例不到30％，肯定比微软总是说当天计划的要好。 听起来像你正在索引的文件，主要是文本，没有OLE属性的开销像Office文档（这是我相信，微软的40％的经验法则的基础上）caching。 （顺便说一下，如果你愿意，你可以让你的开发者为这些不同types的文件设置代码filter，并获得进行特定属性search的能力。向我展示所有来自xxxx的电子邮件……嘿嘿。当然会增长属性caching。）
目录中的500多个文件终于清理并合并了，不是吗？
无论如何，当它“恐慌”时，它会做什么？ 它只是停止“看到”新的文件和索引他们？
我想知道是不是所有的东西都可以代替索引服务（我发现这个服务是非常常见的问题，尽pipe它和索引有所不同，但是所有的东西都是令人高兴的。