внезапный пик в использовании CPU
Мы выполняем 4 узла/машины эластичный поисковый кластер на 12 ядрах, 96 ГБ RAM, 4 машин вращающего диска. при нормальном функционировании большая часть использования CPU является пользователем и приблизительно 5-10%. Каждые несколько дней, одно из использования CPU машины привязано в 80-100% и является всем пользователем, и система - io ожидают на самом деле уменьшения. Мы сначала думали, что это был elasticsearch конкретный вопрос, но после обширной отладки это, кажется, не так:
- высокая загрузка ЦП переживает elasticsearch перезапуск процесса узла
- потоки elasticsearch все ведут себя обычно, вещи просто берут 10x дольше.
- не elasticsearch операции (набор gc) также берут 10x дольше, но действие "кучи" нормально
Если мы останавливаем процесс приблизительно на час и затем перезапускаем процесс только (не машина), проблема уходит, и вещи хорошо работают в течение нескольких дней.
Мы также заметили, что во время проблемы, тесты дисковой копии являются очень медленными. С процессом, но неактивный (не индексация/поиск данных) или вскоре после того, как остановился процесс, копирование файла на 1 ГБ через dd происходит приблизительно в 18MB/s на проблематичной машине, но в 490MB/s, когда здоровый. Интересно, мы заметили использование dstat, что медленная копия заняла приблизительно 25 секунд прежде, чем сделать любой i/o и затем заняла еще 30 секунд для завершения. Вывод strace, казалось, не существенно отличался.
Какая-либо идея, что дальнейшие тесты мы могли работать?
Есть много проблем, связанных с Elastic Search, и с помощью быстрого гуглинга вы можете найти некоторые из них. Но основная проблема при высоком использовании процессора может быть вызвана отсутствием контроля над использованием кэша. Ниже приведены ссылки :
https://github.com/elasticsearch/elasticsearch/issues/4288 http://elasticsearch-users.115913. .n3.nabble.com/Very-high-sys-cpu-usage-with-HTTP-KeepAlive-td4049998.html http://blog.sematext.com/2012/05/17/elasticsearch-cache-usage/
Процессы, использующие много CPU, должны появляться наверху, как предложил Иэн Макинтош, но поскольку они основаны на выборке таблицы процессов по регулярному циклу, то видимость может зависеть от того, как долго эти процессы выполняются.
Утилиты учета GNU также могут быть очень полезны для такого рода вещей. (пакет = 'acct' на системах, основанных на debian, или 'psacct' на системах, основанных на redhat). Обычно я запускаю сверху, а учетный пакет на большинстве серверов (accton на).
После того, как вы включили сбор учетных данных, ведется статистика об использовании процессора каждым запущенным процессом, начиная с wqith, когда он запустился и заканчивая его запуском. Это может быть очень полезно, когда кучка короткоживущих процессов потребляют ваш процессор, что трудно увидеть с atop, strace и т.д. (хотя strace может быть более полезным с флагом -f или -ff). Это менее полезно, когда у вас есть процессы с продолжительностью жизни намного дольше, чем у CPU spike, но в таких случаях atop должен дать вам то, что вы хотите. - lastcomm, вероятно, является тем инструментом, который вам нужен для доступа к собранной статистике.
- хотя и очень полезен, но strace говорит только о системных вызовах. Если у вас что-то интенсивно используется процессором, но вы не вызываете систему, оно не появится. Иногда для этого может пригодиться ltrace, но опять же, только если соответствующая активность происходит внутри вызова библиотеки, а это не всегда так.
Инструменты типа strace и ltrace, а возможно даже отладчик типа gdb, вступают в игру только после того, как вы определили процесс, потребляющий процессор, и похоже, что у вас его еще нет. На данный момент, на вершине и в lastcomm, вероятно, есть путь.
Какие еще тесты вы можете запустить?
(Не хватает информации, например, какой системный процессор % при привязке к пользовательскому %), но проверьте, какой процент процессора составляет IRQ, на всякий случай, если это куда-то ведет.
Если предположить, что системный процессор % довольно высок и это не IRQ, то, возможно, вы захотите проверить память. Удобный инструмент для обзора находится наверху, он должен сказать вам, если что-то вроде сканирования страницы или кражи страницы вызывает это, потому что вы находитесь под сильным давлением памяти.
Я собираюсь предположить, что вы исключили подмену как проблему.
Потому что наверху дается довольно полный обзор состояния машины, это очень удобно в получении информации об общем состоянии. Это поможет вам сравнить atop на корректно работающей системе с той, что неправильно работает.
Если только аномалия - это пользовательский CPU % и система работает корректно, иначе вы, скорее всего, имеете дело с программной ошибкой и вам придётся обратиться за помощью к её авторам - или изменить способ её использования, чтобы избежать срабатывания любой найденной вами ошибки. Просто проверьте, что вы имеете дело не со своей собственной ошибкой - т.е. вы называете её плохо, или в цикле, или что-то в этом роде. Я видел это несколько раз.
Подводя итог, покопайтесь в памяти, irq, swap и т.д. и посмотрите, сможете ли вы их исключить - я предлагаю сверху быстро сравнить нормальное и аберрантное поведение и выделить критические элементы.
.