Как и многие другие в сообществе Apache Cassandra, я очень рад видеть, что наконец-то вышла версия 4.0. Есть много, много улучшений в Cassandra 4.0 . Одним из улучшений, которое является более важным, чем может показаться, является добавление поддержки Java версий 9 и выше. Это не было тривиальным, потому что Java 9 внесла изменения в некоторые внутренние API, на которые опирались наиболее ориентированные на производительность Java-проекты, такие как Cassandra (вы можете прочитать об этом подробнее здесь ).
Это очень важно, потому что с Cassandra 4.0 вы не только получаете прямые улучшения производительности, добавленные коммиттерами Apache Cassandra, вы также открываете возможность воспользоваться преимуществами семилетних улучшений в самой JVM (виртуальной машине Java).
Здесь я хотел бы сосредоточиться на улучшениях в сборке мусора Java, которые предлагает Cassandra 4.0 в сочетании с Java 16 по сравнению с Cassandra 3.11 на Java 8.
смотрите также: Переход на облачные приложения и данные с помощью Kubernetes и Apache Cassandra
Проблема сбора мусора
В 2012 году я выступил с докладом под названием “Устранение ограничений JVM в Apache Cassandra. ” Вот первый слайд из этой презентации:
С одной стороны, сборка мусора является основной причиной того, что Java намного более производительна, чем традиционные системные языки, такие как C++. Как однажды написал архитектор JVM Клифф Клик: “Многие параллельные алгоритмы очень легко написать с помощью GC и совершенно сложно или совершенно невозможно использовать явный бесплатный. ” Кассандра в полной мере использует эту силу.
Но выполнение сборки мусора означает необходимость кратковременной приостановки JVM, чтобы определить, какие объекты больше не используются и могут быть безопасно удалены. Эти паузы GC могут привести к задержке времени отклика на запросы клиентов, т.е. к увеличению задержек.
Это влияет не на все запросы – только на несколько запросов, которые находятся в полете, в то время как потоки обработки запросов Cassandra приостановлены для GC. Таким образом, влияние на производительность проявляется только в конечных задержках, то есть в измерениях 99-го процентиля или 99,9-го процентиля, соответствующих самым медленным 1% или 0,1% запросов.
Как и во многих других вещах, оптимизация GC предполагает компромиссы, и оригинальные проекты Java GC были больше направлены на повышение пропускной способности, чем на сокращение времени паузы. Перенесемся в 2021 год, и у нас будут обычные процессоры серверного класса с 64 ядрами/128 потоками – у нас достаточно пропускной способности. Пришло время потратить некоторые из этих циклов на меньшее время паузы.
Сборщик мусора Z (GC) был создан для решения этой ситуации и, в частности, для обеспечения времени паузы менее 10 мс. ZGC был добавлен в Java 11 в качестве экспериментальной функции, запущен в производство в Java 15 и дополнительно улучшен в Java 16.
Чтобы показать, насколько хорошо ZGC улучшает производительность Cassandra, мы сравнили пропускную способность и задержку в трех средах: Cassandra 3.11, работающая на JDK 8 с настройками CMS GC по умолчанию, Cassandra 4.0, работающая на JDK 8 с теми же настройками, и Cassandra 4.0, работающая на JDK 16 с ZGC. Я рад сообщить, что ZGC убедительно достигает своих проектных целей, позволяя Cassandra обеспечивать почти постоянные задержки в 99-м процентиле, при этом лишь незначительный прирост в 99,9-м процентиле!
Результаты деятельности ZGC
Мой коллега Джонатан Шейк подробно проанализировал характеристики производительности Cassandra 3.11 и 4.0 для трех рабочих нагрузок: простой ключ/значение, рабочая нагрузка временных рядов с большим количеством строк на раздел и табличная рабочая нагрузка с одной строкой на раздел, но множеством столбцов в строке.
Результаты пропускной способности
Здесь мы смотрим на Кассандру, работающую на 70% от максимальной пропускной способности. Это оставляет 30% рабочего запаса для поглощения уплотнения, ремонта или скачков нагрузки для целей реалистичных измерений.
Cassandra 4.0, работающая с той же конфигурацией, что и Cassandra 3.11, на 30% быстрее в рабочей нагрузке по ключу/значению, на 2% медленнее в рабочей нагрузке по временным рядам и на 10% быстрее в табличной рабочей нагрузке. Включение ZGC открывает дополнительную пропускную способность на 30% для рабочих нагрузок “ключ/значение” и “временные ряды”, но не влияет на рабочую нагрузку в виде таблиц.
Результаты задержки
Я разделил результаты задержки на одну диаграмму для каждой рабочей нагрузки, чтобы было легче увидеть тенденции в разных процентилях:
Для получения этих результатов мы ограничили каждый тестовый сценарий самой низкой пропускной способностью системы, т.е. мы использовали 30 000, 44 000 и 54 000 запросов в секунду для рабочих нагрузок ключ/значение, временные ряды и табличные данные соответственно.
Задержки Cassandra 4.0 практически идентичны задержкам 3.11 с теми же настройками GC, но ZGC стабильно лучше, в 5-10 раз лучше при процентилях p99 и p999.
Набор для тестирования производительности NoSQLBench
Большинство тестов нереляционных баз данных выполняются либо с помощью инструментов, специфичных для конкретного продукта (например, cassandra-stress ), либо с помощью YCSB , что дает вам нагрузку на значение ключа с наименьшим общим знаменателем в десятках систем.
Джонатан покачал головой NoSQLBench быть кроссплатформенным инструментом тестирования производительности, который проще в использовании, чем cassandra-stress, и (намного) более мощным, чем YCSB; фактически, его уровень сценариев достаточно мощный, чтобы поддерживать то, что не может позволить ни один другой инструмент тестирования, с особым акцентом на моделирование сложных рабочих нагрузок с точностью, а также моделирование реалистичных сценариев, таких как скачки нагрузки. Как следует из названия, NoSQLBench не зависит от Cassandra и поощряет участие всех, кто хочет внести свой вклад; сегодня есть клиенты для Cassandra, CockroachDB, JDBC и MongoDB, а также продукты, не относящиеся к базам данных, Kafka и Pulsar. Если вы серьезно относитесь к тестированию производительности в 2021 году, вам следует проверить NoSQLBench. Вы можете начать работу по адресу GitHub . Другие полезные ссылки: релизы , discord , документы .
Описания рабочей нагрузки NoSQLBench для тестов в этом посте можно найти здесь .
СМОТРИТЕ ТАКЖЕ: Быстрый поиск идентификатора процесса приложения Java
Вывод
Без перехода на ZGC Cassandra 4.0 предлагает скромные, но реальные улучшения пропускной способности для рабочих нагрузок с ключами/значениями и таблицами.
Объединение Cassandra 4.0 с ZGC в Java 16 приводит к дальнейшему повышению пропускной способности для рабочих нагрузок по ключу/значению и временным рядам, а также убедительно демонстрирует цели разработки ZGC, направленные на то, чтобы время паузы GC не было проблемой для всех протестированных рабочих нагрузок для Cassandra 4.0.
ZGC готова к производству, начиная с Java 15; для предприятий, которые хотят придерживаться выпусков LTS, ZGC станет одной из главных причин перехода на выпуск Java 17 LTS позже в этом году. ZGC — один из наиболее эффективных доступных “бесплатных обедов”, и он просто работает – результаты, показанные здесь, являются готовыми для ZGC без дополнительной настройки.
Приложение: Тестовая среда
Все тесты проводились на одном и том же физическом кластере узлов AWS i3.4xl: 16 VCPU, 122 ГБ оперативной памяти, 10 Гб сети, 5 узлов в кластере. Хранилище было настроено как XFS на прямом NVMe, один том. Все данные хранились в RF3. Назначенные токены использовались для обеспечения согласованного распределения данных по тестируемым версиям. Уровень согласованности для всех операций был установлен как LOCAL_QUORUM. Параллелизм со стороны клиента был установлен на уровне 960 (20-кратные оценки клиентов) для теста на значение ключа и 480 (10-кратные клиентские ядра) для тестов временных рядов и таблиц. Все измерения были взяты у клиента и включают продолжительность между отправкой и полным считыванием любых данных в результатах. Все измерения проводились с точностью до 3 значащих цифр, затем округлялись до ближайшего мс. ZGC был настроен с основными рекомендуемыми настройками : минимальная куча 16 ГБ, максимальная куча 64 ГБ, включены большие страницы. Другие номера используют готовую конфигурацию Cassandra с CMS.
Оригинал: “https://dev.to/datastax/apache-cassandra-4-0-taming-tail-latencies-with-java-16-zgc-1jfa”