Разработчики провели нагрузочные тесты и выявили значительные задержки при записи данных в Kafka, что приводило к накоплению лага.

Я подключился к анализу причин низкой производительности.

Сильно упрощенный флоу:

  1. приложение пишет в Kafka (кластер на виртуальных машинах);
  2. Kafka работает в режиме acks=all и не поспевает за потоком событий;
  3. на приложении копится очередь на запись.

lag

Прежде чем детально разбираться с Kafka, я бегло проверил сетевые ресурсы и состояние машин. Аномалий выявлено не было.

Окей, пошли к брокеру.

Лаг при асихронных коммитах почти отсутствовал (см. acks=1 выше), поэтому мне в первую очередь было интересно, что ограничивает скорость фолловеров кластера.

Дашборд показывал накопление очередей к network threads - эти ребята отвечают за обработку входящих/исходящих запросов:

lag

В интернетах советовали увеличить количество тредов, но вопрос медленной записи оставался открытым.

Анализ состояния тредов (см. TSA) не подтвердил гипотезу ожидания — большую часть времени потоки проводили на CPU.

А вот флеймграф использования процессора (спасибо А. Пангин за async-profiler) дал зацепку - до 36% всего CPU уходило на операции с SSL шифрованием:

flamegraph

К оптимизации работы с SSL можно подходить с разных сторон:

  • аппаратная поддержка шифрования;
  • оптимизация цепочек сертификатов;
  • использование сессий и кеширования;
  • выбор алгоритмов и библиотек;
  • …

Но для начала я провел несколько тестов производительности алгоритма AES (он занимал до 32% времени CPU):

  1. гипервизор одной из kafka машин:
$ openssl speed -evp aes-256-gcm
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-256-gcm     386715.46k  1106963.22k  2161413.00k  3272084.76k  4036008.72k  4165596.14k
  1. рандомная виртуальная машина:
$ openssl speed -evp aes-256-gcm
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-256-gcm     386344.52k  1082957.51k  2009377.84k  3003345.30k  3602678.31k  3649463.55k
  1. одна из машин кластера Kafka:
openssl speed -evp aes-256-gcm
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-256-gcm     107798.70k   133547.52k   138563.93k   139041.45k   137524.57k   137461.76k

Ха, наш подопотный работает на порядок медленее!

Такое отставание можно объяснить только проблемой в аппаратной части.

Так и оказалось – у CPU машин кластера отсутствовали флаги аппаратного шифрования - aes, pclmulqdq, sha.

Проверить их наличие можно утилитой lscpu

На виртуальных машинах изменили тип процессора с KVM на host, и флаги для аппаратного шифрования стали доступны в полном объеме.

Новые нагрузочные тесты были более приветливыми:

  • Объем SSL операций упал с 36% до 9% flamegraph-fix

  • Среднее время коммита в kafka снизилось вдвое

до committime-issue

после committime-fix

Достигнутую скорость нельзя назвать идеальной, поэтому работы по оптимизации продолжаются.

To be continued!