code

2014年10月7日 星期二

Jenkins 作業逾時/超時處理 - Build-timeout Plugin

DeadLock 死結,發生的條件基本上就是有限的資源共用,同時多個事件並行等等,最終資源耗盡只能等待事件完成釋放,而事件等待新的資源發放。這個是Jenkins常發生的逾時情況之一,解法就只能對事件進行仲裁。

我對Jenkins最納悶的問題:Jenkins預設沒有逾時設定,但發生逾時確很頻繁?

當然資源競爭的問題無法請Jenkins解決,也不能期待GC解決。而且造成逾時的問題,還有像網路環境不穩定、機房乖乖過期等。但是造成的結果有一點是相同的,後面多的人在排隊呢!我們可以先看看一個有趣的單位,目前他們 Hudson(Jenkins)運行的情況。

https://hudson.jboss.org/hudson/  以下是寫這篇文章時的取材狀態

10天前開始,這是什麼巫術阿


排隊的在幹嘛阿?在等阿!前面的到底要不要出來阿!?

還好Jenkins的外掛很厲害,作業逾時這種基本需求,肯定有外掛可用,就是Build-timeout Plugin。我們可以利用Build-timeout,來定義各種可能是造成逾時的情況,來中止作業佔用資源無限等待。

本篇相關外掛


目標情境

我們要模擬幾種逾時的情況,測試驗證 Build-timeout 是否有正常運作

第一步:認識build-timeout 設定內容 

安裝build-timeout後,設定會出現在各個專案的組態設定中
build-timeout 主要設定內容 

Time-out strategy 逾時模式

  • Absolute 在指定的時間內沒有完成就算逾時,但設定不可少於三分鐘
  • Elastic 提取先前建置成功時間平均數,當超過150% ~ 400%時算逾時,或超過指定的上限值,無論計算結果為何,逾時最小值為是三分鐘
  • Likely stuck 好像卡住了?定義不明確不建議使用。
  • No Activity 畫面的輸出靜止超過指定秒數,視為逾時


Time-out actions 逾時處理

  • Abort the build 取消建置
  • Fail the build 建置失數,會觸發各種失敗時的事件,建議使用

第二步: 測試 Absolute模式  + Fail the build

測試的方法很簡單,我們只會使用兩個SHELL指令,

  • echo 輸出內容
  • sleep 等待指定的秒數

測試內容,指定超過3分鐘時算逾時,並用sleep模擬200秒的等待。



第三步:測試 Elastic + Abort the build

我們先用sleep指令,做出三次平均90秒的成功建置。指定超過平均150%算逾時,再模擬60秒的等待,反應的結果要為取消建置。

第四步:測試No Activity+Abort the build

指定超過30秒沒有輸出,就算逾時,測試15秒/25秒/35秒各輸出一次,應該要在35秒出現中止。


作業逾時強制中止作業,只是為了讓系統不要全面性停工的手段。如果作業有資源超用的情況,應該還是要用其它手段來防治。例如讓高資源需求的作業到指定的slave進行。或是將他們的排程時間安排於不同時段進行。

沒有留言:

張貼留言