Have you ever noticed your WFE server crawling, and then ran Task Manager to find the Memory Usage of some of your w3wp.exe process through the roof. You need to know which process is tied to which application pool to begin troubleshooting. How do you get this information? OK, so this is nothing new, and definitely not specific to SharePoint. But it does come in handy, and I never seem to remember exactly how:
1. From Task Manager, select View > Select Columns
2. Put a check mark next to “PID (Process Identifier)” and click “OK”
3. Open the command prompt
4. Run the following command:
The above should result in an output similar to the following:
Notice how each w3wp process is tied to a specific application pool. If you’ve properly labeled your Application Pools and are not using the same Application Pool for all of your IIS sites, this should give you a good place to start looking for problems. If responsiveness is severely hampered you may choose to recycle the the offending Application Pool without having to do an IIS Reset which would impact all of your other sites.
I was recently brought into a client to help troubleshoot an issue with a SharePoint Timer Job, that appeared to be executing multiple times (around the same time) although it was scheduled to run only once daily. While others in the SharePoint community appeared to experience the same problem, no one seemed to be able to point to a cause.. much less a solution. In this case it was always running 9 times, significantly more than the three or four others where reporting.
After much digging around, and focusing on the magic number (why 9) it struck me. How many Content Databases did the client have on the web application that the Timer Job was associated with? 9 to be exact. It was doing what it needed to do based on how it had been developed, the developers failed to test it on a Web Application with more than one Content Database. From there on, fixing the code was simple.. but it may be different for you based on what your timer job needs to do. Remember every Site Collection (SPSite) has a property that gives you the Content Database, and every time a Timer Job is called (targeting a Content Database) the Content Database GUID for which it is running is passed in… use it for validation.
Anyhow, at the very least, if you are running into this problem this might help point you in the right direction.
For information on how to develop SharePoint Timer Jobs (SPJobDefinition) see Andrew Connells MSDN Article “Creating Custom Timer Jobs in Windows SharePoint Services 3.0”