Драйвер Spring Data Cassandra зависает через несколько часов с одноузловой базой данных на том же узле

У меня возникли проблемы с доступом к базе данных Apache Cassandra через spring-data-cassandra:

  • Иногда сервер не может подключиться к базе данных на старте - обычно получается со 2-й попытки
  • После запуска, пару раз в час, в случайные моменты, несколько запросов терпят неудачу с тайм-аутом, а затем продолжает работать нормально
  • Наконец, через несколько часов драйвер начинает последовательно отклонять запросы, сообщая о тайм-аутах, и сервер необходимо перезапустить.

Приложение представляет собой небольшое серверное приложение Spring Boot (1.4.0), использующее Spring Data Cassandra (пробовали 1.4.2 и 1.4.4). Приложение собирает данные от удаленных клиентов и реализует некоторый административный графический интерфейс на основе интерфейса REST на стороне сервера, включая панель мониторинга, подготавливаемую каждые 10 секунд с помощью задач Spring @Scheduled и доставляющую данные клиентам (браузерам) по протоколу веб-сокета. Трафик защищен с помощью HTTPS и двусторонней аутентификации (серверные + клиентские сертификаты).

Текущее состояние приложения тестируется в настройке с базой данных (2.2.8), работающей на том же облачном сервере (подключение через петлевой адрес 127.0.0.1) с ОС Ubuntu 14.04. Несколько тестовых клиентов создают нагрузку, в результате чего вставляется около 300 000 записей базы данных в час (50 000 основных и 5x50 000 подробных записей), загружая данные каждые 5 секунд или около того. Приборная панель отслеживает трафик за последний час и создает статистику. Средняя загрузка ЦП утилитой sar составляет около 10%. Текущий размер базы данных составляет около 25 ГБ.

Вставка данных производится небольшими партиями - я пробовал также отдельные записи, но проблема не исчезла, просто загрузка ЦП увеличилась примерно на 50% при тестировании с одиночными записями.

Я провел много «исследований» Google по этой теме и не нашел ничего конкретного, но попробовал довольно много советов, например. добавление имени схемы во все запросы и несколько параметров конфигурации - по-видимому, не влияет на окончательный результат (заблокированный сервер требует перезагрузки). Сервер работает до 30 часов или около того, но иногда блокируется в течение 1-2 часов, обычно работает за 7-10 часов до зависания драйвера, без какой-либо очевидной закономерности в периоде работы.

Я следил за кучей - ничего особенного, никаких структур данных, накапливающихся со временем. Сервер запускается с -Xms2g -Xmx3g -XX:+PrintGCDetails

В итоге появляется ошибка:

Caused by: com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (tried: inpresec-cassandra/127.0.1.1:9042 (com.datastax.driver.core.OperationTimedOutException: [inpresec-cassandra/127.0.1.1:9042] Operation timed out))
        at com.datastax.driver.core.RequestHandler.reportNoMoreHosts(RequestHandler.java:217) ~[cassandra-driver-core-2.1.9.jar!/:na]
        at com.datastax.driver.core.RequestHandler.access$1000(RequestHandler.java:44) ~[cassandra-driver-core-2.1.9.jar!/:na]
        at com.datastax.driver.core.RequestHandler$SpeculativeExecution.sendRequest(RequestHandler.java:276) ~[cassandra-driver-core-2.1.9.jar!/:na]
        at com.datastax.driver.core.RequestHandler$SpeculativeExecution$1.run(RequestHandler.java:374) ~[cassandra-driver-core-2.1.9.jar!/:na]
        ... 3 common frames omitted

Что я также заметил, так это то, что процесс cassandra сообщает о размере виртуальной памяти, примерно соответствующем размеру базы данных - я заметил это, когда база данных была около 12 ГБ, и она точно следовала размеру базы данных - не уверен, что это имеет какое-либо отношение. с сервером проблема. Резидентная часть базы данных составляет от 2 до 3 ГБ. Резидентная часть сервера обычно занимает 1,5-2,5 ГБ. Общий объем памяти облачного сервера составляет 8 ГБ.

Прежде чем запускать Cassandra непосредственно в ОС виртуальной машины хоста, я запускал ее в Docker и имел ту же проблему — выход из Docker был сделан, чтобы исключить Docker из «списка подозреваемых».

Если у кого-то было что-то подобное, буду признателен за информацию или совет.


java spring cassandra spring-data-cassandra
person Vučko    schedule 13.11.2016    source источник
comment
Что в логах Кассандры? Можете ли вы прочитать что-нибудь из кластера, например. с cqlsh?   -  person Ivan    schedule 13.11.2016
comment
Да, cqlsh работает отлично все время, ничего подозрительного в system.log, debug.log, gc.log - пакет вставки иногда превышает 5 КБ для сотен байтов или около того, создавая предупреждение, но ничего больше, на самом деле.   -  person Vučko    schedule 13.11.2016
comment
Работает ли вставка дополнительных данных через cqlsh? Если вы перезапустите процесс записи, он сработает?   -  person Ivan    schedule 13.11.2016
comment
Можете ли вы поделиться кодом для него (например, через github)?   -  person Ivan    schedule 13.11.2016
comment
Похоже на проблемы с сетью/средой. Spring Data Cassandra использует драйвер Cassandra от Datastax под капотом. Вы можете предоставить собственные экземпляры Cluster/Session с настроенными параметрами подключения/сокета/тайм-аута.   -  person mp911de    schedule 13.11.2016
comment
Иван: проблем с cqlsh-операциями нет, приложение работает после перезагрузки - вряд ли сама база. К сожалению, я не могу опубликовать полный исходный код, хотя он уже есть на github (частный проект). mp911de: я уже попробовал пару вариантов, попробую еще, спасибо, но похоже, что драйвер как-то зависает - сеанс поврежден или что-то еще - и со схемой подключения весенних данных я понятия не имею, как повторно инициализировать.   -  person Vučko    schedule 13.11.2016

Ответы (1)


arrow_upward
0
arrow_downward

Проблема, по-видимому, была решена путем обновления Netty и обеспечения поддержки протокола epoll, который будет использоваться вместо резервного варианта NIO по умолчанию. Изначально в pom.xml было:

<dependency>
    <groupId>io.netty</groupId>
    <artifactId>netty-all</artifactId>
    <version>4.0.9.Final</version>
</dependency>

Теперь это было изменено на:

    <dependency>
        <groupId>io.netty</groupId>
        <artifactId>netty-all</artifactId>
        <version>4.0.29.Final</version>
    </dependency>

    <dependency>
        <groupId>io.netty</groupId>
        <artifactId>netty-transport-native-epoll</artifactId>
        <version>4.0.29.Final</version>
        <!-- Explicitly bring in the linux classifier, test may fail on 32-bit linux -->
        <classifier>linux-x86_64</classifier>
        <scope>test</scope>
    </dependency>

добавление второй спецификации для явного включения поддержки epoll, как предлагается здесь.

После этого изменения исходное сообщение появляется в файле журнала:

com.datastax.driver.core.NettyUtil       : Did not find Netty's native epoll transport in the classpath, defaulting to NIO.

превратился в:

com.datastax.driver.core.NettyUtil       : Found Netty's native epoll transport in the classpath, using it

С тех пор не было случайных сбоев - пытался «убить» соединение с БД, несколько раз создавая очень большие запросы - он покорно сообщал об ошибке памяти - а затем восстанавливался.

person Vučko    schedule 15.11.2016