1.摘要
大型數據分析框架正在朝着縮短任務執行時間和提高並行度的方向發展來提供低延遲，任務調度器面臨的主要挑戰是在幾百毫秒內完成高度並行的作業調度，這需要在合適的機器上每秒調度數百萬個任務，同時提供毫秒級的延遲和高可用性。本文證明了去中心化、隨機抽樣方法可提供最佳性能，同時避免了中心化設計存在吞吐量和高可用的問題。本文在110臺計算機集羣上部署Sparrow，並證明Sparrow的性能與理想的調度程序的誤差在12%以內。
2.介紹
當今的數據分析集羣運行的時間越來越短，作業的任務越來越多。在對低延遲交互式數據處理的需求的刺激下，研究機構和同行業共同努力產生了一些框架（例如Dremel，Spark，Impala）可以在數千臺機器上工作，或將數據存儲在內存以秒級分析大量數據，如圖1所示。預計這種趨勢會繼續推動開發針對次秒級響應時間的新一代框架響應時間進入100ms左右，這讓新的強大的應用程序成爲可能；例如，面向用戶的服務在每個查詢的基礎上將能夠運行復雜的並行計算，比如語言翻譯和高度個性化的搜索。
圖1：數據分析框架分析大量數據的延遲非常低
調度由簡短的次秒級任務組成的作業極具挑戰，這些作業不僅是因爲低延遲框架出現的，也有將長時間運行的批處理作業分解爲大量短時間任務的原因。當任務以幾百毫秒的速度運行時，調度決策必須有很高的吞吐量：一個由10000個16核機器組成的集羣並運行100毫秒任務，每秒可能需要超過一百萬個調度決策。調度延遲還必須非常低：對於100 ms的任務，超過幾十毫秒的調度延遲（包括排隊延遲）開銷是無法接受的。最後，處理框架逼近交互式時間範圍，並應用於面向用戶的系統中，高可用性也是必要的，這些設計需求不同於傳統的批處理框架。
修改當前中心化調度程序來支持亞秒級並行任務面臨艱鉅的工程挑戰，支持亞秒級任務需要處理比現有最快的調度程序（比如Mesos, YARN, SLURM）高兩個數量級的吞吐量；通過單個節點調度和啓動所有任務很難滿足此設計要求。另外，要實現高可用性需要在亞秒級的時間內恢復大量狀態。
本文探討了設計領域中的相反極端：建議從一組自動運行且沒有中心化或邏輯中心化狀態的機器進行調度。去中心化設計提供了非常優秀的擴展性和可用性，系統可以通過添加更多調度器來支持更多請求，如果調度器異常，則用戶可以將請求定向到其他調度器。考慮到同時運行的調度程序可能會做出相互衝突的調度決策，因此去中心化設計的關鍵挑戰是提供與中心化調度器可比的響應時間。
本文提出了Sparrow，一種無狀態的分佈式調度器，它將Power of Two Choices負載均衡技術應用並行任務調度的領域。Power of Two Choices是通過探測兩個隨機服務器並將任務放置在隊列較少的服務器上來調度每個任務。本文介紹三個方法，可以讓Power of Two Choices在運行並行作業的集羣有效果：
批量抽樣：對於並行作業，Power of Two Choices表現較差，因爲作業的響應時間取決於最後完成任務的等待時間，而最後完成任務的等待時間在Power of Two Choices下仍然很高。批量抽樣將多選方法（A Generalization of Multiple Choice Balls-into-Bins，）應用於並行作業調度領域來解決此問題。批量抽樣不是將每個任務單獨進行抽樣，而是將m個任務放置在d*m個隨機選擇的worker中負載最少的worker上（d> 1）。本文通過分析證明，與Power of Two Choices不同，批量抽樣的性能不會隨着作業並行度的提高而降低。
後期綁定：Power of Two Choices存在兩個性能問題：1.服務器隊列長度不能很好地表示等待時間；2.由於消息傳遞延遲，多個並行調度器可能會遇到競爭狀況。後期綁定通過將任務延遲分配給節點，直到節點準備好運行任務來避免這些問題，並且與只做批次抽樣相比，平均響應時間減少了多達45％。
策略和約束：Sparrow在worker上使用多個隊列來實現全局性策略，並支持分析框架需要的按作業和按任務放置的約束。無論是策略執行和約束處理用一個簡單的理論模型都可以解決，但是兩者在實際集羣中都起着重要作用。
本文將Sparrow部署在110臺機器上的羣集中以評估其性能。調度TPC-H查詢時，Sparrow的響應時間與理想調度程序的差距在12％以內，調度中值排隊延遲小於9ms，並在小於120ms的時間內從故障中恢復。Sparrow可爲任務較短的作業提供較短的響應時間，即使任務數量要大3個數量級。儘管採用了去中心化設計，Sparrow仍保持合計（累加）的份額公平，同時隔離不同優先級的用戶，這樣惡意的低優先級用戶最多可將高優先級作業的響應時間增加40％。仿真結果表明，隨着羣集增加到數以萬計的CPU核，Sparrow表現依然良好。本文的結果表明，實現低延遲、並行的workload，使用Sparrow分佈式調度可以作爲替代中心化調度的一種可行的方案。
3.設計目標
本文針對低延遲應用程序的細粒度任務調度，與批處理workload相比，低延遲workload對調度的要求更高，因爲批處理workload會用更多的時間獲取資源，任務調度相對很少。爲了支持由亞秒級任務組成的workload，調度程序必須提供毫秒級的調度延遲，並每秒支持數百萬個任務調度決策。此外，由於低延遲框架可用於增強面向用戶的服務的能力，低延遲workload的調度程序應該能夠容忍故障。
Sparrow提供細粒度的任務調度，這是對羣集資源管理器功能的補充。Sparrow不會爲每個任務啓動新的進程，相反，Sparrow假定每臺worker計算機上已經運行了一個運行時間很長的進程，因此Sparrow在啓動任務時僅需要發送簡短的任務描述（而不是大的二進制文件，比如執行任務的鏡像）。這些執行程序進程可以在集羣啓動的時候啓動，或者Sparrow與其他框架（比如傳統的批處理處理框架）一起通過集羣資源管理器（例如YARN, Mesos, Omega）分配資源。
爲了提供更高的調度吞吐量和更低的延遲，Sparrow在調度和權衡很多由尖端的中心化調度程序支持的複雜特性上也會做出近似。特別是，Sparrow不允許某些類型的放置約束（例如x用戶任務不能和y用戶任務運行在同一個機器），不支持bin packing（任務指定機器運行）和gang scheduling（作業的任務要麼全調度要麼全不調度）。
Sparrow以易於擴展、最小化延遲並保持系統設計簡單的方式支持少量特性，許多應用程序運行來自多個用戶的低延遲查詢，因此當總需求超過容量時，Sparrow會強制執行嚴格的優先級或加權份額公平。Sparrow還支持基本的作業放置約束，例如按任務的約束（例如輸入數據在哪任務就在哪執行）和按作業的約束（所有任務必須放置在具有GPU的機器上）。這些特性類似於Hadoop MapReduce和Spark的調度器。
4.基於抽樣的並行作業調度
傳統的任務調度器維護着哪些worker上正在運行的任務的完整視圖，並根據這個視圖將任務放置到可用的worker上。Sparrow採取了截然不同的方法：多個調度器並行運行，並且調度器不維護有關集羣負載的任何狀態。爲了調度作業的任務，調度器依賴從worker獲取的瞬時負載信息。Sparrow的方法將現有的負載平衡技術擴展到並行作業調度的領域，並引入了後期綁定以提高性能。
4.1術語和作業模型
我們假設一個集羣由執行任務的worker和將任務分配給worker的scheduler組成。作業（job）包含m個任務，每個任務(task)分配給一個worker。作業可以由任何scheduler處理。worker在固定數量的槽位中運行任務；避免使用更復雜bin packing，因爲這會增加設計的複雜性。如果併發的任務數量多於worker的槽位，將對新任務進行排隊，直到現有任務釋放足夠的資源來運行新任務。本文使用等待時間(wait time)來描述從任務提交scheduler到任務開始執行的時間，使用服務時間(service time)來描述任務在worker上運行的時間。作業響應時間(job response time)描述了從作業提交到scheduler到最後一個任務完成執行的時間。本文使用延遲（delay）來描述由於調度和排隊而導致的作業中的總延遲。通過計算作業響應時間和所有任務以零等待時間被調度的作業響應時間（相當於作業中任務最長的服務時間）之間的差值來計算延遲。
在評估不同的調度方法時，假設每個作業都是能夠一波任務運行。在實際集羣中，當m大於分配給用戶的槽位數時，作業可能會多波任務運行。對於多波作業，scheduler可以執行早期任務進而不影響作業響應時間。
在評估調度技術時，假設採用單波作業模型，因爲單波作業最能考驗調度分佈式調度方法：即使是單個延遲的任務也會影響作業的響應時間。當然，Sparrow也是可以處理多波工作的。
4.2單任務抽樣（per-task sampling）
Sparrow的設計靈感來自Power of Two Choices的負載均衡技術，該技術使用無狀態的隨機方法可以縮短預期的任務等待時間。Power of Two Choices提出了對將任務隨機分配給worker的簡單改進：將每個任務放置在兩個隨機選擇的worker負載最少的一個上。與使用隨機放置相比，以這種方式分配任務指數級減少了等待時間。
首先考慮將Power of Two Choices技術直接應用於並行作業調度，scheduler會爲每個任務隨機選擇兩臺worker，並向每臺worker發送一個探測消息（probe），探測消息是輕量級的RPC調用。每個worker都會用當前排隊的任務數響應探測消息，然後scheduler將任務放在隊列最短的worker上。scheduler對作業中的每個任務重複此過程，如圖2所示。將Power of Two Choices技術的應用稱爲單任務抽樣。
圖2：並行放置作業的兩個任務，單任務抽樣選擇長度爲1和3的隊列
與隨機放置相比，單任務抽樣可以提高性能，但與omniscient scheduler相比，其性能仍然差2倍甚至更多（omniscient scheduler基於worker完整的負載信息使用貪婪調度算法，將任務放在空閒的worker（如果有）上，否則使用FIFO排隊）。直觀地講，單任務抽樣的問題在於作業的響應時間取決於任何一個任務的最長等待時間，使平均作業響應時間大大高於（並且對最後完成任務特別敏感）平均任務響應時間。本文模擬了由10,000個4覈計算機、網絡往返時間爲1ms組成的集羣中單任務抽樣和隨機放置的情況。作業是Poisson process(最廣泛的計數過程之一)，每個作業包含100個任務。現實中作業的任務運行時間是以100ms爲均值指數分佈的，但是某些特殊的作業的任務的執行時間是相同的（使用這種分佈可以給調度帶來了最大的壓力，當作業中的任務的持續時間不同時，較短的任務可以具有更長的等待時間而不會影響作業響應時間）。如圖3所示，響應時間隨着負載的增加而增加，這是因爲scheduler成功找到空閒計算機放置任務的成功率較低。與隨機放置相比，在80％的負載下，單任務抽樣將性能提高了3倍以上，但響應時間仍然是omniscient scheduler所提供的響應時間的2.6倍以上。
圖3：10000個4覈計算機的模擬集羣中運行100任務/作業的調度技術比較
4.3批量抽樣（batch sampling）
批量抽樣改進了單任務抽樣，通過在特定作業內共享所有探測信息。單任務抽樣一對探測請求可能運氣不好抽樣了兩臺負載率較高的機器（如圖2中Task1那樣），而另一對可能很幸運抽樣到兩個負載率較低的機器（如圖2中Task2那樣），有一個負載率最低的機器並沒有使用。批量抽樣彙總了針對作業所有任務探測的負載信息，並將作業的m個任務放置在所探測的所有工作機中負載最少的worker。在圖2的示例中，單任務抽樣將任務放置在長度爲1和3的隊列中，批量抽樣將Task1和Task2都放置到了Task2抽樣的worker上，如圖4所示：
圖4：批量抽樣選擇長度爲 1 和 2 的隊列
要使用批量抽樣進行調度，scheduler會隨機選擇d*m個worker（d≥1），scheduler將發送探測消息給每個d*m worker，與單任務抽樣一樣，每個worker都會答覆排隊任務的數量。scheduler將作業的m任務放在負載最少的m個worker。除非另有說明，否則本文默認d = 2。
如圖3所示，與單任務抽樣相比，批量抽樣可提高性能。在80％的負載下，批量抽樣的響應時間是單任務抽樣的響應時間的73%。儘管如此，批量抽樣的響應時間仍比omniscient scheduler的響應時間差1.92倍。
4.4基於抽樣調度的問題
由於兩個問題，基於抽樣的技術在高負載下的性能較差：1.scheduler根據worker上的隊列長度放置任務，但是隊列長度僅提供對等待時間的粗略預測。試想一個scheduler放置一個任務探測兩個worker的情況，其中一個排隊兩個50ms任務，另一個排隊一個300ms任務。scheduler會將任務放入只有一個任務排隊的worker中即使該隊列將導致300ms較長等待時間。儘管worker可以估計任務執行時間而不是隊列長度來進行答覆，但是準確預測任務執行時間卻非常困難。2.幾乎所有的任務執行時間估算都需要準確才能使這種技術有效，因爲每個作業都包含許多並行任務，所有任務都必須放在等待時間短的機器上以確保良好的性能。
抽樣還受到競爭條件的困擾，在該競爭條件下，多個scheduler同時將任務放置在看起來負載較輕的worker上。試想兩個不同的scheduler同時探測同一臺空閒工作機w的情況，顯而易見，兩個scheduler都可能在w上放置任務。但是，放置在worker上的兩個任務中只有一個會進入空隊列。如果scheduler知道任務到達時w將不會處於空閒狀態，則排隊的任務可能會被放置到其他的隊列中。
4.5後期綁定
Sparrow引入了後期綁定來解決上述問題，worker不會立即答覆探測消息，而是在worker內部隊列的末尾爲任務保留位置。當此保留位置到達隊列的頭部時，worker將向scheduler發送RPC請求一個相應作業的任務。scheduler將作業的任務分配給前m個worker作爲回覆，回覆其餘(d − 1)m worker無任何操作，表明所有任務均已啓動。通過這種方式，scheduler保證任務將被放置在被探測的worker上，並在最快的時間啓動它們。對於任務執行時間呈指數分佈、集羣負載爲80％時，後期綁定提供的響應時間是批量抽樣的響應時間的55%，使響應時間與omniscient scheduler相比達到5％（4毫秒）之內（如圖3所示）。
後期綁定的缺點是，worker在向scheduler發送RPC請求新任務時處於空閒狀態，當前我們知道的所有羣集調度器權衡利弊都會做出這樣的選擇：scheduler會等待分配任務，直到worker發出信號說它有足夠的可用資源來啓動任務。與在worker上排隊的任務相比，這種折衷會導致2％的效率損失。worker在請求任務時空閒的時間佔比是 (d · RTT)/(t + d · RTT) （其中 d 表示每個任務的探測數，RTT 表示平均網絡往返時間，t 表示平均任務服務時間）。在雲服務器上部署未優化的網絡棧，平均網絡往返時間是 1 毫秒。我們預計最短的任務將在 100ms 內完成，並且調度程序將使用不超過 2 的探測比，最多導致 2% 的效率損失。對於本文的目標workload，這種取捨是值得的，如圖 3 所示的結果（其中包含網絡延遲）就說明了這一點。在網絡延遲時間與任務運行時間比較相當的環境，後期綁定不會帶來價值。
4.6主動取消
scheduler啓動某個作業的所有任務後，可以通過以下兩種方式之一來處理剩餘的掛起的探測消息（作業的任務探測消息發給了worker1,worker2......workern，worker1,worker2.....workeri取走了所有任務，那麼剩餘的worker的探測消息就是掛起的）：它可以主動向所有掛起的worker發送取消RPC，也可以等待worker請求任務並通過沒有剩餘未啓動的任務來答覆這些請求。我們使用模擬環境對使用主動取消的好處進行建模，發現主動取消在集羣95％的負載下將中位響應時間降低了6％。在給定的負載ρ下，worker的忙碌時間超過了ρ的時間：他們花費ρ的時間來執行任務，但是他們花費額外的時間從scheduler中請求任務。通過使用1毫秒網絡RTT進行取消，探測比率爲2，平均任務時間爲100毫秒，可以將worker的忙碌時間減少大約1％；因爲當負載接近100％時響應時間接近無窮大，因此worker在忙碌時間上減少1％導致響應時間明顯減少。如果worker在已經請求任務之後收到取消，則取消會導致其他RPC：在95％的負載下，取消會導致2％的額外RPC。我們認爲，額外的RPC是提高性能的值得權衡的選擇，並且Sparrow實現了主動取消。當網絡延遲與任務執行時間的比率增加時，主動取消任務的幫助會更大，因此，隨着任務執行時間的減少，主動取消將變得更加重要，而隨着網絡延遲的減少，主動取消的重要性將降低。
5.調度策略與約束
Sparrow的目標是在去中心化的框架內支持少量有用策略，本節介紹支持的兩種流行的調度策略：在哪個worker啓動各個任務的約束，以及在資源充足時用戶間隔離策略控制用戶的相對性能。
5.1放置約束處理
Sparrow處理兩種類型的約束，按作業和按任務的約束。數據並行框架通常需要此類約束，例如，在保存任務輸入數據的磁盤或內存所在計算機上運行任務。如第2節所述，Sparrow不支持某些通用資源管理器支持的許多類型的約束（例如，作業間親和）。
按作業的約束（例如，所有任務都應在具有GPU的worker上運行）在Sparrow調度器很容易處理。Sparrow從滿足約束的worker子集中隨機選擇d*m候選worker。一旦選擇了要探測的d*m worker，調度便會按照前面描述的進行。
Sparrow還處理按任務約束的作業，例如將任務限制爲在輸入數據所在的計算機上運行。將任務與輸入數據放置在一起通常會減少響應時間，因爲不需要通過網絡傳輸數據。對於具有按任務約束的作業，每個任務約束不同造成可抽樣的worker不同，因此Sparrow無法使用批量抽樣來彙總作業中所有探測信息。相反，Sparrow使用單任務抽樣，其中scheduler從要限制其運行的worker集合中選擇兩臺worker來探測每個任務，並進行後期綁定。
Sparrow對具有按任務約束的作業在每個任務抽樣上實現了一個小的優化。與其對每個任務進行單獨探測，Sparrow儘可能跨任務共享信息。例如假設一種情況，任務0被約束在機器A，B和C中運行，而任務1被約束在機器C，D和E中運行。假設scheduler檢測了任務0的計算機A和B它們負載較重，對於任務1探測機器C和D都是空閒的。在這種情況下，即使C和D兩臺機器都作爲任務1的探測對象，Sparrow也會將任務0放置在機器C上，將任務1放置在機器D上。
儘管Sparrow不能對具有按任務約束的作業使用批量抽樣，但是我們的分佈式方法仍然爲這些作業提供接近最佳響應時間，因爲即使是中心化scheduler，對於放置每個任務的位置也只有很少的選擇。具有按任務約束的作業仍可以使用後期綁定，因此可以確保scheduler將每個任務放置在將更早運行任務的兩臺探測計算機中的任何一臺上。像HDFS這樣的存儲通常會數據會有三副本分別存儲在三臺不同的計算機上，因此讀取輸入數據的任務將被限制爲在輸入數據所在的三臺計算機之一上運行。結果，即使是理想的omniscient scheduler，對於放置每個任務的位置也沒有什麼其他選擇。
5.2資源分配策略
當對資源的總需求超過容量時，集羣調度程序將根據特定策略分配資源。Sparrow支持兩種類型的策略：嚴格優先級和加權份額公平。這些也是其他調度程序（包括Hadoop Map Reduce調度程序）提供的策略。
許多羣集共享策略簡化爲使用嚴格的優先級，Sparrow通過在worker上維護多個隊列來支持此類策略。FIFO、最早deadline優先、爲每個作業分配優先級以及優先運行最高優先級的作業。例如，以將任務deadline較早的作業分配給更高的優先級。集羣操作者也可能希望直接分配優先級，例如將生產作業優先或者臨時作業優先。爲了支持這些策略，Sparrow在每個worker上爲每個優先級維護一個隊列。當資源變爲空閒時，Sparrow會從優先級最高的非空隊列中響應探測消息。此機制以簡單性換取準確性作爲代價：節點無需使用複雜的協議來交換有關正在等待調度的作業的信息，但是如果低優先級作業的探測消息到達沒有高優先級作業的節點，則低優先級作業可以在高優先級作業之前運行。我們認爲這是一個值得的取捨：此分佈式機制爲高優先級用戶提供了良好的性能。當高優先級任務到達運行低優先級任務的worker時，Sparrow當前不支持搶佔，未來會探索任務搶佔。
Sparrow還可以執行加權份額公平，每個worker爲每個用戶維護一個單獨的隊列，並對這些隊列執行加權公平排隊。該機制可提供預期的羣集範圍內的份額公平：使用相同worker的兩個用戶將獲得與他們的權重成比例的份額，以此擴展，因此使用同一組機器的兩個用戶也將被分配與他們的權重成比例的份額。我們選擇這種簡單的機制是因爲更精確的機制（例如Pisces）會增加相當大的複雜性，後續的章節會說明Sparrow的簡單機制提供了近乎完美的份額公平。
6.分析
在研究實驗評估之前，通過分析發現，在進行一些簡化的假設後（不管任務執行時間的分佈）批量抽樣可達到接近最佳的性能。第4節證明了Sparrow的表現不錯，但僅在一種特定的workload下，本節將這些結果推廣到所有workload。本文還證明了通過單任務抽樣，性能會隨着作業中的任務數量增加呈指數下降，使其不適合並行workload。
爲了分析批量和單任務抽樣的性能，本文檢驗了將所有任務放在空閒計算機上的可能性，或等效地提供零等待時間。與最佳調度程序相比，量化Sparrow的方法多久將作業交給空閒的worker就可以確定Sparrow的性能。
爲了進行此分析，本文做出一些簡化的假設。本文假設網絡延遲爲零，服務器數量無限大，並且每個服務器一次運行一個任務。本文的實驗評估顯示了在沒有這些假設的情況下的結果。
|
n |
集羣中服務器數量 |
|
ρ |
負載 |
|
m |
每個作業的任務數量 |
| d |
每個任務探測數量 |
| t |
平均任務服務時間 |
|
ρn/(mt) |
平均請求到達率 |
表1：符號說明
表2：三種不同的調度技術，作業等待時間爲零的概率
數學分析證實了第4章節中的結果，表明單抽樣對並行作業的表現效果較差。將指定任務放置在空閒計算機上的概率是1減去所有探測消息命中繁忙計算機的概率：1-ρd（其中ρ表示集羣負載，d表示探測比率，詳情見表1）。作業中所有任務分配給空閒計算機的概率爲(1-ρd)m（如表2所示），因爲所有m組探測消息必須命中至少一臺空閒計算機。這種可能性隨着任務中任務的數量增加呈指數下降，這使得單任務抽樣不適用於調度並行任務。圖5說明了10個任務和100個任務的作業等待時間爲零的概率，並且證明在20％的負載下，100個任務的作業經歷零等待時間的可能性降至<2％。
圖5：單核環境中使用隨機放置、單任務抽樣(d=2)和批量抽樣(d=2)作業零等待時間的概率
批量抽樣比單任務採樣可以在集羣負載高得多的情況下將作業的所有任務放在空閒計算機上，可以推出，只要d≥1/(1-ρ)，批量抽樣就可以將所有m個任務放在空隊列中。最重要的是，該表達式不取決於作業中的任務數（m）。圖5展示了這種效果：對於10個任務和100個任務的作業，在50％的負載下零等待時間的概率從1降低到0。
到目前爲止的分析考慮了一次只能運行一個任務的機器，但是，當今的集羣通常都是多核計算機。多核計算機明顯提高了批量抽樣的性能，假設一個模型，其中每個服務器可以同時運行c個任務。每次探測等於探測了c個處理單元上的負載，而不只是一個負載，這增加了找到運行每個任務的空閒處理單元的可能性。爲了分析多核環境中的性能，本文做出兩個簡化的假設：首先，本文假設一個核處於空閒狀態的概率與同一臺機器上其他核是否處於空閒狀態無關；其次，本文假設即使多個核處於空閒狀態，scheduler也最多在每臺計算機上放置1個任務（在空閒計算機上放置多個任務會加劇“淘金熱效應”，在此情況下，許多scheduler會同時將任務放置在空閒計算機上）。基於這些假設，可以將表2中的ρ替換爲ρc以獲得圖6所示的結果。與單核結果相比，這些結果得到了顯著改善：對於每臺機器4個內核，每個作業100個任務的批量抽樣，批量抽樣在負載高達79％的情況下可獲得接近完美的性能（99.9％的作業零等待時間）。該結果表明，在一些簡化的假設下，無論任務執行時間的分佈如何，批量抽樣都表現良好。
圖6：在四核服務器系統中作業零等待時間的概率