Amazon Managed Service for Apache Flink 之前稱為 Amazon Kinesis Data Analytics for Apache Flink。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
解決效能問題
本節包含可以透過檢查來診斷和修正效能問題的徵狀清單。
如果資料來源是 Kinesis 串流，效能問題通常呈現為 millisbehindLatest 指標高或增加。對於其他來源，您可以檢查代表從源讀取時滯後的類似指標。
瞭解資料路徑
調查應用程式的效能問題時，請考慮資料所採用的整個路徑。下列應用程式元件如果未正確設計或佈建，可能會成為效能瓶頸並造成背壓：
資料來源和目的地：確保與應用程式互動的外部資源是針對應用程式將遇到的輸送量而正確佈建。
狀態資料：確保應用程式不會太頻繁地與狀態存放區互動。
您可以最佳化應用程式正在使用的序列化程式。默認的 Kryo 序列化程序可以處理任何可序列化類型，但是如果您的應用程序僅以類型存儲數據，則可以使用更高性能的序列化程序。POJO如需有關 Apache Flink 序列化程式的詳細資訊，請參閱 Apache Flink 文件中的資料類型與序列化
。 運算子：確保運算子實作的業務邏輯不是太複雜，或者您不會在處理每筆記錄時建立或使用資源。還要確保應用程式不會太頻繁地建立滑動或輪轉視窗。
效能疑難排解解
本節包含效能問題的潛在解決方案。
CloudWatch 監視層級
確認「 CloudWatch 監視層級」未設定為太詳細的設定。
Debug 監控日誌層級設定會產生大量的流量，這會造成背壓。您只能在主動調查應用程式問題時使用它。
如果您的應用程式具有較高的 Parallelism 設定值，使用
Parallelism 監控指標層級也會產生大量流量，進而導致背壓。只有在您的應用程式 Parallelism 不足或調查應用程式問題時，才使用此指標層級。
如需詳細資訊，請參閱控制應用程式監控層。
應用程式CPU量
檢查應用程式的 CPU 指標。如果此指標高於 75%，您可以啟用自動擴展，允許應用程式為自己配置更多資源。
如果啟用了 auto 擴展，則在 15 分鐘內的使用量超過 75% 時，應CPU用程式會配置更多資源。如需擴展的詳細資訊，請參閱下面的適當管理擴展一節和在 Apache Flink 的受管理服務中實作應用程式調整。
注意
應用程式只會根CPU據使用情況自動調整規模。應用程式不會自動擴展以回應其他系統指標，例如 heapMemoryUtilization。如果應用程式在其他指標上具有較高的使用量，請手動增加應用程式的平行處理層級。
應用程式平行
增加應用程式的平行處理層級。您可以使用UpdateApplication動作的ParallelismConfigurationUpdate參數更新應用程式的平行處理原則。
根據預設，應用程式的最大值KPUs為 64，並且可以透過要求提高限制來增加。
務必基於每個運算子的工作負載指派運算子的平行處理層級，而不僅僅是單獨增加應用程式平行處理層級。請參閱下文的操作員並行。
應用程式日誌記錄
檢查應用程式是否正在記錄正在處理的每筆記錄項目。在應用程式具有高輸送量時，為每筆記錄寫入日誌項目將會導致資料處理中出現嚴重瓶頸。若要檢查此狀況，請查詢您的日誌，找出應用程式隨處理的每筆記錄所寫入的日誌項目。如需如何讀取應用程式日誌的詳細資訊，請參閱 使用日誌見解分析 CloudWatch 日誌。
操作員並行
確認應用程式的工作負載在工作者處理序之間平均分配。
如需調整應用程式運算子工作負載的相關資訊，請參閱運算子擴展。
应用逻辑
檢查您的應用程式邏輯是否有效率低或性能不佳的操作，例如存取外部相依性 (例如資料庫或 Web 服務)，存取應用程式狀態等。如果外部相依性效能不高或無法可靠地存取，也可能會阻礙效能，這可能導致外部相依性傳回 HTTP 500 錯誤。
如果您的應用程式使用外部相依性來富集或以其他方式處理傳入資料，請考慮改用非同步 IO。如需詳細資訊，請參閱 Apache Flink 文件
應用記憶體
檢查應用程式是否有資源洩漏。如果應用程式未正確處置執行緒或記憶體，您可能會看到 millisbehindLatest、CheckpointSize 和 CheckpointDuration 指標急遽增加或逐漸增加。此情況還可能導致任務管理員或作業管理員失敗。
