PLM系統是企業最重要的資訊系統之一，尤其對於研發人員，PLM系統更是日常工作中非常重要的一環。隨著時間的推移，企業對PLM系統的相關應用越來越深入，一方面系統中的資料量急劇增長，另一方面研發人員工作中對於PLM系統的依賴性越來越大。所以，提升PLM系統的效能就是節約研發人員的寶貴時間。

Teamcenter作為業界領先的PLM系統，提供了相關的工具與引數供效能診斷與優化使用，但是工具如何結合企業實際業務與系統環境，並配合相應的效能診斷與優化方法，達到定位效能問題，最終解決效能問題才是調優工作成功與否的決定因素。

1

分析與定位效能問題

要解決Teamcenter的效能問題，不能完全照搬其他執行順暢的系統的引數直接大刀闊斧的上手進行調整，而是需要結合企業實際的業務與系統環境進行。因為每一個系統的業務與資料都不相同，應用的功能也是千差萬別，直接照搬肯定會出現“水土不服”，造成效能無法提升，甚至可能由於引數調整的不合理，造成系統宕機等嚴重後果。所以在系統調優之前一定要進行相應的系統與業務情況訪談，建議系統性能診斷與優化的流程如下：

圖1 系統診斷與優化流程

業務訪談分為終端使用者訪談與IT管理員的訪談。終端使用者訪談主要需要調研終端使用者在應用的過程中對系統哪些業務場景使用頻率較高，哪些業務場景效能較差。IT管理員訪談主要對系統整體可能對效能造成影響的資料數量級進行訪談，分析出相應的效能參考值，以便後續對系統進行整體評估。常見的業務訪談問題如下：

圖2 業務訪談問題

根據終端使用者訪談，根據使用者描述或操作定製重現步驟，並制定一個業務重要程度(效能影響大)與功能調優難度的四象限圖，以便後面制定調優範圍與計劃。因為有一些功能雖然存在效能存在瓶頸，但是可能使用的頻度非常的低，類似這種問題就可以將優先順序放低，以保障花最多的精力解決最重要的問題。下圖是一個常見的調優四象限圖示例：

圖3 調優工作四象限

眾所周知，Teamcenter採用的是分層架構，按照連線方式的不同分為兩層架構與四層架構。結合以往的經驗，並根據分層架構的特點，總結出常見的Teamcenter問題區域定位方式，可以通過不同層之間的效能存在問題定位到對應的效能瓶頸。

圖4 Teamcenter架構與問題區域定位方法

對於效能的診斷不光需要感性的判斷，同時還需要使用專業的工具進行檢測，通過工具的檢測主要包括網路的檢測、資料庫的檢測、Teamcenter自身的檢測以及伺服器作業系統的檢測。

網路的檢測主要需要檢測以下幾個指標：

●網路通訊延時情況。

●資料包組成結構分析(是否有大量的小於511的資料包影響網路傳輸效率)。

●TCP通訊相應情況(慢應答、資料重傳)。

●Teamcenter伺服器是否接入核心網路。

資料庫的檢測主要需要檢測以下幾個指標：

●資料庫SQL語句的執行效率。

●資料庫遊標快取數量。

●資料庫會話連線數。

●資料庫索引是否合理建立。

Teamcenter自身的檢測主要檢測以下幾個指標：

●典型操作場景執行時間(登陸、展開BOM、查詢等)。

●使用者反饋速度較慢的場景執行時間(特別是二次開發的功能)。

●後臺日誌輸出監控。

作業系統的檢測主要需要檢測以下幾個指標：

●高峰時期系統的資源佔用情況(CPU、記憶體)。

●系統I/O情況，是否有阻塞等。

●系統等待時間檢測。

通過上述的檢測可以診斷出類似如下的效能瓶頸：

網路架構不合理造成網路瓶頸。

資料庫相關引數不合理造成效能瓶頸。

Teamcenter整體效能是否在合理區間。

硬體無法符合造成系統整體效能瓶頸。

特定二次開發的功能操作較慢，可能是程式碼存在問題造成效能瓶頸。

作業系統引數不合理造成系統性能瓶頸。

2

效能優化解決思路

利用NX建模，實現了大輪拖駕駛室及底盤零件在Techviz立體視覺化系統中進行產品樣機的評審與互動。通過診斷我們找出了造成系統問題的相關瓶頸，接下來就需要針對已有症狀與推斷出的瓶頸制定解決效能問題的思路。

首先針對網路問題，我們建議採取如下優化思路：

1.將Teamcenter伺服器接入核心層網路，提高Teamcenter網路通訊效率。

2.建立企業軟體白名單庫，遮蔽一些使用廣播造成網路擁塞的小軟體。

3.提升網路頻寬，儘量使研發人員的網路達到百兆到桌面以上。

針對資料庫的引數不合理建議採用如下優化思路：

1.優化共享池與資源池引數，提高資料庫的記憶體利用率。

2.資料庫啟用動態記憶體管理。

3.調整相應的遊標快取引數。

4.將常用的資料庫小表放入記憶體中，提高基礎操作效能。

圖5 資料庫常用小表放入記憶體

針對作業系統引數的不合理採用如下優化思路：

1.調整VMO引數，優化記憶體結構。

2.對作業系統與儲存系統邏輯卷的不合理劃分進行重構。

3.作業系統上對ORACLE啟用大頁面。

針對特定的二次開發功能操作慢的問題，採取如下的二次開發程式碼優化思路：

二次開發程式碼的優化方式分為時間複雜度分析、API是否優選、程式碼結構是否最優、隱患排查等幾個方面。

圖6 二次開發程式碼優化思路

時間複雜度分析：

分析程式碼的時間複雜度主要涉及演算法中的時間複雜度，最終的分析要理論結合實際。比如：A演算法有兩層迴圈(時間複雜度n)，而B演算法只有一層迴圈+若干操作(時間複雜度1)。這並不能說明B演算法比A演算法優，因為A演算法在業務上可能n始終小於2，此時就需要分析加實驗，根據多次實驗結果進行選擇。

API是否優選：

某些情況下，同一種功能可以通過不同的API進行具體實現，但是API可能內部有一些是通過遍歷，而另一些可能是精確查詢得出結果，此時就需要進行API的優選。

程式碼結構是否最優：

程式碼結構的優選是在程式碼實現的功能相同的情況下，對程式碼的結構進行優選。比如程式碼中的某一段先行執行，執行的結果可能在後面得到使用，則此時需要提升程式碼段到前面防止多次讀取。

隱患排查：

隱患排查是需要排查程式碼中未考慮到，也不會馬上產生惡劣效果的部分。比如記憶體釋放的排查，記憶體釋放未執行可能造成記憶體洩漏，使用者在剛開始使用時並不會馬上體現出來，但在使用一段時間後就可能造成一些效能影響。

3

效能優化實施

效能優化的實施由於是在生產系統上直接進行調整，具有較大的風險，所以在進行效能優化的實施前需要制定完整的實施計劃、備份與回退策略。

調優準備階段進行相應的系統備份是保證調優工作安全平穩進行的基礎。對於系統備份建議分如下幾部分進行：

圖7 系統備份策略

資料庫備份：資料庫備份包括資料庫全域性備份與Teamcenter資料庫例項備份。

檔案伺服器備份：檔案伺服器備份包括對Teamcenter的Volume進行備份，同時還包括對伺服器的TCData目錄備份。Volume用於存放Teamcenter系統中的相應圖文件檔案等，TCData用於存檔相應的系統環境變數的資訊。

作業系統備份：作業系統備份包括對AIX伺服器上的作業系統進行備份，其中重點對一些配置檔案進行備份。

調優引數記錄：首先需要將一個調優週期內要調整的所有引數記錄到一張Excel表中，將初始值放入表格中，每一次調整都要寫上調整值與調整時間。如下表所示：

表1 調優引數記錄

當調優引數未起作用或引起負面效果後，需要對受影響部分進行回退操作。回退方式分為引數回撥、系統區域性還原、系統整體還原。對整個環境的影響是系統整體還原>系統區域性還原>引數回撥。所以我們建議能使用引數回撥解決的，就不要使用系統區域性回撥，能使用系統區域性回撥解決的，就不要使用系統整體還原。根據調優的常見情況，在調優前需要制定類似表2的回退策略表：

最後需要針對每一調優項按照時間順序制定調優計劃，並根據計劃在測試機上進行一次完整的演練。

表2 回退策略表

系統調優採用的是迭代調整方式。因為引數的調整要結合實際的情況，大多數時候無法做到一步到位，對於某些引數最好也是適當的增加上去，起到降低風險的作用。具體的調優流程圖如下：

圖8 調優實施流程

4

效能優化效果檢測

系統性能的最終結果需要反饋到資料上，通過與調優之前對應操作的資料進行比對，可以得出最終效能優化的效果，下面是在某企業中經過兩次調優並增加記憶體後的結果：

1.系統基礎操作效能得到提升，指標如下：

●展開Item效能提升79.8%。

●展開資料夾效能提升44.5%。

2.BOM相關操作效能提升，指標如下：

●傳送一個較小的BOM到PSE的效能提升35.6%。

●展開同一個中小型BOM的效能提升30%。

3.登陸調優後兩層客戶端有一定提升，改為四層客戶端後指標提升更為明顯。

4.作業系統效能指標有較大提升：

●CPU的平均等待時間，由原來的31.5%降低到了20%，降幅達到36.5%。

●最高等待時間由原來的42%降低到了35.8%，降幅達到14.7。

●作業系統磁碟等待由80%左右降低到了1%以內。

●資料庫表空間的磁碟的負荷由一塊磁碟分攤到了4塊磁碟上，I/O讀寫效率大幅提升。

5.通過優化二次開發程式碼，對業務部門抱怨最多的工藝模組效能提升明顯：

表3 優化二次開發程式碼後工藝模組的效能提升幅度

5

總結

通過本文可以瞭解到，經過一系列的效能診斷，可以分析出造成Teamcenter效能問題的瓶頸。在條件允許的情況下根據適當的方法可以使Teamcenter的效能得到提升。在Teamcenter調優的實施過程中，一定要專業的團隊根據環境進行特定分析並進行完整備份後進行，因為調優工作有較大的風險。同時由於不同的環境造成效能問題的原因各不相同，最終的調優效果肯定也會存在一定的差異。

END