我有一个树节点cassandra集群。
当我从java客户端请求大量数据时,服务器端会出现以下警告:
WARN SELECT * FROM [...] time 789 msec - slow timeout 500 msec/cross-node
WARN SELECT * FROM [...] time 947 msec - slow timeout 500 msec/cross-node
WARN SELECT * FROM [...] time 1027 msec - slow timeout 500 msec/cross-node
WARN SELECT * FROM [...] time 819 msec - slow timeout 500 msec/cross-node
客户端,我以以下异常结束:
java.util.concurrent.executionexception异常:
com.datastax.driver.core.exceptions.transportexception:
[/x.y.z.a:9042]连接已关闭
我的服务器配置yaml如下:
# How long the coordinator should wait for read operations to complete
read_request_timeout_in_ms: 5000
# How long the coordinator should wait for seq or index scans to complete
range_request_timeout_in_ms: 10000
# How long the coordinator should wait for writes to complete
write_request_timeout_in_ms: 2000
# How long the coordinator should wait for counter writes to complete
counter_write_request_timeout_in_ms: 5000
# How long a coordinator should continue to retry a CAS operation
# that contends with other proposals for the same row
cas_contention_timeout_in_ms: 1000
# How long the coordinator should wait for truncates to complete
# (This can be much longer, because unless auto_snapshot is disabled
# we need to flush first so we can snapshot before removing the data.)
truncate_request_timeout_in_ms: 60000
# The default timeout for other, miscellaneous operations
request_timeout_in_ms: 10000
我找不到任何“500毫秒”超时的参考。那我怎么调整这个超时?在查询大量分区/数据时,是否有避免以异常结束的选项?
作为补充说明,我使用future以异步方式检索数据:
import com.datastax.driver.core.ResultSetFuture;
1条答案
按热度按时间im9ewurl1#
默认值
slow_query_log_timeout_in_ms
是500,不是实际超时,只是通知/日志记录。你可以在你的yaml更新,如果你想它更高。不过,500ms的速度很慢,可能是环境或查询出错的一个指标。虽然这种情况很少见,但可能只是周期性的gcs,可以通过客户端推测性重试来缓解。