Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I admin a MOSS SP2007 service pack 3 (32 bit) farm of 1 sql server (shared) and 1 machine that runs all of sp2007 (windows 2003, 32 bit). The VM has allocated to it 2 CPUs and 8 GB of memory.

Recent changes: In the past 2 weeks we moved the farm from hardware to virtual, and then applied the service pack 3.

I inherited the system 2 years ago. Since that time, I have seen a variety of errors in the logs and event queue that I have been unable to resolve.

However, the problems the past couple of weeks are big enough to be of concern.

We have had, several times now, cases where IIS no longer serves pages for SharePoint. If I recycle the app pool sometimes, things work again. Other times, if I recycle the IIS service, pages once again are served.

The most recent case (from yesterday) is a bit different from most. The application event log says:

Event Type: Error Event Source: ASP.NET 2.0.50727.0 Event Category: None Event ID: 1334 Date: 11/5/2012 Time: 2:04:38 PM User: N/A Computer: myserver Description: An unhandled exception occurred and the process was terminated.

Application ID: /LM/W3SVC/956111699/Root

Process ID: 5864

Exception: System.OutOfMemoryException

Message: Exception of type 'System.OutOfMemoryException' was thrown.

StackTrace: at System.Threading.ExecutionContext.CreateCopy() at System.Threading._TimerCallback.PerformTimerCallback(Object state)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

In the System event log, we also had this message Event Type:

Information Event Source: Application Popup Event Category: None Event ID: 26 Date: 11/5/2012 Time: 2:04:38 PM User: N/A Computer: myserver Description: Application popup: Microsoft Visual C++ Runtime Library : Runtime Error!

Program: c:\windows\system32\inetsrv\w3wp.exe

This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

This particular event required me to recycle the IIS server.

I am interested in learning how to prevent this event from reoccuring. However, I am also interested in figuring out how to monitor IIS so that any time the app pool dies (or IIS dies) I get them recycled quickly.

I know very little about IIS. I expect that the configuration of it is at the heart of this problem.

I know that my app pool is set up in this way. 1. Recycle worker processes at 02:44. 2. Recycle worker processes when execeeding maximum virtual memory of 1700 MB 3. Recycle worker processes when exceeding used memory 1000 MB 4. Limit the kernel request queue to 1000 requests 5. Maximum number of worker processes 1 6. Ping worker process every 30 seconds 7. rapid-fail protection nis turned on, set to 5 failures in 5 minutes. 8. the startup time limit for a worker process is 90 seconds 9. The shutdown time limit for a worker process is 90 seconds

I don't know how to determine a "better" setting for the maximum virtual and used memory. I don't know for certain that these are the cause - I would have thought I would be seeing system events regarding recycling of the worker processes if that were the case.

The system has trend micro anti-virus software running on it. The system does 1 incremental content crawl a day, which can vary between 60 minutes and 20 hours. It does 1 full crawl a week. It does 1 active directory user profile crawl a day at 6am.

I have performed quite a number of web searches, and looked at the causes others have found for this type of error, but have not found anything comperable in our environment yet.

Help - or pointers to references that would help - would really be appreciated.

With regards to the comments about "crashing processes" - is there a tool/log/etc that would show... or alert me... when the worker process was no longer operational? Right now I only find out once a user tries to access the site and either gets an error page or a time out for the page.

share|improve this question
    
If you're on a 32-bit OS, there's no reason to give the system 8 GB of RAM - it's only using 4 GB at most. –  Drew Lanclos Nov 6 '12 at 22:40
add comment

1 Answer 1

Crashing worker processes & the need to regularly recycle IIS could be a sign of low memory conditions or custom code gone bad.

I see a lot of OutOfMemoryExceptions on 32 bit SharePoint 2007 systems where "simply" upgrading to 64 bit solved a lot of issues. How are you doing on server resources?

Are there any particular errors in the SharePoint logfiles? Most of the time they provide more detailed information than the event logs.

share|improve this answer
    
To Drew Lanclos - I understand there is no reason to give the system that much RAM. The machine was configured by others who believed they knew better than I how much memory the 32 bit application and OS could access. –  LVirden Nov 7 '12 at 12:21
    
Changes to a 64 bit application is not something we can take on lightly; the plan is to migrate sites as resources are available, to SP 2010 over a period of time. As for particular errors in the logfiles, there was nothing in the ULS logs for that period of time other than v3 cache statistics, a trace health status that everything appears ok, a couple of "remove v3 cache reason - expired" messages, and a destructor v3 usercatalogcache GUID message. –  LVirden Nov 7 '12 at 12:30
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.