Scylladb: Scylla写入延迟随着连续批处理写入摄取时间的推移而增加

Question

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

用于scylla集群的配置

写入者过程的细节，基本上它是一个kafka消费者。消费者的流程是

1-阅读来自kafka的500条消息

2- 500个工作者(Goroutine)开始批量写入scylla(cassandra) (单个批量包含与单个分区相关的数据)。每批包含平均3k条记录(最大=>为20k)。(密钥空间的复制因子为1)

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

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

5-返回步骤1

所以，基本上在测试中我使用了3个消费者。scylla无法应付kafka的注入速率，而cassandra的注入速率与之匹配。

分享了负载测试的grafana dashborad，如果还需要什么，请让我知道。

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

Answer 1

您报告了“写入响应延迟随着时间的推移而增加”，但没有解释您是如何测量这一点的，或者它增加了多少。延迟是从1ms增加到2ms，还是从1ms增加到500ms？是否意味着延迟增加，或者tail延迟(例如，99%)增加？

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

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

当然，Scylla在这方面总是有可能有bug，所以如果你怀疑它，请在Scylla邮件列表或bug跟踪器上报告你的问题，并提供更多细节。

Answer 2

资料太少了，最好还是在邮件列表上讨论一下吧。最好的方法是使用Grafana监视器，并观察是否达到了限制。压缩是并行运行的，但scylla调度程序为其提供了较低的优先级。

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