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

Один из наших узлов в нашем кластере из 3 узлов не работает, и при проверке файла журнала он показывает следующие сообщения.

INFO  [keyspace.core Index WorkPool work thread-2] 2016-09-14 14:05:32,891  AbstractMetrics.java:114 - Cannot record QUEUE latency of 11 minutes because higher than 10 minutes.
INFO  [keyspace.core Index WorkPool work thread-2] 2016-09-14 14:05:33,233  AbstractMetrics.java:114 - Cannot record QUEUE latency of 10 minutes because higher than 10 minutes.
WARN  [keyspace.core Index WorkPool work thread-2] 2016-09-14 14:05:33,398  Worker.java:99 - Interrupt/timeout detected.
java.util.concurrent.BrokenBarrierException: null
at java.util.concurrent.CyclicBarrier.dowait(CyclicBarrier.java:200) ~[na:1.7.0_79]
at java.util.concurrent.CyclicBarrier.await(CyclicBarrier.java:355) ~[na:1.7.0_79]
at com.datastax.bdp.concurrent.FlushTask.bulkSync(FlushTask.java:76) ~[dse-core-4.8.3.jar:4.8.3]
at com.datastax.bdp.concurrent.Worker.run(Worker.java:94) ~[dse-core-4.8.3.jar:4.8.3]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [na:1.7.0_79]
at java.util.concurrent.FutureTask.run(FutureTask.java:262) [na:1.7.0_79]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_79]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_79]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
WARN  [keyspace.core Index WorkPool work thread-2] 2016-09-14 14:05:33,398  Worker.java:99 - Interrupt/timeout detected.
java.util.concurrent.BrokenBarrierException: null
at java.util.concurrent.CyclicBarrier.dowait(CyclicBarrier.java:200) ~[na:1.7.0_79]
at java.util.concurrent.CyclicBarrier.await(CyclicBarrier.java:355) ~[na:1.7.0_79]
at com.datastax.bdp.concurrent.FlushTask.bulkSync(FlushTask.java:76) ~[dse-core-4.8.3.jar:4.8.3]
at com.datastax.bdp.concurrent.Worker.run(Worker.java:94) ~[dse-core-4.8.3.jar:4.8.3]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [na:1.7.0_79]
at java.util.concurrent.FutureTask.run(FutureTask.java:262) [na:1.7.0_79]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_79]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_79]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
INFO  [keyspace.core Index WorkPool work thread-4] 2016-09-14 14:05:33,720  AbstractMetrics.java:114 - Cannot record QUEUE latency of 13 minutes because higher than 10 minutes.
INFO  [keyspace.core Index WorkPool work thread-4] 2016-09-14 14:05:33,721  AbstractMetrics.java:114 - Cannot record QUEUE latency of 13 minutes because higher than 10 minutes.

Конфигурация узлов: 8 ЦП, 32 ГБ ОЗУ, 500 ГБ дискового пространства. По каким причинам может выйти из строя только один конкретный узел?


cassandra datastax datastax-enterprise datastax-startup
person Hitesh    schedule 14.09.2016    source источник
comment
Привет Хитеш, Вы нашли решение этой проблемы?   -  person Ram    schedule 29.09.2016
comment
@Ninja еще нет, обновлю ответ, если получу.   -  person Hitesh    schedule 29.09.2016
comment
Эй, ребята, у вас есть ответ на это? У меня та же проблема, но с узлами i2 * 2xlarge (64 ГБ оперативной памяти)   -  person itayad    schedule 19.10.2016

Ответы (1)


arrow_upward
0
arrow_downward

Поэтому я собираюсь ответить с некоторой общей информацией здесь, ваш случай может быть более сложным. 32 ГБ ОЗУ может быть недостаточно для узла Solr; использование сборщика G1 на Java 1.8 оказалось лучше для Solr с размерами кучи более 26 ГБ.

Я также не уверен, какие размеры кучи, настройки JVM и сколько ядер solr у вас есть. Однако я видел подобные ошибки, когда узел занят индексацией и пытается не отставать. По моему опыту, одна из наиболее распространенных проблем, наблюдаемых на узлах Solr, заключается в том, что max_solr_concurrency_per_core остается по умолчанию (закомментировано) в файле dse.yaml. Обычно это распределяет количество потоков индексирования по количеству ядер ЦП, и, чтобы еще больше усугубить проблему, вы можете увидеть 8 ядер, но если у вас есть HT, то на самом деле, скорее всего, 4 физических ядра.

Проверьте свой dse.yaml и убедитесь, что вы установили его на num physcal cpu cores / num of solr cores с минимум 2. Это может индексировать медленнее, но вы должны снять нагрузку с вашего узла.

Я бы порекомендовал этот полезный блог здесь как хорошее начало настройки DSE Solr:

http://www.datastax.com/dev/blog/tuning-dse-search

Также документы по теме:

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

person markc    schedule 11.10.2016
comment
Спасибо за ответ, он хоть и не помог полностью, но помог улучшить производительность. Я начал использовать сборщик G1, обновив Java 1.8 с 1.7, и это очень помогло. Чтобы ответить на ваши вопросы, размер моей кучи составляет 14 ГБ, настройки JVM по умолчанию и около 150 ядер solr. И да, мой max_solr_concurrency_per_core оставлен по умолчанию. (P.S. минусовать не стал) - person Hitesh; 27.10.2016
comment
@Hitesh рад, что вы нашли это полезным. Мне пришлось дать общий ответ, так как, не видя полного журнала и всей вашей конфигурации, сложно дать более подробный ответ. Вам определенно следует настроить параллелизм, поскольку по умолчанию он будет использовать количество ядер процессора, которое может перегрузить ваш процессор. Вы, вероятно, также хотите увеличить размер своей кучи. Я видел, как парни в этой области упоминали, что около 26 ГБ — это хорошая отправная точка. - person markc; 31.10.2016
comment
спасибо, я рассмотрю ваше предложение по размеру кучи. Что касается параллелизма, что, по вашему мнению, должно быть основано на моей конфигурации? - person Hitesh; 14.11.2016
comment
@Hitesh, как я упоминал выше, начните с использования задокументированного предложения num physcal cpu cores / num of solr cores с минимум 2: docs.datastax.com/en/datastax_enterprise/4.8/ - person markc; 15.11.2016
comment
У меня около 200 ядер solr, поэтому я не могу понять, как этот расчет подойдет для меня. На каждый мой узел приходится 8 процессоров. Должен ли я установить max_solr_concurrency_per_core на 6, чтобы 2 процессора использовались для других операций? - person Hitesh; 15.11.2016
comment
@Hitesh Это зависит от того, сколько индексируется одновременно. 200 это довольно большое количество ядер, вы постоянно на все пишете? - person markc; 15.11.2016
comment
нет, большая часть операций записи происходит постоянно примерно на 20 ядрах - person Hitesh; 15.11.2016
comment
Даже с индексацией 20 ядер это, вероятно, слишком много для этих 8-ядерных машин, и они, вероятно, являются 4 физическими ядрами ЦП, как я указал. Вам, вероятно, потребуется увеличить масштаб, чтобы иметь возможность индексировать 20 ядер одновременно. - person markc; 15.11.2016
comment
Итак, вы предлагаете, чтобы каждый из моих узлов состоял как минимум из 20 основных машин, верно? Это может помочь в моей ситуации. - person Hitesh; 16.11.2016
comment
Поэтому в идеале вы должны зарезервировать 2 физических ядра на одно ядро ​​​​solr. Это руководство, если у вас есть, скажем, 4 ядра solr и ваш параллелизм на ядро ​​равен 2, то в идеале 8 физических ядер. Это зависит от того, пишете ли вы одновременно во все таблицы, поддерживающие ядра solr. Вот почему вам нужно тестировать, но да, похоже, что здесь помогут и более крупные процессоры. - person markc; 16.11.2016