Storm latency verursacht durch ack

Question

Ich benutzte kafka-storm, um kafka und storm zu verbinden. Ich habe 3 Server mit Tierpfleger, Kafka und Sturm. Es gibt ein Thema "Test" in Kafka, das 9 Partitionen hat.

In der Sturmtopologie ist die Anzahl der KafkaSpout-Executoren 9 und die Anzahl der Aufgaben sollte standardmäßig ebenfalls 9 sein. Und der "Auszug" -Bolzen ist der einzige Bolzen, der mit KafkaSpout, dem "Log" -Auslauf, verbunden ist.

Von der Benutzeroberfläche gibt es eine große Rate von Fehlern in der Tülle. Allerdings ist die Anzahl der ausgeführten Nachricht in bolt = die Anzahl der ausgegebenen Nachricht - die Anzahl der fehlgeschlagenen Nachricht in bolt. Diese Gleichung ist nahezu identisch, wenn die fehlgeschlagene Nachricht zu Beginn leer ist.

Nach meinem Verständnis bedeutet dies, dass der Bolzen die Nachricht von der Tülle erhalten hat, aber die Ack-Signale im Flug ausgesetzt sind. Das ist der Grund, warum die Anzahl der Aids im Auslauf so gering ist.

Dieses Problem kann möglicherweise gelöst werden, indem Sie die Anzahl der Zeitüberschreitungen und die Anzahl der ausstehenden Nachrichten erhöhen. Aber dies wird mehr Speicherverbrauch verursachen und ich kann es nicht auf unendlich erhöhen.

Ich war herumwandern, wenn es eine Möglichkeit gibt, Sturm zu zwingen, die Ack in irgendeiner Tülle/Bolzen zu ignorieren, so dass es auf dieses Signal bis zum Zeitlimit nicht warten wird. Dies sollte die Durchlaufzeit deutlich erhöhen, aber keine Garantie für die Nachrichtenverarbeitung darstellen.

Answer 1

Wenn Sie die Anzahl der Ackers auf 0 setzen, quittiert storm automatisch jede Probe.

config.setNumAckers(0); 

Bitte beachten Sie, dass die UI nur 5% des Datenflusses misst und anzeigt. es sei denn, Sie

config.setStatsSampleRate(1.0d); 

versuchen setzen Sie die Schraube des Timeout zu erhöhen und die Menge an topology.max.spout.pending reduzieren.

Stellen Sie außerdem sicher, dass die Methode nextTuple() des Auslaufs nicht blockiert und optimiert ist.

Ich würde auch empfehlen, den Code zu profilieren, vielleicht werden Ihre Storm Queues gefüllt und Sie müssen ihre Größe erhöhen.

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); 

Answer 2

Ihre Kapazität Zahlen sind etwas hoch, führt mich zu glauben, dass Sie wirklich die Verwendung von Systemressourcen zu maximieren (CPU, Speicher). Mit anderen Worten, das System scheint ein wenig unterzugehen, und das ist wahrscheinlich der Grund, warum Tupel auslaufen. Sie können versuchen, die Konfigurationseigenschaft topology.max.spout.pending zu verwenden, um die Anzahl der Inflight-Tupel am Auslauf zu begrenzen. Wenn Sie die Anzahl nur so weit reduzieren können, sollte die Topologie in der Lage sein, die Last effizient zu verarbeiten, ohne dass Tupel auslaufen.