Scylladb: задержка записи Scylla увеличивается с течением времени для непрерывного приема пакетной записи

Question

У меня есть случай использования, когда я непрерывно загружаю данные в Scylla с помощью драйвера gocql. Во время тяжелого теста записи я заметил, что задержка ответа записи scyllas увеличивается с течением времени, Иногда это приводит к перезапуску узла scylla, Где в Случай латентности кассандры постоянен во времени. Я просто хочу знать правильные конфиги для этого варианта использования, чтобы я мог добиться постоянной задержки во времени.

Конфиги, используемые для кластера scylla

Подробности процесса записи В основном это потребитель kafka , Поток потребителя составляет

1 - читает 500 сообщений от kafka

2-500 рабочих (goroutine) начинают записывать его в scylla (cassandra) партиями (одна партия содержит данные, относящиеся к одной раздел) каждая партия содержит в среднем 3 тыс. записей (максимум => 20 тыс.) (коэффициент репликации пространства ключей равен 1)

3 - обновляет состояние партии в таблице счетчиков scylla.

4 - принятие это 500 сообщений kafka

5 - назад к шагу 1

soo, в основном в тесте я использую 3 потребителя. Сцилла не в состоянии справиться со скоростью инъекции кафки, в то время как кассандра соответствует скорости инъекции.

Разделил графическую панель инструментов нагрузочного теста, пожалуйста, дайте мне знать, если требуется что-то еще.

[! [Скорость впрыска против расхода] [1]] [1]

[! [scylla memory dashboard] [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

Вы сообщили, что «задержка ответа при записи увеличивается с течением времени», но не объяснили, как вы измерили это или насколько оно увеличивается. Увеличивается ли задержка с 1 мс до 2 мс или с 1 мс до 500 мс? означает увеличение задержки или увеличение tail задержки (например, 99-го процентиля)?

Некоторые идеи, высказанные в других ответах, в основном объясняют увеличение задержки в хвосте. Но в пакетных рабочих нагрузках, которые вы описываете, вы обычно не заботитесь о хвостовой задержке, а просто получаете разумную (даже не низкую) среднюю задержку (в пакетных рабочих нагрузках более важной мерой является пропускная способность). Но если вы видите, что средняя задержка постоянно растет и становится необоснованной, то обычно происходит то, что параллелизм вашего клиента увеличивается или, другими словами, он запускает слишком много новых записей, не ожидая предыдущих запросов закончили (см. Закон Литтла ). Вы не сказали, как вы делали свои «записи партии». Используете ли вы клиент с фиксированным числом потоков, или ваш параллелизм записи может бесконтрольно расти?

Когда ваш клиент правильно установил параллелизм, Сцилла все равно должна быть осторожна, чтобы клиент не поверил, что предыдущая работа завершена в то время как на самом деле еще много фоновой работы - я объяснил эту проблему и то, как Сцилла решает ее в блоге, который год за годом go.

Конечно, всегда возможно, что у Scylla есть ошибка в этой области, поэтому, если вы подозреваете это, пожалуйста, сообщите о своей проблеме - с более подробной информацией - в списке рассылки Scylla или трекере ошибок.

Answer 2

Слишком мало данных, лучше всего обсудить их в списке рассылки или нет. Лучше всего использовать монитор Grafana и наблюдать, если вы достигнете предела. Уплотнение выполняется параллельно, но планировщик scylla придает ему более низкий приоритет.

Может быть, вы запускаете на машине что-то еще, кроме Сциллы?