Cassandra Cluster schlechte Leistung

Question

Ich habe ein Cassandra (2.2.1) Cluster von 4 Knoten, die von Java-Client-Anwendung verwendet wird. Der Replikationsfaktor ist 3, die Konsistenzstufe ist LOCAL_QUORUM für Lese- und Schreibvorgänge. Jeder Knoten hat ungefähr 5 GB Daten. Beträge von Anfragen sind ungefähr 2-4k pro Sekunde. Es gibt fast keine Löschoperationen, daher wird eine kleine Menge an Tombstones erstellt.

Ich habe vor einiger Zeit schlechte Lese- und Schreibleistungen bemerkt, und es wird immer schlimmer - der Cluster wird langsam. Lesen (meistens oft) und Schreib-Timeouts sind sehr oft geworden. Hardware sollte nicht das Problem verursachen, Server, auf denen Cluster bereitgestellt wird, sind wirklich gut in Bezug auf Festplattenleistung, CPU und RAM-Ressourcen.

Die Ursache des Problems ist mir unklar, aber ich habe mehrere Protokolleinträge bemerkt, die auf die Ursache hinweisen:

1. Ausnahme-Stack-Trace in Java-Client-Anwendungsprotokoll:

   com .datastax.driver.core.exceptions.ReadTimeoutException: Cassandra Timeout während der Leseabfrage an Konsistenz LOCAL_QUORUM (2 Antworten erforderlich waren, aber nur 1 Replik reagierte)

Es ist interessant, dass 1 Knoten immer noch antwortet.

2. Mehrere Einträge gescheiterter Hinweise Fehler:

   Fehlgeschlagen Hinweise auf /1.1.1.1 Wiedergabe; Abbrechen (135922 geliefert), Fehler: Zeitüberschreitung der Operation - nur 0 Antworten erhalten.

3. Mehrere folgenden Ausnahmen in cassandra Protokolle:

   Unerwartete Ausnahme während Anfrage; channel = [id: 0x10fc77df, /2.2.2.2:54459:> /1.1.1.1:9042] java.io.IOException: Fehler beim Lesen (...): Zeitüberschreitung der Verbindung bei io.netty.channel.epoll .Native.readAddress (systemeigene Methode) ~ [netty-all-4.0.23.Final.jar: 4.0.23.Final] bei io.netty.channel.epoll.EpollSocketChannel $ EpollSocketUnsafe.doReadBytes (EpollSocketChannel.java:675) ~ [netty-all-4.0.23.Final.jar: 4.0.23.Final] bei io.netty.channel.epoll.EpollSocketChannel $ EpollSocketUnsafe.epollInReady (EpollSocketChannel.java:714) ~ [netty-all-4.0. 23.Final.jar: 4.0.23.Final] bei io.netty.channel.epoll.EpollEventLoop.processReady (EpollEventLoop.java:326) ~ [netty-all-4.0.23.Final.jar: 4.0.23. Endgültig] bei io.netty.channel.epoll.EpollEventLoop.run (EpollEventLoop.java:264) ~ [netty-all-4.0.23.Final.jar: 4.0.23.Final] bei io.netty. util.concurrent.SingleThreadEventExecutor $ 2.run (SingleThreadEventExecutor.java:116) ~ [netty-all-4.0.23.Final.jar: 4.0.23.Final] bei io.netty.util.concurrent.DefaultThreadFactory $ DefaultRunnableDecorator.run (DefaultThreadFactory.java:137) ~ [netty-all-4.0.23.Final.jar: 4.0.23.Final] bei java.lang.Thread.run (Thread.java:745) [na: 1.8.0_66]

4. fehlgeschlagen Batch-Fehler:

   Batch von Prepared Statements für [< ...>] ist von Größe 3453794, festgelegten Schwellenwert von 1.024.000 von 2429794. überschreitet (siehe batch_size_fail_threshold_in_kb)

Sieht aus wie die Charge zu groß ist, wir haben übrigens viele Batch-Operationen. Vielleicht beeinflussen Chargen das System?

1. Schließlich Ausnahme, die meist häufig gesehen wird - diese Einträge nacheinander erscheinen nach Protokollebene auf DEBUG Schalt:

   TIOStreamTransport.java:112 - Fehler beim Schließen Ausgangsstrom . java.net.SocketException: Socket geschlossen bei java.net.SocketOutputStream.socketWrite (SocketOutputStream.java:116) ~ [na: 1.8.0_66] bei java.net.SocketOutputStream.write (SocketOutputStream.java:153) ~ [na: 1.8.0_66] bei java.io.BufferedOutputStream.flushBuffer (BufferedOutputStream.java:82) ~ [na: 1.8.0_66] bei java.io.BufferedOutputStream.flush (BufferedOutputStream.java:140) ~ [na : 1.8.0_66] bei java.io.FilterOutputStream.close (FilterOutputStream.java:158) ~ [na: 1.8.0_66] bei org.apache.thrift.transport.TIOStreamTransport.close (TIOStreamTransport.java:110) ~ [libthrift-0.9.2.jar: 0.9.2] bei org.apache.cassandra.thrift.TCustomSocket.close (TCustomSocket.java:197) [apache-cassandra-2.2.1.jar: 2.2.1] um org.apache.thrif t.transport.TFramedTransport.close (TFRamedTransport.java:89) [libthrift-0.9.2.jar: 0.9.2] bei org.apache.cassandra.thrift.CustomTThreadPoolServer $ WorkerProcess.run (CustomTThreadPoolServer.java:209) [ apache-cassandra-2.2.1.jar: 2.2.1] bei java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1142) [na: 1.8.0_66] bei java.util.concurrent.ThreadPoolExecutor $ Worker .run (ThreadPoolExecutor.java:617) [na: 1.8.0_66] bei java.lang.Thread.run (Thread.java:745) [na: 1.8.0_66]

haben Sie irgendwelche Ideen über was kann dieses Problem verursachen?

Vielen Dank!

Answer 1

Für den ersten Punkt, den ich habe eine Idee:

Wenn Sie eine Abfrage ausgeben, gibt es immer ein Thread ist, die sich darum kümmern sollte.

Wenn es zu viele gibt, gibt es eine Warteschlange, die sie organisieren sollte.

Es gibt auch eine Zeitüberschreitung für wie viel ein Thread in einer Warteschlange warten könnte.

So antworten Ihre Replikate nicht schnell genug, da einige der Threads, die eine bestimmte Abfrage bedienen, verworfen werden.

Betrachten Sie ein wenig mit der Anzahl der Schreiben/Lesen-Threads spielen. Wenn Ihr System gut genug ist, können Sie mehr Arbeitskräfte in diesem Bereich zuweisen.

ich mit cassandra Stress erinnere mich spielen eine Weile und die Rate threads = wo Standard war 32. Betrachten Erhöhung in cassandra.yaml die Anzahl der

• concurrent_reads von 32 bis zu 128
• concurrent_writes von 32 bis zu 128

Sie können auch in Betracht ziehen, die Zahlen zu verringern. Ich empfehle den Test zu testen und erneut zu testen.

Sie auch mit dem Timeouts (wie viel ein Thread kann in einer Warteschlange leben, um Antworten zu dienen)

• read_request_timeout_in_ms von 5000 bis zu etwas 10000
• write_request_timeout_in_ms von 2000 bis zu so etwas wie 5000 spielen können.

zu Punkt 2. ich das gleiche vermuten, Ihr Knoten versucht, die Hinweise so 2 Dinge zu antworten passiert:

1. erreicht nicht den Knoten (einige Netzwerkprobleme überprüfen)

2. vielleicht brauchen Sie mehr Arbeits Threads zuzuweisen, die max_hints_delivery_threads zu beeinflussen.

Punkt 3 sieht 1.

Viel Glück zum Punkt zusammen.

Answer 2

Es ist möglicherweise mit dem Threads begrenzten Speicher verbunden, die Hinweise nicht verarbeiten können. Es kann durch die Erhöhung -Xss gelöst werden. Weitere Informationen: https://issues.apache.org/jira/browse/CASSANDRA-4740