Best Pracice Conference is back to Washignton DC this Aughst. This time it's for SharePoint and SQL Server.
You can find details here.
Saturday, April 11, 2009
MOSS and High CPU Usage - a rare case
Earlier this week in the afternoon we noticed that the production MOSS was running very slow. Our team found out the CPU usage of the WFE server was reaching 100% constantly. The WFE had 8 cores with 4 GB memory and hard to believe it's normal.
I was on the way home and driving, so I could only help with my mouth bfore I could open my computer and connect to the server. We reset IIS couple times and the same situation would come back after 10 to 15 minutes. We could not reboot at the time due to the users from the west still using it.
So the next thing we did was to find out what may cause this CPU spike. When we traced the time line back, the major difference was that one site collection was restored with DocAve earlier in the afternoon. We decided to narrow down the range by restoring the same site collection to our development environment.
Then the same situation happened in the development sever and we knew that's the source. But why? By going through some emails and conversation with different users, we thought it has something to do with InfoPath form. But we still did not have anything clear.
In order to put production MOSS back to normal status, we communicated to the site owners with the situation and our work around solutions: backed up the site collection and removed it from the system until we know how to open it again without problem. Very soon we had approval from the owner and proceeded.
We backed up the site collection, removed it from production, reset IIS and restarted coupld services. Everything looked fine and CPU usage staied low for 30 to 40 minutes. We knew the crisis in production was over and we can concerated on finding the answers.
Our techinical lead took another site collection which had InfoPath from and restored it with DocAve to development enevironment. The same situation came back right away. Now we knew something wrong with DocAve and InfoPath form.
We sent our finding and a sample to the vendor and they could reproduce the same problem in their lab. So, DocAve can not deal with site which has InfoPath form?
Not really. This is a very rare case: in order to have this problem, you have to have a InfoPath 2003 form template saved in a library which was migrated from WSS 2 (not sure the same would happen to 2003 Portal). When you restore the site with DocAve, you will have the same problem. However, if you restore the entire site collection with STSADM, no problem at all.
We received a patch from the vendor and tested it. So far it looks good. So, case closed.
I was on the way home and driving, so I could only help with my mouth bfore I could open my computer and connect to the server. We reset IIS couple times and the same situation would come back after 10 to 15 minutes. We could not reboot at the time due to the users from the west still using it.
So the next thing we did was to find out what may cause this CPU spike. When we traced the time line back, the major difference was that one site collection was restored with DocAve earlier in the afternoon. We decided to narrow down the range by restoring the same site collection to our development environment.
Then the same situation happened in the development sever and we knew that's the source. But why? By going through some emails and conversation with different users, we thought it has something to do with InfoPath form. But we still did not have anything clear.
In order to put production MOSS back to normal status, we communicated to the site owners with the situation and our work around solutions: backed up the site collection and removed it from the system until we know how to open it again without problem. Very soon we had approval from the owner and proceeded.
We backed up the site collection, removed it from production, reset IIS and restarted coupld services. Everything looked fine and CPU usage staied low for 30 to 40 minutes. We knew the crisis in production was over and we can concerated on finding the answers.
Our techinical lead took another site collection which had InfoPath from and restored it with DocAve to development enevironment. The same situation came back right away. Now we knew something wrong with DocAve and InfoPath form.
We sent our finding and a sample to the vendor and they could reproduce the same problem in their lab. So, DocAve can not deal with site which has InfoPath form?
Not really. This is a very rare case: in order to have this problem, you have to have a InfoPath 2003 form template saved in a library which was migrated from WSS 2 (not sure the same would happen to 2003 Portal). When you restore the site with DocAve, you will have the same problem. However, if you restore the entire site collection with STSADM, no problem at all.
We received a patch from the vendor and tested it. So far it looks good. So, case closed.
Subscribe to:
Posts (Atom)
Posts
