背景信息

當遇到作業運行較長時間仍未結束且通過Logview難以定位原因，或作業運行結束后，發現作業運行時長達不到預期（作業運行慢），您需要分析是否是由于資源供給問題導致的。

MaxCompute提供作業分析功能，數據開發人員和管理員可通過MaxCompute控制臺的作業分析功能查看歷史作業和正在運行的作業，方便了解作業資源消耗詳情。

注意事項

下述典型案例的評估方式比較簡單，在實際業務實施過程中，您需要綜合多方面考慮，建議您依據實際情況調整作業屬性，并關注調整后的效果。

典型場景一：包年包月預留資源不足導致作業運行慢

某公司購買了包年包月預留計算資源50 CU供作業使用，每天有十余批（一千多個）作業固定運行在這些資源上。

數據開發工程師小K認為Instance ID為20240717020015831xxxxxxxxxxxx的作業運行時長過長，影響后續業務流程，于是前往MaxCompute控制臺的工作區>作業運維頁面搜索到該作業，并單擊操作列的分析進行查看。

可以通過作業級別資源消耗圖表發現，包年包月預留計算資源50 CU已全部被占用，該作業也已經使用了大多數計算資源，但由于整體資源有限，Quota級別的等待CU也居高不下，說明預留計算資源不足以及時消化所有作業的請求，單作業也始終存在未被消化的請求，因此作業運行較慢。

如遇到上述情況，您可以參考以下兩種解決方案：

• 評估是否可以調整作業發起時間，避免集中請求資源而導致預留資源不足。

• 作業請求資源情況無法調整，需要升配包年包月資源，您可以前往成本優化頁面，設置您的期望作業完成時間，查看系統推薦的資源配置方案。

典型場景二：多作業同時搶占資源導致作業遲遲無法開始運行

某公司購買了包年包月預留計算資源50 CU供作業使用，每天有十余批（一千多個）作業固定運行在這些資源上。

數據開發工程師小K發現Instance ID為20240717020020365xxxxxxxxxxxx的作業運行時間過長，影響后續業務流程，于是前往MaxCompute控制臺的工作區>作業運維頁面搜索到該作業，發現該作業總運行時長為21分鐘17秒，其中有超過一半時間都在等待，于是單擊操作列的分析查看等待原因。

可以看到，該作業在提交后的前13分鐘一直處于等待資源狀態，而Quota級別的使用值卻已達到上限，說明有其他作業正在占用資源，導致該作業無法獲取計算資源運行，在13分鐘后開始慢慢獲取資源運行，但始終沒有達到Quota上限值。

您可以通過單擊資源消耗圖橫軸的時間點，查看對應時刻計算Quota級別的資源分配情況，包括所有運行中和等待中的作業資源分配情況，如下圖顯示10:04，有3個優先級為9的作業正在消耗計算資源，但本作業沒有獲取到資源，同時有5個作業存在請求資源被等待的情況。

單擊等待中作業資源分配對應的色塊，可以跳轉查看具體的作業列表，由下圖可知該時刻占用資源較多的作業Instance ID為20240717020015831gza7jdf21uv3。

深入了解作業20240717020015831gza7jdf21uv3的資源消耗情況，可以發現該作業確實在同一時間占用了較多的計算資源。

如遇到上述情況，您可參考以下三種解決方案：

• 評估是否可以調整作業發起時間，避免集中請求資源而導致多作業搶占有限的計算資源。

• 評估是否可以調整作業優先級，如果無法避免多作業在同一時間發起，可以選擇將重要作業的優先級調高，那么在多作業同時請求資源時，會先滿足優先級較高的作業請求。

• 升配包年包月資源，您可以前往成本優化頁面，設置您的期望作業完成時間，查看系統推薦的資源配置方案。

數據開發工程師小k將該節點的任務優先級調整為0，在下一輪作業運行中，可以明顯觀察到作業的等待時間縮短，并且很快就獲取到預留計算資源的50%用于作業計算，總運行時間從21分鐘縮短至6分鐘。