Мы запускаем эластичный поисковый кластер с 4 узлами / машиной на 12 ядрах, 96 ГБ ОЗУ и 4 машинах с вращающимся диском. при нормальной работе процессор чаще всего используется пользователем и составляет около 5-10%. Каждые несколько дней использование одного ЦП машины фиксируется на уровне 80–100% и полностью определяется пользователем и системой - время ожидания io фактически уменьшается. Сначала мы думали, что это проблема, связанная с эластичным поиском, но после обширной отладки, похоже, это не так:
Если мы остановим процесс примерно на час, а затем перезапустим только процесс (а не машину), проблема исчезнет, и все будет работать нормально в течение нескольких дней.
Мы также заметили, что во время проблемы тесты копирования диска очень медленные. Когда процесс запущен, но простаивает (без индексации / поиска данных) или вскоре после остановки процесса, копирование файла размером 1 ГБ через dd происходит со скоростью около 18 МБ / с на проблемной машине, но со скоростью 490 МБ / с в исправном состоянии. Интересно, что мы заметили, используя dstat, что медленное копирование занимало около 25 секунд перед выполнением любого ввода-вывода, а затем потребовалось еще 30 секунд для завершения. Вывод strace не сильно отличался.
Есть идеи, какие еще тесты мы могли бы провести?
Процессы, использующие много ЦП, должны отображаться поверх, как было предложено Яном Макинтошем, но поскольку он основан на выборке таблицы процессов в регулярном цикле, эта видимость может зависеть от того, как долго эти процессы выполняются.
Утилиты бухгалтерского учета GNU также могут быть очень полезны для подобных задач. (package = 'acct' в системах на основе Debian или 'psacct' в системах на основе Redhat). Я обычно запускаю поверх и включил бухгалтерский пакет (accton on) для большинства серверов.
После того, как вы включите сбор учетных данных, будет храниться статистика об использовании ЦП каждым запущенным процессом, включая время его запуска и завершения. Это может быть очень полезно, когда ваш процессор потребляет куча недолговечных процессов, что трудно увидеть с помощью atop, strace и т. Д. (Хотя strace может быть более полезным с -f или -ff флаг). Это менее полезно, когда у вас есть процессы, время жизни которых намного больше, чем скачок ЦП, но в этих случаях поверх должен дать вам то, что вы хотите. lastcomm возможно, вам нужен инструмент для доступа к собранной статистике.
Хотя strace очень полезен, он сообщает вам только о системных вызовах. Если у вас что-то интенсивно использует процессор, но не вызывает систему, оно не появится. Иногда ltrace может быть полезен для этого, но опять же, только если соответствующее действие происходит в вызове библиотеки, а это не всегда так.
Такие инструменты, как strace и ltrace, и, возможно, даже отладчик, такой как gdb, вступают в игру только после того, как вы определили процесс, который потребляет процессор, а это не похоже на то, что у вас это еще есть. На этом этапе, вероятно, лучше всего использовать atop и lastcomm.
С 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/
Какие еще тесты вы могли бы провести?
(Отсутствует некоторая информация, например, какой процент ЦП системы при привязке к% ЦП пользователя), но проверьте, какой процент ЦП составляет IRQ, на всякий случай, если это куда-то приведет.
Предполагая, что% CPU системы довольно высок и это не IRQ, вы можете проверить память. Удобный инструмент для обзора находится наверху, он должен сказать вам, если что-то вроде сканирования страниц или их кражи вызывает это из-за сильной нехватки памяти.
Я предполагаю, что вы исключили подмену как проблему.
Поскольку atop дает вам достаточно полный обзор состояния машины, он очень удобен для получения информации об общем состоянии. Это помогло бы сравнить наверху в правильно работающей операционной системе с другой, которая также плохо себя ведет.
Если только отклонение от нормы - это процентный показатель ЦП пользователя, и сама система работает правильно, иначе вы, вероятно, столкнетесь с ошибкой программного обеспечения и вам придется обратиться к авторам за помощью - или изменить способ ее использования, чтобы не вызывать любую ошибку, которую вы ' я нашел. Просто убедитесь, что вы не имеете дело со своей собственной ошибкой - т. Е. Вызываете ее плохо, зацикливаетесь или что-то в этом роде. Я видел это несколько раз.
Таким образом, покопайтесь в памяти, irq, swap и т. Д. И посмотрите, сможете ли вы их исключить - я предлагаю сверху для быстрого сравнения между нормальным поведением и аномальным поведением и для выделения критических элементов.