It analyzes the dump of the w3wp process that you previously provided when the CPU usage is high. The following are some findings:
- During the capture of dump files,. Net garbage collection is running. When memory resources are insufficient,. NET will automatically start the memory garbage collection mechanism to release memory resources for the program to use. Because the garbage collection process requires a large amount of CPU resources, this is the reason for the high CPU usage during this period.
- Most of the memory used by the w3wp process is occupied by the permissioncollection struct, which is used to record the permissions of each project in the SharePoint site, therefore, if our SharePoint site has many projects with independent permissions, these structures will occupy a large amount of memory space. For content in this struct, refer to the msdn article: http://msdn.microsoft.com/en-us/library/permissions.permissions.getpermissioncollection (V = office.12). aspx
- At the moment of capturing the dump file, there should be a crawler in your environment in progress, we see the w3wp process has a similar HTTP Request: http://apps.westrac.com.cn: 80/_ vti_bin/sitedata. asmx: the Web service request is sent by the crawler. The crawler obtains the content of the SharePoint site and the permissions corresponding to the content through the web service, therefore, the permissioncollection mentioned above is usually composed of sitedata. the Web Service asmx is generated when processing crawler requests.
Therefore, the intermittent increase in CPU and memory usage you have observed may be related to network crawling in your environment. We recommend that you reduce the number of independent permissions and the number of list items proposed before Jinkui, and do not set SharePoint crawling to start during peak hours, so as not to affect the overall performance of the Sharepoint Server.
The execution duration of database query statements is determined by many factors. Based on our log analysis, we update the statistics of the two tables in the new environment SharePoint content database and reset the index, it can effectively improve the query speed. Run the following command in the newly upgraded SQL Server database. Make sure that wtc_app_center_content is the content database used to access the slow Website:
Use wtc_app_center_content;
Go
Update statistics alluserdata with fullscan
Update statistics alldocs with fullscan
Alter index all on alluserdata rebuild
Alter index all on alldocs rebuild
Because the execution of this command may affect the performance of database products, it is recommended that you execute this command during non-working hours. Based on the size of the data in the database, this command may be executed for a long time.
If we have adjusted the network crawling schedule and updated the statistics in the database, we can continue to capture the pssdiag log of SQL Server, further analysis has no space to increase the query speed. Combined with the previous analysis, the root cause of slow access to SharePoint in your environment is that the current site has too many independent permission projects, resulting in a large amount of time to return the query statements in SQL Server. Therefore, the fundamental solution to this problem is to adjust the content of your site according to the recommended configurations in our official documentation. For details, refer to the emails before jiankui.
SharePoint site performance