3

我正在使用带有 Datastax Cassandra 驱动程序的 Phantom-DSL 获得 Cassandra 超时。但是，Cassandra 似乎并没有超载。下面是我得到的例外：

com.datastax.driver.core.exceptions.OperationTimedOutException: [node-0.cassandra.dev/10.0.1.137:9042] Timed out waiting for server response
    at com.datastax.driver.core.RequestHandler$SpeculativeExecution.onTimeout(RequestHandler.java:766)
    at com.datastax.driver.core.Connection$ResponseHandler$1.run(Connection.java:1267)
    at io.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:588)
    at io.netty.util.HashedWheelTimer$HashedWheelBucket.expireTimeouts(HashedWheelTimer.java:662)
    at io.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:385)
    at java.lang.Thread.run(Thread.java:745)

以下是我在这段时间内从 Cassandra Datadog 连接器获得的统计数据：

卡桑德拉统计

您可以在顶部中心图上看到我们的读取率（每秒）。我们的 CPU 和内存使用率非常低。

以下是我们配置 Datastax 驱动程序的方式：

val points = ContactPoints(config.cassandraHosts)
  .withClusterBuilder(_.withSocketOptions(
    new SocketOptions()
      .setReadTimeoutMillis(config.cassandraNodeTimeout)
  ))
  .withClusterBuilder(_.withPoolingOptions(
    new PoolingOptions()
      .setConnectionsPerHost(
        HostDistance.LOCAL,
        2,
        2
      )
      .setConnectionsPerHost(
        HostDistance.REMOTE,
        2,
        2
      )
      .setMaxRequestsPerConnection(
        HostDistance.LOCAL,
        2048
      )
      .setMaxRequestsPerConnection(
        HostDistance.REMOTE,
        2048
      )
      .setPoolTimeoutMillis(10000)
      .setNewConnectionThreshold(
        HostDistance.LOCAL,
        1500
      )
      .setNewConnectionThreshold(
        HostDistance.REMOTE,
        1500
      )

))

我们的nodetool cfstats样子是这样的：

$ nodetool cfstats alexandria_dev.match_sums
Keyspace : alexandria_dev
        Read Count: 101892
        Read Latency: 0.007479115141522397 ms.
        Write Count: 18721
        Write Latency: 0.012341060840767052 ms.
        Pending Flushes: 0
                Table: match_sums
                SSTable count: 0
                Space used (live): 0
                Space used (total): 0
                Space used by snapshots (total): 0
                Off heap memory used (total): 0
                SSTable Compression Ratio: 0.0
                Number of keys (estimate): 15328
                Memtable cell count: 15332
                Memtable data size: 21477107
                Memtable off heap memory used: 0
                Memtable switch count: 0
                Local read count: 17959
                Local read latency: 0.015 ms
                Local write count: 15332
                Local write latency: 0.013 ms
                Pending flushes: 0
                Percent repaired: 100.0
                Bloom filter false positives: 0
                Bloom filter false ratio: 0.00000
                Bloom filter space used: 0
                Bloom filter off heap memory used: 0
                Index summary off heap memory used: 0
                Compression metadata off heap memory used: 0
                Compacted partition minimum bytes: 0
                Compacted partition maximum bytes: 0
                Compacted partition mean bytes: 0
                Average live cells per slice (last five minutes): 1.0
                Maximum live cells per slice (last five minutes): 1
                Average tombstones per slice (last five minutes): 1.0
                Maximum tombstones per slice (last five minutes): 1
                Dropped Mutations: 0

当我们运行时cassandra-stress，我们没有遇到任何问题：正如预期的那样，我们每秒获得稳定的 50k 读取。

每当我进行查询时，Cassandra 都会出现此错误：

INFO  [Native-Transport-Requests-2] 2017-03-10 23:59:38,003 Message.java:611 - Unexpected exception during request; channel = [id: 0x65d7a0cd, L:/10.0.1.98:9042 ! R:/10.0.1.126:35536]
io.netty.channel.unix.Errors$NativeIoException: syscall:read(...)() failed: Connection reset by peer
        at io.netty.channel.unix.FileDescriptor.readAddress(...)(Unknown Source) ~[netty-all-4.0.39.Final.jar:4.0.39.Final]

为什么我们会超时？

编辑：我上传了错误的仪表板。请看新图。

4

2 回答 2

0

2个有用的问题：

  1. 你设置的超时时间是多少
  2. 问什么？

现在澄清一下我认为你在这里出错的地方：

  1. 分辨率太粗糙，无法诊断单个查询，我可以让服务器什么都不做，做一个昂贵的查询，该查询在整个时间内都存在一些瓶颈，并且在那个规模上看起来没有任何瓶颈，在服务器上运行 iostat -x 1同时，您可能会发现与该分辨率下图表所显示的完全不同的东西。
  2. 如果我正确地查看了您的 CPU 使用率图表，它看起来像是 50% 的使用率。在由于超线程以及总体 CPU 使用率如何工作而实际上非常繁忙的现代服务器上，请参阅https://www.percona.com/blog/2015/01/15/hyper-threading-double-cpu-throughput/
于 2017-03-10T11:15:07.150 回答
0

我建议跟踪有问题的查询以查看 cassandra 在做什么。

https://docs.datastax.com/en/cql/3.1/cql/cql_reference/tracing_r.html

打开 cql shell，键入TRACING ON并执行您的查询。如果一切看起来都很好，那么这个问题可能偶尔会发生，在这种情况下，我建议使用 nodetool settraceprobablilty 跟踪查询一段时间，直到你设法发现问题为止。

nodetool settraceprobability <param>您可以使用其中参数是查询将被跟踪的概率（介于 0 和 1 之间）分别在每个节点上启用它。小心：这将导致负载增加，所以从一个非常低的数字开始并上升。

如果这个问题是偶发的，则有可能是由于长时间的垃圾收集造成的，在这种情况下，您需要分析 GC 日志。检查您的 GC 有多长时间。

编辑：为了清楚起见，如果此问题是由 GC 引起的，您将不会在跟踪中看到它。因此，首先检查您的 GC，如果不是问题，则继续进行跟踪。

于 2017-03-10T12:48:54.633 回答