Почему Datastax Opscenter потребляет слишком много ресурсов процессора?

Окружающая среда :

machines : 2.1 xeon, 128 GB ram, 32 cpu
os : centos 7.2 15.11
cassandra version : 2.1.15
opscenter version : 5.2.5
3 keyspaces : Opscenter (3 tables), OpsCenter (10 tables), application`s  keyspace with (485 tables)
2 Datacenters, 1 for cassandra (5 machines )and another one DCOPS to store up opscenter data (1 machine).

Сейчас агенты на узлах потребляют в среднем ~ 1300 процессоров (из 3200 доступных). Единственные транзакционные данные составляют ~ 1500 w/s в пространстве ключей приложения.

Какая-то связь между числовыми таблицами и оперцентром? Это ведет себя одинаково, потребляя много ресурсов ЦП, потому что агенты пытаются записать данные из слишком большого количества метрик, или это какая-то ошибка!?

Обратите внимание, такое же поведение в предыдущей версии opscenter 5.2.4. По этой причине я сначала попытался обновить opg center до последней доступной версии.

Из примечаний к выпуску opscenter 5.2.5: «Устранена проблема с высокой загрузкой ЦП агентами в некоторых топологиях кластера. (OPSC-6045)»

Любая помощь/мнение высоко ценится.

Спасибо.


cpu-usage cassandra-2.1 opscenter
person Mr'Black    schedule 21.11.2016    source источник
comment
Не могли бы вы немного запустить github.com/patric-r/jvmtop или java Flight Recorder? во время забегов? Количество метрик зависит от количества таблиц, но также может быть получено от GC или других служб (например, резервного копирования/восстановления, ремонта). Не могли бы вы попробовать обновиться до версии 6.0.5? было много улучшений с 5.2.5.   -  person Chris Lohfink    schedule 21.11.2016
comment
Привет Крис, спасибо за быстрый ответ.   -  person Mr'Black    schedule 22.11.2016
comment
Об обновлении до 6.0.5 я боюсь, что im on cassandra 2.1.5 and if i remember correctly isnt поддерживается. Насчет бекапа/восстановления, ремонтов на лету нет, кроме разве что read_repairs. Runing top обнаружил, что pid агента отвечает за такую ​​высокую загрузку процессора. Выполнение jps, получение идентификатора агента и запуск jstat -gcutil pid 1000 100 показывает большую активность GC в eden (у меня есть G1GC с кучей 12 Гб). Я постараюсь проверить также с помощью предоставленного вами инструмента, и я постараюсь предоставить более подробную информацию и несколько снимков, сделанных с его помощью.   -  person Mr'Black    schedule 22.11.2016
comment
загрузил экран печати с jvmtop: s000.tinyupload.com/?file_id=67858497675930199607. Агент имеет такое же поведение, если я запускаю его также под root. У меня заканчиваются идеи... Обновлял пока opscenter, java, запускал под разными пользователями агенты, удалял keyspace и т.д.   -  person Mr'Black    schedule 22.11.2016
comment
jvmtop перечисляет PID для выбора, т.е. jvmtop 9019, а не только jvmtop   -  person Chris Lohfink    schedule 22.11.2016
comment
Привет, Крис, запустил его с PID агента: s000.tinyupload.com/?file_id=77218272978659960277   -  person Mr'Black    schedule 23.11.2016

Ответы (1)


arrow_upward
0
arrow_downward

Наблюдая с помощью замечательного инструмента, который вы предоставили Крису, на PID конкретного агента было замечено, что использование кучи было постоянным выше 90%, и это вызывало большую активность GC с огромными паузами GC почти в 1 секунду. Я подозреваю, что в этот период времени потоки объединения должны были ждать и много блокировать мой процессор. В любом случае я не специалист в этой области.

Я принял решение увеличить кучу для агента со 128 по умолчанию до более подходящего значения 512, и я увидел, что все давление GC исчезло, и теперь любое распределение потоков выполняется хорошо.

В целом загрузка процессора снизилась со значений 40-50% до 1-2% для агента opscenter. И я могу жить с 1-2%, так как я точно знаю, что процессор потребляется jmx-метриками.

Поэтому мой совет - отредактируйте файл:

datastax-agent-env.sh

и измените значение по умолчанию 128 Xmx

-Xmx512M

сохраните файл, перезапустите агент и некоторое время наблюдайте.

http://s000.tinyupload.com/?file_id=71546243887469218237

Еще раз спасибо, Крис.

Надеюсь, это поможет другим людям.

person Mr'Black    schedule 23.11.2016