December 6, 2007 at 10:57 am
Hi all,
I don't know if it can be usefull for you to understand the problem but, this is the configuration I have
physical server :
- 4 proc dual core
- 8Go RAM
- windows 2003 Server Ent. SP1
- Virtual Server 2005 R2 (with 2 virtual servers)
Virtual Server (the one with I have problem...) :
- 3721 Mo
- 1 proc (no choice...)
- Windows 2003 Server Ent. SP2
- SharePoint Portal Server 3.0
- SQL Server 2005 SP2
The second virtual server is up but not used by anyone (test server)
My problem is : a colleague has installed this sharePoint server (so I don't know excactly how he did it) and we have a problem : the CPU is always 100% used... it is the sqlservr.exe process which take those resources.
I have activated traces and I have a "Missing Column Statistics" for every SPID...
The message is : NO STATS:([#AnchorText2].[LinkId], [A].[SourceDocID], [A].[LinkId])
I have also messages (for the same SPID) which deal with tempdb.
if I run this command : DBCC SQLPERF(LOGSPACE)
the result for tempdb is : 49,99219 (size)53,61775 (used)0 (status)
Somes options in the tempdb properties :
- auto create statistics : True
- auto shrink : False
- auto update statitics : True
- auto update statistics asynchronously : False
I don't know if the problem deals with SQL or SharePoint... or both...
I'm a begginer in "database administration" (as you can see) so any advice would be very appreciable.
Thanks in advance.
Vincent
December 6, 2007 at 11:28 am
It's never a very popular thing to say, but don't share the SQL Server server with any other process. It's a pretty safe rule of thumb (yeah, there are exceptions).
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
December 6, 2007 at 11:41 am
Grant Fritchey (12/6/2007)
It's never a very popular thing to say, but don't share the SQL Server server with any other process. It's a pretty safe rule of thumb (yeah, there are exceptions).
Sharepoint can be worse than the average "other app", since in addition to being a rather intense IIS-based process, it will make extensive and liberal use of SQL Server to store all sorts of things from configs, security info, BLOB's, etc.... Not only are you now fighting for resources, but you're also likely competing for SQL resources with auto-generated code, etc.... And if he took the defaults - the SharePoint databases are probably installed on the C: drive.
Oh yeah - now THAT's some serious fun.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
December 6, 2007 at 12:14 pm
Databases are installed on the D: drive.
Thanks for your advices and point of view but I have to try to resolve this problem keeping the existing configuration...
March 3, 2008 at 7:21 am
Have exactly the same problem:
Win2003 server, Share Point 2007 and after two weeks of good working, CPU is 100% and I can't do anything.
Stuck in some problem which I can't find by "Googling"
Some idea?
March 3, 2008 at 7:30 am
You are very likely not going to solve the problem. If the two processes are fighting for resources you have to put severe limits on one or both which is going to make performance an issue. You can limit the amount of memory that SQL Server has available through the server properties. If the unit has multiple cpu's, you can limit the number available to SQL Server and set an affinity to one of the processors so that's the only one it will use.
I assume, but I don't know, that the other service can have the same limits placed on it.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 3, 2008 at 7:50 am
You are even more limited if you are using the embedded version of SQL Server that is loaded in a single server install. We have two installations of Windows SharePoint Services in a development environment. The first is using the embedded version, and if I need to running the Surface Area Configuration program on the install of SQL Server 2005 DE on the server WSS is installed, I have to shutdown WSS first.
Also, SSMS can't connect to the embedded version of SQL Server making managing it even harder.
Our second development server, although on a single server, is setup as a web farm using SQL Server 2005 DE as the backend (it is after all a development site). That one is easier to support.
😎
March 3, 2008 at 8:03 am
Hi all,
I don't know if it can help you but the problem was related to the re index processus of the document stored in the database.
The problem has disappear but I don't have the final answer...
I'm going to get information and I will complete this post.
May 6, 2008 at 9:53 am
I found a way to connect to the Windows Internal Database (SQL Server 2005 Embedded Edition (SSEE)) with thanks to Wikipedia!
It has to be done local to server, and you enter the server name as such:
\\.\pipe\mssql$microsoft##ssee\sql\query
The link to Wikipedia is this:
http://en.wikipedia.org/wiki/Windows_Internal_Database
Hope this helps some people!
😎
Viewing 9 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply