對效能問題進行故障診斷

本節包含可以透過檢查來診斷和修正效能問題的徵狀清單。

如果資料來源是 Kinesis 串流，效能問題通常呈現為 millisbehindLatest 指標高或增加。對於其他來源，您可以檢查代表從源讀取時滯後的類似指標。

了解資料路徑

調查應用程式的效能問題時，請考慮資料所採用的整個路徑。下列應用程式元件如果未正確設計或佈建，可能會成為效能瓶頸並造成背壓：

• 資料來源和目的地：確保應用程式互動的外部資源已正確佈建，以達到應用程式將體驗的輸送量。

• 狀態資料：確保應用程式不會太頻繁地與狀態存放區互動。

  您可以最佳化應用程式正在使用的序列化程式。預設的 Kryo 序列化程式可以處理任何可序列化類型，但是如果應用程式只將資料存儲在 POJO 類型中，則可以使用更高性能的序列化程式。如需 Apache Flink 序列化程式的相關資訊，請參閱 Apache Flink 文件中的資料類型和序列化。

• 運算子：確保運算子實作的業務邏輯不是太複雜，或者您不會在處理每筆記錄時建立或使用資源。還要確保應用程式不會太頻繁地建立滑動或輪轉視窗。

效能疑難排解解決方案

本節包含效能問題的潛在解決方案。

CloudWatch 監控層級

確認未將 CloudWatch 監控層級設定得太詳細。

Debug 監控日誌層級設定會產生大量的流量，這會造成背壓。您只能在主動調查應用程式問題時使用它。

如果您的應用程式具有較高的 Parallelism 設定值，使用 Parallelism 監控指標層級也會產生大量流量，進而導致背壓。只有在您的應用程式 Parallelism 不足或調查應用程式問題時，才使用此指標層級。

如需詳細資訊，請參閱控制應用程式監控層級。

應用程式 CPU 指標

檢查應用程式的 CPU 指標。如果此指標高於 75%，您可以啟用自動擴展，允許應用程式為自己配置更多資源。

如果啟用了自動擴展，則當 CPU 使用率超過 75% 並持續 15 分鐘時，應用程式會配置更多資源。如需擴展的詳細資訊，請參閱下面的適當管理擴展一節和實作應用程式擴展。

注意

應用程式只會根據 CPU 使用率自動擴展。應用程式不會自動擴展以回應其他系統指標，例如 heapMemoryUtilization。如果應用程式在其他指標上具有較高的使用量，請手動增加應用程式的平行處理層級。

應用程式平行處理

增加應用程式的平行處理層級。您可以使用 UpdateApplication 動作的 ParallelismConfigurationUpdate 參數來更新應用程式的平行處理層級。

應用程式的最大 KPU 預設為 64 個，可透過請求提高限制來增加。

務必基於每個運算子的工作負載指派運算子的平行處理層級，而不僅僅是單獨增加應用程式平行處理層級。請參閱下文的運算子平行處理。

應用程式日誌記錄

檢查應用程式是否正在記錄正在處理的每筆記錄項目。在應用程式具有高輸送量時，為每筆記錄寫入日誌項目將會導致資料處理中出現嚴重瓶頸。若要檢查此狀況，請查詢您的日誌，找出應用程式隨處理的每筆記錄所寫入的日誌項目。如需如何讀取應用程式日誌的詳細資訊，請參閱 使用 CloudWatch Logs Insights 分析日誌。

運算子平行處理

確認應用程式的工作負載在工作者處理序之間平均分配。

如需調整應用程式運算子工作負載的相關資訊，請參閱運算子擴展。

應用程式邏輯

檢查您的應用程式邏輯是否有效率低或性能不佳的操作，例如存取外部相依性 (例如資料庫或 Web 服務)，存取應用程式狀態等。如果外部相依性效能不高或無法可靠地存取，也可能會阻礙效能，這可能導致外部相依性傳回 HTTP 500 錯誤。

如果您的應用程式使用外部相依性來富集或以其他方式處理傳入資料，請考慮改用非同步 IO。如需詳細資訊，請參閱 Apache Flink 文件中的非同步 I/O。

應用程式記憶體

檢查應用程式是否有資源洩漏。如果應用程式未正確處置執行緒或記憶體，您可能會看到 millisbehindLatest、CheckpointSize 和 CheckpointDuration 指標急遽增加或逐漸增加。此情況還可能導致任務管理員或作業管理員失敗。