web-dev-qa-db-ja.com

cassandra= datastaxドライバーによってスローされる書き込みタイムアウト

ログデータに基づいてカウンタをインクリメントしながらデータのバルクロードを実行しているときに、タイムアウト例外が発生します。 Datastax 2.0-rc2 Javaドライバーを使用しています。

これは、サーバーが維持できない問題（つまり、サーバー側の構成の問題）ですか、それとも、サーバーが応答するのを待っているクライアントが退屈する問題ですか？いずれにしても、これを修正する簡単な設定変更はありますか？

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

ノードの1つは、ほぼ発生時にこれを報告します。

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

この問題の根本的な原因はわかりませんが、conf/cassandra.yamlファイルのタイムアウト値を増やすことで問題を解決できました。

write_request_timeout_in_ms: 20000
34
Jacob

ESXクラスタの単一ノードでSANストレージが接続されている（これは datastaxでは推奨されません ですが、現時点では他のオプションはありません）で同様の問題が発生しました） 。

注：以下の設定は、最大パフォーマンスに大きな打撃を与える可能性がありますCassandra can達成しましたが、高性能よりも安定したシステムを選択しました。

iostat -xmt 1の実行中に、WriteTimeoutExceptionsが発生すると同時にw_a​​wait時間が長くなることがわかりました。デフォルトのwrite_request_timeout_in_ms: 2000設定内では、memtableをディスクに書き込めないことが判明しました。

Memtableのサイズを512Mb（デフォルトではヒープスペースの25％、この場合は2Gb）から32Mbに大幅に削減しました。

# 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

また、書き込みタイムアウトを3秒にわずかに作成しました。

write_request_timeout_in_ms: 3000

また、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

これらの設定により、memtableを小さく保ち、頻繁に書き込むことができました。例外は解決され、システムで実行されたストレステストを乗り切りました。

23
dvtoever

これはコーディネーター（サーバー）が書き込みの確認応答の待機をタイムアウトします。

0
Christopher Batey