Scylladb：Scylla 写入延迟随着时间的推移而增加，以进行连续批量写入摄取答案

【问题标题】：Scylladb: Scylla write latency increasing over the time for continuous batch write ingestionScylladb：Scylla 写入延迟随着时间的推移而增加，以进行连续批量写入摄取
【发布时间】：2020-05-14 23:56:56
【问题描述】：

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

用于 scylla 集群的配置

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

1- 从 kafka 读取 500 条消息

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

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

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

5 - 返回第 1 步

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

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

[![注入与排出率][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]: https://i.stack.imgur.com/o0yQc.png
  [2]: https://i.stack.imgur.com/i0RhS.png
  [3]: https://i.stack.imgur.com/sA4WY.png
  [4]: https://i.stack.imgur.com/5QAob.png
  [5]: https://i.stack.imgur.com/6U5UM.png
  [6]: https://i.stack.imgur.com/DG2my.png
  [7]: https://i.stack.imgur.com/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

【问题讨论】：

标签： scylla

【解决方案1】：

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

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

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

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

【讨论】：

感谢您的回复！我已经更新了有关编写器过程的更多详细信息的问题，并上传了 scylla 的 grafana 仪表板。

【解决方案2】：

数据太少，最好在邮件列表或slack上讨论。最好的办法是使用 Grafana 监视器并观察您是否达到了限制。压缩并行运行，但 scylla 调度程序赋予它较低的优先级。

会不会是你在机器上运行了除了 Scylla 之外的其他东西？

【讨论】：

是的，那台机器上运行着其他 java 服务。我们没有为 scylla 使用专用机器。将在 slack 上发布更多数据。
最好使用任务集将每个服务器限制为自己的 cpu 和内存。 Scylla 计划消耗整个机器并且没有不需要的邻居。 Scylla 期望使用整个 cpu 和磁盘，如果不能，我们会感到惊讶——我们有很多算法和调度程序来确保压缩不会超出磁盘容量。停止该 Java 服务，看看性能如何变得一致。
如果你坚持在同一台机器上运行其他服务，Scylla有一个共享模式你可以在yaml文件中配置但并不理想。
当然，会尝试在专用机器上运行 scylla
我已经更新了这个问题，提供了有关编写器过程的更多详细信息，并上传了 scylla 的 grafana 仪表板。