SharePoint - WSS3 Search Crawl causes 100% cpu usage

Asked By admi

21-Mar-07 10:39 AM

Hello,
I have a problem on one of my WSS3 servers that just started last friday.
When the WSS3 Search Crawl task kicks off, the cpu goes to 100% and remains
there. It will stay there forever until I do an IIS reset.

Upon investigating, I see 2 application pools using all the cpu.
1. The Server farm Application Pool uses about 40%
2. The Application pool all the sharepoint sites uses about 60%

I have confirmed in the log files that is the WSS3 search crawl that causes
this.

Anyone have any ideas on what may be causing this?

--
Edward York

01-Apr-07 03:58 PM

I am answering my own question here. I found the problem.

On installation of SharePoint, the config wizard sets permissions on the
directory C:\Documents and Settings\All Users\Application
Data\Microsoft\SharePoint for the the accounts WSS_ADMIN_WPG and the WSS_WPG
groups. When the server is new, there is nothing in this folder, so the
problem is not noticed. However, everytime you add a site to the server,
another file gets dropped into this folder. So whenever you run a task either
manually or automatically, such as the search crawl task or when you setup a
new site, sharepoint access all those files. The more files in this folder,
the more cpu is used. It seems sharepoint tries to access all those files at
the same time and when it does, cpu shoots up on the farm application pool
and the application pools used for all the sites. I do not know what these
files even do yet.

I discovered this problem accidently a few weeks ago as I messed up the
permissions on my 1st sharepoint server. I manually fixed all the permissions
except I forgot about that folder. But I also noticed my high cpu problem
went away. I still had this high CPU problem on my 2nd sharepoint server. I
had been fighting this 2nd server for weeks. I finally decided to open each
server side by side and compare all permissions on the server. This is when I
discovered the folder on the 1st server did not have the permissions set for
the groups WSS_ADMIN_WPG and WSS_WPG. I had forgot to add those user groups
back to that folder.
So I decided on an experiment. I went to the 2nd server still having cpu
problems and removed the WSS_ADMIN_WPG and WSS_WPG group from this folder and
all files and folders below it. I ran a few tests, kicked off the crawl task,
created a few sites and wow and behold, the problem was gone. CPU usage is
now back to normal.

All this said, I am still investigating what the files in that folder do. I
will report back here if I find that answer. My servers seem to be working
fine though without these user groups assigned to that folder.

I am curious if anyone else has run across a problem such as this. I would
be interested in hearing what others have to say.

--
Edward York

10-Apr-07 12:20 AM

This is an update to my last update on 4/1/07.
It appears my previously mentioned fix is really not a fix after all. It's
more a work around then anything else. While it appears at first glance to
correct the problem, it sometimes causes other database connection problems
for the sites if an IIS reset is done.

After poking around for another 2 weeks, I believe I finally found the
correct fix.
I compared my servers to another WSS3 server which was known to work. The
file permissions were all correct, but the registry permissions were not
correct.
You need to hack the registry as I did to correct the problem.
You need to open regedit and go to HKey Local
Machine\Software\Microsoft\shared tools\web server extensions\12.
Right click the key WSS, choose Permissions, then highlight the group
WSS_WPG and click Advance. You need to add the user Everyone to the list of
users and assign the user Eeveryone to READ access.

Do the same for the key called Search. Right click the key Search, choose
Permissions, then highlight the group WSS_WPG and click Advance. You need to
add the user Everyone to the list of users and assign the user Eeveryone to
READ access.

It appears to me that new installations of WSS3 installed in Active
Directory Account Creation mode have this problem. The server that worked
fine was installed in a stand alone mode and had the correct permissions in
the registry. I believe this is a bug, but until I build a 3rd server and
test it, I won't know for sure. If anyone else has come across this same
problem, please post it here for all to see as there is no other
documentation in existance that I have found that relates to this problem.
--
Edward York
724 Inc