继续扩展我们的计数器子集.

• Search Gatherer\Performance Level
  • 这是一个非常重要的指标, 反映出可以被和将要被crawler使用的资源的数量. 该计数器的值的范围是1到5, 默认值是3。
  • 这个数值影响着将要启动的单线程的和多线程的daemons(mssdmn.exe)的数量. 如果这个值是1或者2， 那么启动的daemons的数量就会显著地减少. 这样的话, 爬网就不会对服务器的整体性能产生较大的影响了. 另一个需要在这里指出的重点是这个数值还对filtering threads的线程优先级(thread priority)有影响. 当filtering threads的这项计数器为1~3时, 则线程是以低于普通线程优先级的等级启动的. 这就意味着filtering thread可能不会得到你想要的那么多的CPU处理时间了.
  • 它还会通过调整可供IFilter调用的线程的数目来影响多线程的守护进程(daemon). 如果Performance Level下降得越多, 那么可供IFilters调用的线程就越少.
• Search Gatherer\Server Objects
  • 这个计数器反映了gatherer在一次爬网中同时访问的服务器的数目. 当一个而服务器被首次访问的时候, 一个server object就会被创建出来. 你配置的被爬网的每一台主机都会有一个对应的server object. 这个计数器就是监视这些server objects的. 比如说, 如果你配置了爬网http://mysharepoint 和http://www.microsoft.com这两个站点, 那么你就至少有两个server objects被创建了出来. 如果这些服务器更多地链接到了其他服务器的话, 那么还会有更多的server objects会被创建出来的.
  • Server object会保存很多有关这台被访问的服务器的信息. 其中之一是这台服务器允许的并发连接的数量. 在稍后的一篇文章中, 我们会讨论Site Hit Frequency规则以及这项规则如何影响对连接的限制.
• Search Gatherer\Threads Accessing Network
  • 这个计数器展现了正在当前访问网络的可用的filtering threads的数量. 当一个filtering thread接收到下一个要crawl的item时, 这个线程就会负责加载用于连接到目标item的protocol handler. 如果目标item是在一个文件共享上的话, 那么我们就会加载可以连接到文件服务器的protocol handler.
  • 目标item是否会被拷贝到服务器场的本地服务器(特指请求该item的索引服务器indexer)取决于文件的类型.
  • 目标Item会被存储在索引服务器的临时文件夹中. 典型地, 该文件夹为<drive>:\Program Files\SharePoint Portal Server\Data\temp. 这个文件夹可以在管理中心站点中配置, Manage Server Settings-> Search Server Settings页面. 其中的File Location就允许你配置这个临时文件夹的路径. 注意! 不要让防毒软件扫描这个路径, 这非常重要! 如果你让杀毒软件扫描这个路径的话, 会严重地增加爬网时间. 你需要确保SharePoint站点中没有感染病毒的文件, 但这可以在上传文件时通过防毒软件与SharePoint的集成来做到. 很多软件可以做到这一点, 你需要找到一款适合你的杀毒软件.
  • 在目标item被拷贝的时候, 这个计数器就会增加. 当拷贝结束, 我们不再需要访问网络的时候, 那么这个计数器就会减少.
  • 目标item拷贝到本地的临时目录后, 这个线程就会加载IFilter, 然后开始调用GetChunk 方法来萃取出目标item的内容. 这项工作是由守护进程(deamon)完成的, 然后数据会被喂回给MSSearch进程, 用以执行最后的处理, 这项计数器在这里还会再次增长. 所以, 它的意思是在数据源源不断地通过网络从守护进程送回来的时候, 以及数据被喂给MSSearch进程的时候, 该计数器都会反映出来. 所以, 简单来说, 它会展现出来还在访问网络的, 还有实际上并没有在使用网络的但还在喂数据给MSSearch的线程总数.
• Search Gatherer\Threads In Plug-ins
  • 这项计数器展现了某时刻在Plug-in中的线程数. Search的设计者做了两个非常酷的选择, 第一, 让守护进程负责IFilter的错误; 第二, 让MSSearch可以通过plug-in方式进行扩展以处理多样的功能.
  • 这些plug-in的其中之一是Subscription Plug-in (SUBPI). 当数据从守护进程送回来的时候, 针对gatherer的某些动作是一定要完成的, 这样才能让gatherer完成所有的工作. 其中之一的功能就是创建SPS Alerts(注意, 不是WSS alerts, 它们是通过非常不同的机制来完成的). 这些一定要完成的动作就是plug-in的功能.
  • 这项计数器如果过高的话, 说明plug-in占用的时间太多, 可能意味着对后台SQL Server的连接缓慢. 爬网过程中这项计数器的频繁增长, 下降是正常的.
• Search Gatherer Projects\Crawls in Progress
  • 这个计数器指示出一个爬网正在进行. 它并不会告诉你进行的是哪一种爬网, 但是至少它告诉你有一个爬网正在运行.
  • 当查看该项计数器的历史数据的时候, 你可以确定出爬网开始和结束的时间.
  • 很多时候, 客户来询问说他们知道一个爬网正在运行, 但是他们不知道哪一种index正在爬网, 因为他们有太多的index了. 这项计数器可以帮助我们集中在究竟在爬哪一个.
  • 在查看历史数据的时候, 我使用这个计数器来限制view. 比如说, 在一分perfmon的日志中当我有3到4个爬网在运行的时候, 我可以修改开始标记和结束标记, 让perfmon的日志仅显示某一个爬网的时间段.
• Search Gatherer Projects\Incremental Crawls
  • 这个计数器展示出当前正在爬网的是否是一个incremental crawl. 当这个计数器是1的时候, 那么这就是一个incremental crawl, 当这个计数器是0， 那么就是一次full crawl, 或者是一次自适应crawl. 我没见过什么人运行自适应的crawl(adaptive crawl), 所以从这个计数器中估计你也会很少见到这种crawl.
  • 再次说明, 这个计数器可以用来在看历史数据时鉴别爬网使用, 在实时数据中查看当前爬网是否是incremental crawl的时候也是明智的.

后续的文章中, 我们还会讨论更多的计数器和它们的意义.

资料来源:

SharePoint Portal Server 2003 Crawl Performance Part 4

http://blogs.msdn.com/b/tonymcin/archive/2007/05/07/sharepoint-portal-server-2003-crawl-performance-part-4.aspx