解决SharePoint 2003的爬网性能问题- 之三

继续我们的针对爬网性能问题的讨论, 我们会看更多的一些计数器, 它们能帮助我们进一步地诊断crawler的状态.

让我们增加一点我们的计数器子集吧, 看看它们能帮助我们收集到什么信息.

 

计数器在传达什么信息?

在Search Gather对象中, 更多的计数器可以通过一瞥就了解一下整体的情况.

• Search Gatherer\Filter Process Created
  • 这个计数器会展现给你自从上次MSSSearch.exe会回收或者机器重启后, filtering process或者deamons (MSSDmn.exe)已经创建出来的数目. 这是一个有趣的值得观察的数字, 因为它可以作为你系统中的IFilter的健康程度指示器. 比如说, 如果你有一个IFilter正倾向于崩溃, 那么它会带着filter process一起崩溃, 从而MSSearch会需要创建一个新的filter process. 这对于有很多内容需要爬, 并且deamon不停崩溃的时候是很糟糕的. 当我说这个counter很高的时候, 我的标准是在24小时的时间内, 该计数器超过了300-400。这样高的值会出现在你有很多不同的会引起守护进程(deamon)启动和停止的crawl schedule的时候, 如果是这样的情况, 那么你并没有遇到什么大不了的问题. 如果你感觉这个数字有点大, 你应该去看一下application event log. 如果守护进程正在崩溃, 他们会典型地在event log中记录下一个ID为1000的事件. 如果你开启了Dr. Watson reporting特性的话, 你还会在event id 1000之后看到一个相关的event id 1001也被记录下来. 这些application event ID(1000 或1001)可以帮助我们确定IFilter是否在崩溃.
• Search Gatherer\Filter Processes
  • 这个计数器会告诉我们正在你的机器上运行着的filtering process或deamon(MSSDmn.exe)的进程数量. 在你想要获得一个印象的时候很有用, 这个印象就MSSearch进程觉得应该投入多少努力来执行爬网. 这个数字在某种程度上跟Search Gatherer下的Performance Level计数器相关, 我们稍后会讨论这个要点.
• Search Gatherer\Filter Processes Max
  • 这个计数器会告诉你自从上次重启机器或MSSearch进程被recycle以来, filtering process或deamon的进程数目的最大值.
• Search Gatherer\Filtering Threads
  • 这个计数器和下一个计数器一起可以直接反映你的爬网的性能. 这里列出的每一个线程都相当于一个IFilter, 还有一个正在被爬网的主文档. 如果这个值很低(2到5), 那么你的爬网肯定比当这个数值高一些(14到30+)的时候要慢. 把这些线程中的每一个都想像为杂货店的一条线. 如果有成百上千的人在你的商店里, 却只有两个人在收银台工作, 那么所有的人都会排起长队等待轮到自己结账. 如果你的商店里有30多个人可以同时帮助结账的话, 那么队伍很快就会被清空.
• Search Gatherer\Idle Threads
  • 这个计数器代表着空闲的filtering threads. 所以如果你有32个filtering threads, 并且只有0到2个是空闲的, 那么你就在同时filtering大致30到32个文档. 如果32个是空闲的, 并且你还正在运行爬网, 那么很可能你就遇到了某种问题, 需要进行更进一步的研究. 这里的研究可以在application event log中开始, 然后进一步到由产品提供的diagnostic logging(ULS).

后面的文章中, 我们会进一步地讨论这些计数器以及它们的意义.

 

资料来源

===========

SharePoint Portal Server 2003 Crawl Performance Part 3

http://blogs.msdn.com/b/tonymcin/archive/2007/03/13/sharepoint-portal-server-2003-crawl-performance-part-3.aspx