在進行作業恢複時，從檢查點或快照中恢複相較於無狀態啟動，關鍵在於高效地從遠程持久儲存中下載狀態檔案並重建狀態引擎。這一步驟需要執行大量的輸入輸出操作，容易成為恢複過程中的效率瓶頸，可能會造成作業的長時間停滯。本文為您介紹作業啟動和擴縮容過程中瓶頸問題的診斷方法和調優策略，助力您高效提升系統效能。
診斷步驟
在作業啟動或進行擴容操作期間，如果發現作業長時間停留在初始化階段，應首先診斷是否存在初始化瓶頸。以下是推薦的診斷步驟：
使用診斷工具分析運算元狀態：利用Thread Dump、線程動態分析和火焰圖等工具，檢查初始化階段的運算元線程棧。重點關注線程棧是否長時間處於等待狀態，尤其是在Gemini等狀態儲存系統上的操作。診斷工具使用方式請參見分析工具使用方式。
識別狀態運算元的初始化問題：如果發現某個運算元長時間處於初始化狀態，且該運算元涉及狀態處理，那麼可以推斷問題可能出在狀態的下載或重建過程中。
調優策略
為了提升作業啟動和擴容效率，一旦確定大狀態處理是作業初始化的瓶頸，您可以參考如下方案進行針對性調整。
策略 | 策略說明 | 配置方法 | 注意事項 |
動態擴縮容 | 可以實現更快的讓參數配置生效，減少作業啟停對業務的停機時間，方便進行TM動態擴縮容。 | 詳情請參見動態擴縮容與參數動態更新。 | 動態更新為實驗性功能，在動態更新參數時，業務並不是完全不中斷。相比傳統的參數修改模式，動態更新能夠顯著縮短停機時間，但中斷的具體時間長度受到作業拓撲和狀態大小等因素的影響，通常在5秒至1分鐘之間。 |
Local Recovery：本地備份快照加速恢複 | 在本地同時儲存快照，可減少恢複過程中的資料下載需求。當本地磁碟空間充裕時，為首選方案。 | 在運行參數中配置
，配置方法請參見控制台操作 |
|
GeminiStateBackend智能懶載入和延遲剪裁：非同步狀態恢複方案 | 作為平台核心技術GeminiStateBackend，即使面對大規模狀態的作業，也能僅通過下載必要的中繼資料快速啟動，實現對資料的即時處理。隨後，系統將通過非同步下載和智能裁剪技術，有效處理遠程檢查點檔案，顯著降低作業停機時間，提升效率超過90%，詳情請參見企業級狀態後端儲存介紹。 | 在運行參數中配置
，配置方法請參見控制台操作 說明 僅Realtime Compute引擎VVR 6.0.6及以上版本支援該參數。 | 作業剛啟動後的一小段時間內，會非同步下載狀態檔案，作業效能逐步恢複，因此一開始效能會稍微低一些。 |
相關文檔
大狀態作業導致的問題和診斷調優整體思路詳情，請參見大狀態作業調優實踐指南。
Flink SQL由最佳化器根據配置項以及SQL語句來推導產生狀態運算元，想要高效處理有狀態的大規模資料和效能調優，需要對SQL狀態運算元產生機制、管理原則、診斷方法和調優方法有一定瞭解，詳情請參見SQL作業大狀態導致反壓的調優原理與方法。
Flink Datastream API在狀態管理方面提供了靈活的介面，您可以採取相關措施來確保狀態大小可控，避免狀態的無限制增長，詳情請參見DataStream作業大狀態導致反壓的調優原理與方法。