Scylladb : Scylla write latency increasing over the time for continuous batch write ingestion

Question

我有一个用例，我使用 gocql 驱动程序连续将数据批量摄取到 Scylla 中，在繁重的写入测试期间，我观察到 scyllas 写入响应延迟随着时间的推移而增加，有时它会导致 scylla 节点重新启动，如果是 cassandra延迟时间是恒定的。我只想知道这个用例的正确配置，这样我就可以在整个时间内实现恒定的延迟。

用于 scylla 集群的配置

writer process 的详细信息基本上它是一个 kafka 消费者。
消费者的流量是

1- 从 kafka 读取 500 条消息

2- 500 个 worker (goroutine)开始将它分批写入 scylla(cassandra)(单批包含与单个分区相关的数据)每批包含平均 3k 条记录(最大值 => 20k)。(键空间的复制因子为 1)

3-更新计数器表 scylla 中的批处理状态。

4-将这 500 条消息提交给 kafka

5 - 返回第 1 步

soo，基本上在测试中我使用了 3 个消费者。 scylla 无法应对 kafka 的注入(inject)速度，而 cassandra 与注入(inject)速度相匹配。

分享了 load test 的 grafana dashborad，如果还有什么需要请告诉我。

[![注入(inject)与排出率][1]][1]

[![Scylla 内存仪表板][2]][2]

[![scyllaIOqueue][3]][3]

[![ScyllaIo][4]][4]

[![scyllaDiskDetails][5]][5]

[![延迟][6]][6]

[![加载][7]][7]

smp 16
cpuset 0-15
memory 80G
iops 
cat /etc/scylla.d/io_properties.yaml 
[root@ip /]# cat /etc/scylla.d/io_properties.yaml 
disks:
  - mountpoint: /var/lib/scylla
    read_iops: 265
    read_bandwidth: 99796024
    write_iops: 1177
    write_bandwidth: 130168192


Is there any other config which I  missed by which I can achieve constant write latency.


  [1]: /image/o0yQc.png
  [2]: /image/i0RhS.png
  [3]: /image/sA4WY.png
  [4]: /image/5QAob.png
  [5]: /image/6U5UM.png
  [6]: /image/DG2my.png
  [7]: /image/TOtuQ.png

saw this logs in scylla container

WARN  2020-02-05 11:07:54,409 [shard 12] seastar_memory - oversized allocation: 1081344 bytes. This is non-fatal, but could lead to latency and/or fragmentation issues. Please report: at   0x2cf31dd
  0x2a1d0c4
  0x2a21e8b
  0x103d7d2
  0x103e298
  0x10070c0
  0x100cd14
  0x10289b8
  0x1028057
  0x1028f59
  0x2a003ac
  0x2a50491
  0x2a5069f
  0x2aba615
  0x2acedac
  0x2a330ed
  /opt/scylladb/libreloc/libpthread.so.0+0x85a1
  /opt/scylladb/libreloc/libc.so.6+0xfb302

Answer 1

您报告说“写入响应延迟会随着时间的推移而增加”，但没有解释您是如何衡量这一点的，或者它增加了多少。延迟是从 1 毫秒增加到 2 毫秒，还是从 1 毫秒增加到 500 毫秒？ 意思是 延迟增加，或 尾部 延迟(例如，第 99 个百分位)增加？

其他响应提出的一些想法将主要解释尾部延迟的增加。但是在您所描述的批处理工作负载中，您通常不关心尾部延迟，而只关心获得合理(甚至不低)的平均延迟(在批处理工作负载中，更重要的衡量标准是吞吐量)。但是，如果您看到平均延迟持续增长并变得不合理，通常发生的情况是您客户的 并发正在增加，或者换句话说，它开始了太多的新写入，而没有等待先前的请求完成(参见 Little's Law)。您没有说您是如何进行“批量写入”的。您是在使用具有固定线程数的客户端，还是您的写入并发性会不受控制地增长？

当您的客户端正确地具有固定的并发性时，Scylla 仍然必须小心不要让客户端相信以前的工作已经完成，而实际上仍然有很多后台工作 - 我在 a blog bost a year ago 中解释了这个问题以及 Scylla 如何解决它.

当然，Scylla 总是有可能在这方面存在错误，因此如果您怀疑它，请在 Scylla 邮件列表或错误跟踪器上报告您的问题 - 并提供更多详细信息。