web-dev-qa-db-fra.com

Délai d'expiration de l'écriture renvoyé par cassandra pilote de datastax

Tout en effectuant un chargement en masse de données, en incrémentant les compteurs en fonction des données de journal, je rencontre une exception de délai d'attente. J'utilise le Datastax 2.0-rc2 Java.

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? Quoi qu'il en soit, y a-t-il un changement de configuration facile que je puisse 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 le signale à peu près au moment où il s'est produit:

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)
javacassandradatastax
32
Jacob

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

write_request_timeout_in_ms: 20000
34
Jacob

Nous avons rencontré des problèmes similaires sur un nœud unique dans un cluster ESX avec SAN attaché (ce qui est non recommandé par la datastax , mais nous n'avons aucune autre option pour le moment)) .

Remarque: les paramètres ci-dessous peuvent être un coup dur pour les performances maximales Cassandra peut atteindre, mais nous avons choisi un système stable plutôt que de hautes performances.

En courant iostat -xmt 1 nous avons trouvé des temps d'attente élevés en même temps que les exceptions WriteTimeoutExceptions. Il s'est avéré que la table mém ne pouvait pas être écrite sur le disque dans la valeur par défaut write_request_timeout_in_ms: 2000 réglage.

Nous avons considérablement réduit la taille de la mémoire de 512 Mo (par défaut à 25% de l'espace de stockage, 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 augmenté 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 élevés IO:

#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 ont été résolues et nous avons survécu aux tests de résistance effectués sur le système.

23
dvtoever

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

0
Christopher Batey