Question

我有一个用例，其中我正在使用gocql驱动程序将批数据连续不断地提取到Scylla中。在繁重的写测试中，我观察到scyllas写响应延迟随时间增加，有时会导致scylla节点重新启动。 Cassandra延迟的情况在一段时间内是恒定的。我只想知道此用例的正确配置，以便在整个时间内都能获得恒定的延迟。

用于scylla群集的配置

编写程序的详细信息基本上，它是一个kafka使用者。消费者的流向是

1-从kafka读取500条消息

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

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

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

5-返回步骤1

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

共享了负载测试的grafana dashborad，如果需要其他条件，请告诉我。

[！[注入量与消耗率] [1]] [1]

[！[scylla内存信息中心] [2]] [2]

[！[scyllaIOqueue] [3]] [3]

[！[ScyllaIo] [4]] [4]

[！[scyllaDiskDetails] [5]] [5]

[！[延迟] [6]] [6]

[！[load] [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

Answer 1

您报告说“写响应延迟随时间增加”，但没有说明您如何测量它，或它增加了多少。延迟会从1ms增加到2ms，还是从1ms增加到500ms？平均延迟是否增加，或者 tail 延迟（例如，第99个百分位数）增加？

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

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

Scylla当然总是有可能在此区域出现错误，因此，如果您怀疑它存在，请在Scylla邮件列表或错误跟踪器上报告您的问题-详细信息。

Answer 2

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

可能是您在Scylla之外的计算机上运行了其他东西吗？

Scylladb：Scylla写延迟随着连续批量写摄入而增加

2 个答案: