-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implementation of BackboneImbalanceScenario
#1476
Implementation of BackboneImbalanceScenario
#1476
Conversation
目前 Performance Tool 生成的指令在執行上會有一些效能的問題 比如這個指令
他嘗試對 1627 個 Partition 進行對應速度的 throttle,該生成結果預期 Performance Client 會輸出 359 MB/s 的資料量,但實際上 Performance Client 只有輸出 30 MB/s 上下的吞吐量,然後跑 Performance 的設備有 CPU 資源用盡的跡象。 |
我後面會去追看看這個問題 |
大概有大量的collection操作太操,如果這是嚴重的技術問題(例如單機上操作的瓶頸),我們就要逐步移動到使用分散式版本的perf (see https://github.com/skiptests/astraea/blob/main/docs/connector/performance_banchmark_connector.md) 不過該分散式版本功能還很陽春 @@ |
可否先開議題? |
剛剛確認過了,應該是卡到底下硬碟讀寫的頻寬,我記得那幾臺設備的 SSD 寫入速度最高可以到 500 MB/s 附近,但查核點的測試環境下,backbone topic 自己就會佔據掉 500 MB/s 的讀寫,其中一個 SSD 還要承受同個 broker 中另外 500 個小 partition 的流量,這樣前後加總起來,目前的設備應該是很難在沒有人為介入的情況下重現查核點的情境。 目前可能的做法有
@chia7712 你覺得這些解決方案如何,我覺得第一個應該是最簡單的做法,但我不知道文件出去了沒還能不能改。 |
文件還沒出去,你們的報告改到二月底了(等其他人) 不過可以先提一下你打算改成哪樣的數字 |
變更有3項:
比較有爭議的改變是第二項,第二項是說肯定會有負載不平衡的情況發生,這個是透過在 Scenario 內刻意調整 Partition 在某些節點的流量來達成的,之所以要這樣做是因為 Kafka 的設計不一定會負載不平衡,這邊透過腳本刻意的方式,確保負載不平衡的情境會發生。這種流量分佈在生產環境是真的有可能會發生,只是發生的可能性是一個機率,然後這邊就是假設這個運氣不好的機率真的成真。在這個假設下去做負載平衡。 第三項是因為 Performance Tool 對無 consumer 的情境支援有些困難,所以這邊直接改成 topic 一定會有 consumer。 目前測試
|
嘗試使用 Zipfian 來製造負載不平衡的情境 目前發現到的問題有
關於第一點的部分 我嘗試把其他 Perf 關掉,然後 Zipfian 那臺的流量有變穩定的趨勢,我覺得是遇到 SSD 讀寫上的瓶頸,有些時候 SSD 讀寫到達 500 MB/s 附近。 如果用 Zipfian 做實驗的時候可能意外會比較多(太多變數),我在想能不能在實驗之前先用 Zipfian 分佈生成流量,確定流量不會造成實驗環境的瓶頸之後,把對應的值用 throttle 去限制(類似上面 #1476 (comment) 提出的做法,只是換個故事說這件事情) |
另外一個做法是把整體流量壓下去,不要打到現在 500 MB 到 700 MB 那麼高,可能把流量控制在比如 200 MB 到 500 MB 之間,這樣實驗的執行會能夠比較穩定 |
撞到硬體的上限並不是什麼意外(這很正常),反之,這更是一個好的情境,可以說在這種狀況下有大量資源浪費(撞到上限可能導致 retry or 其他 overhead),而透過你設計的 balancer 可以有效平衡負載讓各個資料流避免撞到硬體上限
同上 |
不過這樣負載平衡演算法會很難做,我們是基於過去的效能指標來判斷 Partition 背後的負載量,可能因為撞到硬體上限而難以估計一個 Partition 背後真正的負載量是多少(比如他的值一直彈跳,誤會真正的負載值,或是以為 Partition A 的負載量是 100 MB/s,但搬移完成後硬體上限問題不存在,Partition A 的負載量長到原本應該輸入的 150 MB/s,造成最後的結果依然負載不平衡) |
這就是真實有意義且有挑戰感的題目了不是嗎 :) 我們的 cost function 的目標就是要能克服這些真實且會發生的狀況,像你現在說到的這個現象,你能否找到一個數學的方式來減輕“誤判”,這樣就會是既有理論又有實際意義的題目 但如果是為了查核項目方便,我會建議可以考慮用壓縮來減緩 I/O |
從上次討論的結果來看,情境已經有些變化,我們回原本的議題討論,也麻煩你試著修改 #1424 的描述,把情境的部分也重寫一次。 |
已修改,這隻 PR 的情境生成程式碼我需要再做一下修正,後面測試穩定後大致上就完成了 |
上面這些工作量都和 Partition 數量有關。用 #1502 的程式碼對不同 Partition 數量的叢集做優化,可以看出這個 Partition 數量和執行時間之間的趨勢。他們有著非常高的正相關。
所以花太多時間的關鍵點應該是 Partition 數量太多沒辦法在現行的實作 & 30 秒內得到好的計劃。 |
#1508 的修正似乎讓速度變更慢
套用 |
@garyparrot 這回到我們上次討論的,量和值有時候就是trade off,看你想要往哪邊用力 |
效能問題解得差不多後嘗試進行實驗,目前發現的幾個問題 Zipfian 的 Consumer 吞吐量追不上Zipfian 分佈下的 Producer/Consumer 有非常顯著的 "Produce 寫入流量 > Consume 讀取流量" 的問題,這個現象導致目前查核點的情境沒辦法被準確呈現。 上圖所有 parititon 的 consumer fanout 都是 1,理論上節點的輸入和輸出流量要長得一致,但負責 zipfian 最熱門的那個 partition 的 broker 的 egress 流量特別低 (右邊紅色)。去 performance tool 輸出也能看到 consumer 的總消費吞吐量輸 produce 約 100 MB/s 附近。 透過連線進去看 Consumer 的 Lag 資訊,可以看到有些比較熱門的 Partition 有非常顯著的 lag: 上圖的 Consumer Partition 大約堆積了 76 GB 的資料還沒消費(10KB per record) Zipfian 的 Performance Tool 在負載優化後速度降低這個應該也是 consumer lag 造成的,目前還不確定 Consumer 吞吐的下降原因。 NetworkCost 流量預估不準確
ClusterCost 裡面某些節點的流量值和監控上看到的情況不一致,裡面的計算可能有些誤差存在 (約 50MB/s) |
回頭看了一下這隻PR,幾個疑問:
請問這邊的套用是指什麼?
這些功能除了查核驗收以外, production 上有機會使用嗎? |
把 #1424 的情境建立在叢集上,比如那 10000 個 Partition
我想沒有辦法在 production 上用,這些 scenario 都是實驗用途。 這 PR 主要是實驗的程式碼和工具要推上來方便重現。另外除了這個 PR 的建立情境之外,還有一段是把情境的 Performance Tool 開起來,因為那個部分會牽涉很多東西,所以沒有打算推上,我想這部分可以靠其他人閱讀 scenario output 來手動建起來。 如果說這些功能要避免出現在 production 的話,那 |
我們還是稍微區分一下 production code 和 驗收的項目。 驗收的項目可以先用獨立的專案放著,然後其中涉及到production 變更 或是 需求的部分再推到官方專案上 |
ok 那這個 PR 的內容就不考慮合併了 |
這個 PR 實作一個
Scenario
他可以建立 #1424 的情境。Scenario
現在會回傳一個物件,內容包含他的生成情境的一些描述和統計資訊。這個 PR 完成後,會再另外開一個 PR,給 WebService 新增一個ScenarioHandler
,他可以透過 Web API 的形式來對叢集套用特定的情境。然後將Scenario
回傳的資訊以 JSON 回覆給使用者。回覆的資訊包含:
詳細回傳如下:
CLICK ME