客戶項目是Dynamic CRM On Promise的 ,並且由於 預算關係,是ALL in One的
在一個項目中遇到的一個情況,項目上線的時候都很正常,運行一段時間後,系統能正常登陸,
但是打開默認的儀表板頁面 和 列表頁 非常慢,慢的令人髮指,大概需要幾分鐘的時間,哪怕列表頁只有不到10條數據,還有就是一開始正常運行的流程,現在也開始報錯
對於CRM的性能調優也沒什麼經驗,不過好在之前有聽過幾次關於調優的講座,
從幾個方面入手,
1.基礎網絡
2.應用層面
3.數據庫層面
1--> 先從客戶的網絡入手,排除掉了網絡問題
2-->應用層面: 一開始從前端開始排查 頁面的TTFB 能到達 1分鐘 ,甚至更長,還想着找到最長的那個TTFB的請求
找到的都是 CRM系統原生的一些請求,這些請求也沒法改動,網上翻了一些帖子,也基本沒有什麼收貨
3-->數據庫層面: 之前知道一些 數據庫 調優的一些工具,例如: sqlprofile ,計數器 這些,也是試圖 用這些工具 做了一些監控,由於對
這些工具使用較少,也翻了一些文檔,沒有什麼收貨
後來換了一種思路,數據庫調優 一般會從 索引 入手,就從這方面去翻了一些資料,果然有收穫
對於Dynamic CRM 數據庫,微軟內置了 一大批 存儲過程,其中就會有 重新生成索引的 存儲過程,並且會有一些job 在跑這些存儲過程
找到了一個 重新生成全部 索引的 存儲過程,根據 博客的一些介紹,重新跑一下完事後在訪問系統就基本恢復正常了
對於客戶來說,到這裏基本問題得到解決,到底 爲什麼會這樣,後來也沒有時間深究。
我猜想 可能一下幾個方面會有一些影響
1.也許跟客戶的服務器環境 和 設置有關係,ALL in One的 系統,
2.每天會有跟SAP的接口程序,有大量數據的同步,刪除和重新生成數據操作
有哪些大神有一些思路了 ,希望可以批評指正。
下邊是一篇關於 CRM 性能調優且有關 重新生成索引的一些介紹
引用地址:http://soluciones-microsoft.blogspot.com/2018/07/how-to-improve-microsoft-dynamics-365.html
How to Improve Microsoft Dynamics 365 CRM Performance
https://github.com/pfedynamics/dynamicsperf
The following 5 items provided the biggest performance boost to their Dynamics CRM instance.
1.) Reorganizing / Rebuilding SQL Indexes
When you install Microsoft CRM, several System jobs are set up to keep your database running smoothly. These routines include rebuilding fragmented indexes and cleaning up tables that contain data that is no longer needed. These jobs work great when your database is of moderate size, however if your database grows over 40 GB, these jobs may begin to fail. When this happens your database will begin to grow rapidly, and your indexes will quickly become fragmented. (My client had over 100 indexes fragmented at more than 80%, and a few tables that contained over 20 million unnecessary records.)These issues can lead to extremely slow performance and eventual SQL timeouts.Are You Experiencing These Symptoms?
If so, you should turn off the out-of-the box index maintenance jobs and develop your own maintenance plan. You can get the CRM Job Editor tool from CodePlex to change the time that the maintenance plans run. (If you go this route, you’ll want to set the “Reindex All” and “Indexing Management” jobs to run sometime in the distant future, such as 12/31/2099.)
Once you have disabled these jobs, you will need to set up your own index maintenance jobs. I recommend using the SQL Server Maintenance Plan Wizard ( http://msdn.microsoft.com/en-us/library/ms191002.aspx ). Alternatively, you can create a SQL job to run the CRM 2011 index maintenance procedure p_ReindexAll, leaving the MaxRunTime variable null to ensure the job will complete. The procedure variables are as follows:
Order | Variable name | Default | Description |
1 | AllIndexTypes | 0 | 0:Clustered Index only, 1: Clustered and Non Clustered indexes |
2 | MaxRunTime | Null | Maximum allowed running time (in seconds) |
3 | FragRebuildPct | 30 | Percentage of fragmentation at which indexes are rebuilt |
4 | MinPages | 25 | do not touch tables less than xx pages |
5 | Verbose | 0 | 1: Print progress messages and detailed results |
EXEC p_ReindexAll 1,null,1,1,0
2.) Deletion of Completed Workflows
Similar to the CRM re-indexing job, the CRM system jobs designed to keep CRM tables cleaned up may start failing if your database becomes too large. When this happens the AsyncOperationsBase and PricipalObjectAccess tables can grow extremely large (tens of millions of records) within a few months. There are a few methods you can employ to keep these tables in check.If you want to delete all completed workflows immediately after they are completed, simply check the “Automatically delete completed workflow jobs” checkbox on each process.
However if you would like to remove completed workflows after some period of time (such as two weeks), you will need to create a SQL job to delete them in bulk. The Microsoft KB article 968520 contains the SQL required to do this.
3.) Delete Orphaned POA Records
BEGIN TRY
BEGIN TRAN t1
— delete PrincipalObjectAccess records in batches
exec(@deletestatement)
4.) Enabling Compression & SSL
Compression Enabled on HTTP | Compression Enabled on HTTPS | ||
Bytes Sent | 105084 | 105084 (0% reduction) | 67586 (36% reduction) |
Bytes Received | 219102 | 149424 (32% reduction) | 25837 (88% reduction) |
5.) Define system wide Outlook Sync Filters