由ack造成的風暴等待時間

我正在使用卡夫卡風暴來連接卡夫卡和風暴。我有3臺運行zookeeper，kafka和storm的服務器。在kafka中有一個有9個分區的「測試」主題。由ack造成的風暴等待時間

在風暴拓撲中，KafkaSpout執行器的數量是9，默認情況下，任務數量也應該是9。 '提取'螺栓是唯一連接到KafkaSpout（「原木」噴口）的螺栓。

從用戶界面來看，噴嘴出現了很大的故障率。但是，他在bolt中執行的消息數=發出的消息數 - 螺栓中失敗的消息數。當失敗的消息在開始時爲空時，該等式幾乎匹配。

根據我的理解，這意味着該螺栓確實從噴口接收到消息，但確認信號在飛行中暫停。這就是爲什麼噴口數量如此之少的原因。

可以通過增加超時秒數和噴出待處理消息號來解決此問題。但是這會導致更多的內存使用，我無法將其增加到無限。

我在徘徊，如果有強迫風暴的方法，忽略某些噴口/螺栓的響應，以便它不會等到這個信號出現。這應該會顯着增加消息處理，但不能保證消息處理。

來源

2016-03-24 Weizhou He

如果您將ackers的數量設置爲0，那麼storm會自動確認每個樣本。

config.setNumAckers(0);

請注意，UI只能測量並顯示5％的數據流量。除非你設置

config.setStatsSampleRate(1.0d);

嘗試增加螺栓的超時時間，並減少topology.max.spout.pending量。

另外，確保噴口的nextTuple（）方法是非阻塞和優化的。

我也建議分析代碼，也許你的風暴隊列正在填充，你需要增加它們的大小。

config.put(Config.TOPOLOGY_TRANSFER_BUFFER_SIZE,32); 
    config.put(Config.TOPOLOGY_EXECUTOR_RECEIVE_BUFFER_SIZE,16384); 
    config.put(Config.TOPOLOGY_EXECUTOR_SEND_BUFFER_SIZE,16384);

來源

2016-03-24 15:38:47 LiozM

謝謝您的建議。我通過將'topology.max.spout.pending'限制爲2000來解決這個問題。 –

你的能力的數字是有點高，導致我相信，你真的最大限度地利用系統資源（CPU，內存）。換句話說，該系統似乎陷入了一點點，這可能是爲什麼元組超時。您可以嘗試使用topology.max.spout.pending配置屬性來限制噴口中的飛行元組的數量。如果你可以減少這個數量，那麼拓撲結構應該能夠有效地處理負載，而不需要元組超時。

來源

2016-03-24 11:19:33

由ack造成的風暴等待時間

回答

相關問題