Délai d'écriture lancé par le pilote cassandra datastax

En effectuant une charge en vrac de données, en incrémentant les compteurs en fonction des données du journal, je rencontre une exception de délai d'attente. Im en utilisant le pilote Java Datastax 2.0-rc2.

Est-ce un problème avec le serveur ne pouvant pas suivre (c'est-à-dire un problème de configuration côté serveur), ou est-ce un problème avec le client qui s'ennuie en attendant que le serveur réponde? De toute façon, y a-t-il un changement de configuration facile que je peux faire pour résoudre ce problème?

Exception in thread "main" com.datastax.driver.core.exceptions.WriteTimeoutException: Cassandra timeout during write query at consistency ONE (1 replica were required but only 0 acknowledged the write)
    at com.datastax.driver.core.exceptions.WriteTimeoutException.copy(WriteTimeoutException.java:54)
    at com.datastax.driver.core.ResultSetFuture.extractCauseFromExecutionException(ResultSetFuture.java:271)
    at com.datastax.driver.core.ResultSetFuture.getUninterruptibly(ResultSetFuture.java:187)
    at com.datastax.driver.core.Session.execute(Session.java:126)
    at jason.Stats.analyseLogMessages(Stats.java:91)
    at jason.Stats.main(Stats.java:48)
Caused by: com.datastax.driver.core.exceptions.WriteTimeoutException: Cassandra timeout during write query at consistency ONE (1 replica were required but only 0 acknowledged the write)
    at com.datastax.driver.core.exceptions.WriteTimeoutException.copy(WriteTimeoutException.java:54)
    at com.datastax.driver.core.Responses$Error.asException(Responses.java:92)
    at com.datastax.driver.core.ResultSetFuture$ResponseCallback.onSet(ResultSetFuture.java:122)
    at com.datastax.driver.core.RequestHandler.setFinalResult(RequestHandler.java:224)
    at com.datastax.driver.core.RequestHandler.onSet(RequestHandler.java:373)
    at com.datastax.driver.core.Connection$Dispatcher.messageReceived(Connection.java:510)
    at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
    at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
    at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
    at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)
    at org.jboss.netty.handler.codec.oneone.OneToOneDecoder.handleUpstream(OneToOneDecoder.java:70)
    at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
    at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
    at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)
    at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462)
    at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443)
    at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303)
    at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
    at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
    at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
    at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
    at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
    at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88)
    at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109)
    at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312)
    at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90)
    at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
    at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
    at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:744)
Caused by: com.datastax.driver.core.exceptions.WriteTimeoutException: Cassandra timeout during write query at consistency ONE (1 replica were required but only 0 acknowledged the write)
    at com.datastax.driver.core.Responses$Error$1.decode(Responses.java:53)
    at com.datastax.driver.core.Responses$Error$1.decode(Responses.java:33)
    at com.datastax.driver.core.Message$ProtocolDecoder.decode(Message.java:165)
    at org.jboss.netty.handler.codec.oneone.OneToOneDecoder.handleUpstream(OneToOneDecoder.java:66)
    ... 21 more

L'un des nœuds signale cela à peu près au moment où il s'est produite:

ERROR [Native-Transport-Requests:12539] 2014-02-16 23:37:22,191 ErrorMessage.java (line 222) Unexpected exception during request
java.io.IOException: Connection reset by peer
    at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
    at sun.nio.ch.SocketDispatcher.read(Unknown Source)
    at sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source)
    at sun.nio.ch.IOUtil.read(Unknown Source)
    at sun.nio.ch.SocketChannelImpl.read(Unknown Source)
    at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:64)
    at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109)
    at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312)
    at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90)
    at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
29
demandé sur Jacob 2014-02-17 04:58:30

4 réponses

Bien que je ne comprenne pas la cause profonde de ce problème, j'ai pu résoudre le problème en augmentant la valeur du délai d'attente dans conf/cassandra.fichier yaml.

write_request_timeout_in_ms: 20000
28
répondu Jacob 2014-02-17 22:52:58

Nous avons rencontré des problèmes similaires sur un seul nœud dans un cluster ESX avec un stockage SAN attaché (ce qui est non recommandé par datastax , mais nous n'avons pas d'autres options pour le moment).

Note: les paramètres ci-dessous peuvent être un grand coup à la performance maximale Cassandra peut atteindre, mais nous avons choisi un système stable sur la haute performance.

Lors de l'exécution de iostat -xmt 1, nous avons trouvé des temps w_await élevés en même temps que les WriteTimeoutExceptions se sont produites. Il se tourna out le memtable n'a pas pu être écrit sur le disque dans le paramètre par défaut write_request_timeout_in_ms: 2000.

Nous avons considérablement réduit la taille de memtable de 512 Mo (par défaut à 25% de l'espace de tas, qui était de 2 Go dans notre cas) à 32 Mo: 

# Total permitted memory to use for memtables. Cassandra will stop
# accepting writes when the limit is exceeded until a flush completes,
# and will trigger a flush based on memtable_cleanup_threshold
# If omitted, Cassandra will set both to 1/4 the size of the heap.
# memtable_heap_space_in_mb: 2048
memtable_offheap_space_in_mb: 32

Nous avons également légèrement incrémenté le délai d'écriture à 3 secondes: 

write_request_timeout_in_ms: 3000

Assurez-vous également d'écrire régulièrement sur le disque si vous avez des temps d'attente d'E / S élevés: 

#commitlog_sync: batch
#commitlog_sync_batch_window_in_ms: 2
#
# the other option is "periodic" where writes may be acked immediately
# and the CommitLog is simply synced every commitlog_sync_period_in_ms
# milliseconds.
commitlog_sync: periodic
commitlog_sync_period_in_ms: 10000

Ces paramètres ont permis au memtable de rester petit et d'être écrit souvent. Les exceptions étaient les suivantes résolu et nous avons survécu aux tests de résistance qui ont été exécutés sur le système.

16
répondu dvtoever 2016-06-08 13:28:05

C'est le coordinateur (donc le serveur) qui temporise en attendant les accusés de réception pour l'écriture.

0
répondu Christopher Batey 2014-02-17 23:07:53

Cela vaut la peine de vérifier vos paramètres GC pour Cassandra.

Dans mon cas, j'utilisais un sémaphore pour accélérer les écritures asynchrones et encore (parfois) obtenir des délais d'attente.

Il s'est avéré que j'utilisais des paramètres GC inappropriés, j'utilisais cassandra-unit pour plus de commodité, ce qui avait pour conséquence involontaire de fonctionner avec les paramètres VM par défaut. Par conséquent, nous finirions par déclencher un GC stop-the-world entraînant un délai d'écriture. Appliquer les mêmes paramètres GC que mon exécution cassandra Docker image et tout va bien.

Cela pourrait être une cause rare, mais cela m'aurait aidé, donc cela semble valoir la peine d'enregistrer ici.

-1
répondu Mumrah 2016-11-08 16:22:00