大量讀取期間 kafka 磁盤 hault 寫入並導致 kafka 生產者中的“隊列已滿”錯誤

Question

我們有 6 個具有 256GB RAM、24c/48T 的 kafka 代理，它們托管在 raid10 中配置的 20 個 1.8TB SAS 10K rpm 磁盤。

有兩個火花流應用程序

• 每 10 分鍾開始他們的批次
• 一旦他們開始，他們的第一份工作就是閱讀同一個 kafka 主題。
• 該主題有 200 個分區，均勻分布在 6 個代理上（每個代理上有 33 個分區）。
• 流媒體應用程序使用 kafka 客戶端 0.8.2.1 從 kafka 消費

有 21 個注入器實例以 6K 事件/秒的速率連續寫入該主題。 他們使用 librdkafka poroducer 來向 kafka 生成事件。

當流媒體應用程序醒來時，他們的第一份工作是閱讀主題。 一旦這樣做，kafka 磁盤中的 %util 將在 30 秒到 60 秒內變為 90-100%，同時所有注入器實例都從它們的 kafka 生產者那里得到“隊列已滿”錯誤。 這是生產者配置：

• queue.buffering.max.kbytes：2097151
• 逗留時間：0.5

從該圖中看不到，但是在 util% 高的時候，有一段時間寫入為 0，我們假設在這些時間注入器的生產者的隊列已滿，因此拋出“隊列已滿”錯誤。

值得一提的是，我們在kafka機器中使用deadline IO調度器，它優先考慮讀取操作。

關於如何釋放寫的壓力，我們有幾個想法：

• 減少不必要的 iops - 將 kafka 磁盤配置從 raid10 更改為非raid（“jbod”）
• 傳播閱讀 - 使 Spark 應用程序在不同時間從 kafka 讀取，而不是在同一時間醒來
• 更改寫入和讀取的優先級 - 將 IO 調度程序更改為 CFQ

我寫這個問題是為了驗證我們是否在正確的軌道上，並且由於 raid10、截止時間 IO 調度程序和同時讀取過多，操作系統 hault 在讀取期間確實寫入。

你怎么看？

Answer 1

當你問這是否朝着正確的方向發展時：

我認為你提到的步驟是有道理的。

一般來說，我總是建議不要讓任何東西占用 100% 的磁盤容量，如果它必須與其他假設它們有一些 IO 可用的東西共享這些磁盤。