DSE/Solr: не удается записать задержку QUEUE

Используя DSE 4.8.7, мы можем вставлять ~ 1000 записей в секунду в таблицу cassandra, которая индексируется Solr. С пропускной способностью какое-то время (может быть, 30-60 минут) все в порядке, пока 2-3 узла (в кластере из 5 узлов) не начнут показывать в журнале следующие сообщения:

INFO  [datastore.data Index WorkPool work thread-0] 2016-05-17 19:28:26,183  AbstractMetrics.java:114 - Cannot record QUEUE latency of 29 minutes because higher than 10 minutes.

В этот момент скорость вставки снижается до 2-10 записей в секунду. Перезапуск узлов решает проблему. Нагрузка на ОС и операции ввода-вывода низкие для всех узлов в кластере. Кроме того, при просмотре статистики nodetool нет ожидающих выполнения задач.

Этот вопрос почти дословно является вопросом здесь, который я делаю на потому что (а) это все еще проблема, и (б) я не могу комментировать этот вопрос.


solr datastax-enterprise datastax-startup
person Shion Deysarkar    schedule 17.05.2016    source источник
comment
К вашему сведению, я также хотел бы знать, где живет AbstractMetrics.java. Я не вижу этого в кодовой базе solr или cassandra. Это специфично для DSE?   -  person Shion Deysarkar    schedule 17.05.2016
comment
Может быть полезно sestevez.com/tuning-dse-search   -  person phact    schedule 18.05.2016
comment
Спасибо, но мы уже прошли этот пост. Мы еще вернемся к этому, но я думаю, что наша текущая проблема выходит за рамки этого поста.   -  person Shion Deysarkar    schedule 18.05.2016
comment
Моя интуиция подсказывает, что слишком мало одновременных индексаторов, вам нужно найти этот баланс. Вы смотрели на показатели jmx очереди индексов?   -  person phact    schedule 19.05.2016
comment
удалось ли решить эту проблему, если да то как? @phact Я все еще сталкиваюсь с этой проблемой, и перезапуск узлов также не решает ее для меня. Я разместил отдельный вопрос для того же stackoverflow.com/questions/39493387/   -  person Hitesh    schedule 15.09.2016
comment
Я не думаю, что мы когда-либо решили эту проблему. Я не знаю четкого решения.   -  person Shion Deysarkar    schedule 16.09.2016

Ответы (1)


arrow_upward
0
arrow_downward

Я подумал, что стоит опубликовать ответ здесь, хотя я также ответил на следующий вопрос почти таким же образом:

Не удается записать задержку QUEUE в n минут — DSE

Когда узел Solr принимает записи, он не только должен принимать записи в обычный путь записи Cassandra, но также должен принимать записи в путь записи Solr. Происходит уплотнение Cassandra, а также эквивалент Solr (слияние Lucene). Сжатие и слияние очень дорого обходятся дисковому вводу-выводу.

По умолчанию параметр dse.yaml будет иметь закомментированный параметр max_solr_concurrency_per_core, это может означать, что слишком много потоков назначено вашей индексации в ядрах solr.

Сообщение, на которое ссылается @phact в блоге выше, действительно хорошее место для начала. Мониторинг IndexPool mBean — хорошее место для начала проверки. Проверьте QueueDepth и посмотрите, увеличивается ли он, если да, то узел не может справиться с пропускной способностью индексации, и пришло время посмотреть на ЦП и ввод-вывод. Если вы не видите высокую загрузку ЦП, вы можете увеличить параллелизм.

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

Еще одна вещь - это размер вашего индекса, уменьшение размера таких вещей, как текстовые поля, путем установки вещей omitNorms=true в схеме также может значительно уменьшить размер индекса.

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

https://docs.datastax.com/en/datastax_enterprise/4.8/datastax_enterprise/srch/srchTune.html

https://docs.datastax.com/en/datastax_enterprise/4.8/datastax_enterprise/srch/srchCmtQryMbeans.html

person markc    schedule 13.10.2016