2015-11-23 2 views
1

Я пытаюсь добавить новый узел в наш кластер (cassandra 2.1.11, 16 узлов, 32 Гб оперативной памяти, 2x3Tb hdd, 8core cpu, 1 центр обработки данных, 2 стойки , около 700 Гб данных на каждом узле). После запуска нового узла данные (приблизительно 600 Гб всего) из 16 существующих узлов успешно передаются на новый узел и начинается запуск вторичных индексов. Процесс вторичного здания индексов выглядит нормально, я вижу информацию о преуспевающей сдаче некоторых вторичных индексов строительных и некоторых задачи потока:cassandra, добавление вторичных индексов при добавлении нового узла длится вечно

INFO [StreamReceiveTask:9] 2015-11-22 02:15:23,153 StreamResultFuture.java:180 - [Stream #856adc90-8ddd-11e5-a4be-69bddd44a709] Session with /192.168.21.66 is complete 

INFO [StreamReceiveTask:9] 2015-11-22 02:15:23,152 SecondaryIndexManager.java:174 - Index build of [docs.docs_ex_pl_ph_idx, docs.docs_lo_pl_ph_idx, docs.docs_author_login_idx, docs.docs_author_extid_idx, docs.docs_url_idx] complete 

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

nodetool compactionstats -H 

показывает

Secondary index build ... docs 882,4 MB 1,69 GB bytes  51,14% 

Таким образом, существует некоторый процесс указательного здания и имеет некоторый прогресс, но очень медленно, 1% в полчаса или около того.

Единственное существенное различие между новым узлом и любым из существующих узлов состоит в том, что java-процесс cassandra имеет 21k открытых файлов, в отличие от 300 открытых файлов на любом существующем узле и 80k-файлов в каталоге данных на новом узле в отличие от 300-500 файлов в каталоге данных на любом существующем узле.

Нормально ли это? На этой скорости мне кажется, что я потрачу 16 недель или около того, чтобы добавить еще 16 узлов.

+0

Вы установили тайм-аут потокового сокета? – phact

+0

no i did not, _streaming_socket_timeout_in_ms_ свойство закомментировано в config, и я думаю, что нет связанных сокетов проблем, поскольку все данные уже переданы на узел назначения, теперь он строит вторичные индексы и делает это очень медленно –

+0

Вторичные индексы строятся очень медленный, но если вы вешаете бесконечно, это может быть связано с потоковой сессией, поэтому убедитесь, что вы установили тайм-аут сокета вперёд. – phact

ответ

0

Я знаю, что это старый вопрос, но мы столкнулись с этой точной проблемой с 2.1.13, используя DTCS. Мы смогли исправить это в нашей тестовой среде, увеличив пороговые значения флеш-памяти до 0.7 - что не имело для нас никакого смысла, но, возможно, стоит попробовать.

+0

спасибо за ответ, в моем случае решение главным образом заключалось в увеличении числа одновременных транзакций от одного (по умолчанию) до семи –