Spring Kinesis Binder быстро заполняет пространство кучи, что приводит к частым сбросам сборщика мусора и замедляет процесс обработки сообщений.

Мое приложение использует один поток, а затем отправляет сообщения в три потока.

Связующее:

public interface MyBinder {

  @Input("input1")
  SubscribableChannel input1();

  @Output("output1")
  MessageChannel output1();

  @Output("output2")
  MessageChannel output2();

  @Output("output3")
  MessageChannel output3();


}

Конфигурация:

spring:
  cloud:
    stream:
      kinesis:
        binder:
          locks:
            leaseDuration: 30
            refreshPeriod: 3000
        bindings:
          input1:
            consumer:
              listenerMode: batch
              recordsLimit: 1500
              idleBetweenPolls: 10000
              consumer-backoff: 1000
      bindings:
        input1:
          group: my-group
          destination: input1-stream
          content-type: application/json
        output1:
          destination: output1-stream
          content-type: application/json
        output2:
          destination: output2-stream
          content-type: application/json
        output3:
          destination: output3-stream
          content-type: application/json

Данные, которые мы отправляем в поток в каждой записи, составляют около 800 КБ. Мы видим, что в AbstractAwsMessageHandler/AmazonKinesisAsyncClient больше данных, что приводит к очень частой очистке сборщика мусора.

Мы используем версию Binder 1.0.0.RELEASE.

Не могли бы вы помочь?


person Patan    schedule 17.04.2019    source источник


Ответы (1)


Только то, что я могу сказать по вашей конфигурации, что у вас будет 1500 * 3 PutRecordRequest экземпляров на вашем AbstractAwsMessageHandler, и, поскольку он находится в режиме async по умолчанию, вы можете привести к накладным расходам очереди, ожидающим, когда сервис AWS обработает их.

Вы можете уменьшить этот recordsLimit или настроить всех производителей в режиме sync: https://github.com/spring-cloud/spring-cloud-stream-binder-aws-kinesis/blob/master/spring-cloud-stream-binder-kinesis-docs/src/main/asciidoc/overview.adoc#kinesis-producer-properties

В случае меньшего количества записей для потребления у вас будет меньше объектов в памяти. В случае режима создания синхронизации вы собираетесь заблокировать потребительский поток, поэтому он не будет извлекать больше записей из входного потока.

person Artem Bilan    schedule 17.04.2019
comment
Спасибо за помощь. Я попробую варианты и вернусь - person Patan; 17.04.2019
comment
Есть ли способ ограничить количество PutRecordRequest через какую-то конфигурацию? - person Patan; 18.04.2019
comment
В любом случае он ограничен пропускной способностью на уровне клиента, но, поскольку он находится в асинхронном режиме, все записи просто ставятся в очередь в памяти. Лучший способ ограничить количество записей для опроса восходящего потока или выполнить перевод в режим синхронизации, чтобы заблокировать потребителя в том же потоке. - person Artem Bilan; 18.04.2019
comment
Можете ли вы взглянуть на это и предложить нам stackoverflow.com/questions/55877979/ - person Patan; 01.05.2019