Я пытаюсь упростить имеющуюся у нас систему мониторинга.
У него есть множество видов для просмотра использования ЦП сервера, включая:
Средняя загрузка ЦП (в сумме это все ядра).
Низкая и высокая загрузка ядра (количество ядер, используемых в данный момент времени более 20% или 70%)
У нас также есть конкретные показатели использования каждого отдельного ядра.
Загрузка ядра полезна, потому что у вас может быть 4 ядра, 1 ядро на 100% и 3 ядра на 0%. В этом случае вы можете использовать 1 или 2 ядра, не влияя на вашу рабочую нагрузку, тогда как средняя загрузка ЦП будет показывать только 25% (бесполезно).
Хранение всех этих отдельных показателей очень утомительно, поскольку у нас есть тысячи серверов, которые сообщают показатели несколько раз в минуту.
Есть ли стандартный способ измерения использования ЦП, который учитывает как общую мощность, так и количество используемых ядер (насколько хорошо вы распараллеливаете свою работу)?
Изменить: мы получаем отличные / полезные ответы с точки зрения разработки реальной системы. Но давайте сосредоточимся на общей проблеме «Как вы можете подсчитать / составить единый или небольшой набор показателей, чтобы представить использование компьютером ресурсов процессора, включая параллелизм использования?».
Всегда существовал Лос-Анджелес, служащий по одной и той же причине. Сам по себе LA (средняя загрузка) показывает количество процессов, которые были готовы к запуску при последней проверке. Это несколько затрудняет понимание LA, но также делает его очень полезным для выявления неправильного использования серверов или потенциальных возможностей для улучшения.
Низкое значение LA говорит нам, что сервер чувствует себя хорошо при текущей нагрузке, поэтому даже 100% загрузка ЦП для него не проблема, поскольку он отзывчивый и быстрый.
Высокое значение LA говорит нам, что сервер испытывает некоторую большую нагрузку или не может справиться с текущими задачами, поэтому даже при использовании 5% ЦП может показаться, что сервер полностью завис и не отвечает. Это может произойти в различных ситуациях, таких как ожидание данных с диска (диск перегружен), слишком много данных пересекает границу ядра (плохое кодирование / пространство для улучшения), плохое поведение процессора (проблемы с оборудованием) и т. Д.
Разница между низким и высоким LA мнима и может незначительно отличаться от ОС к ОС. Раньше Linux был довольно небрежным на LA 20, в то время как BSD мог достичь 100 без серьезных последствий. Наверное, сегодня это сильно изменилось.
Измерение времени простоя вашего процессора - не лучший способ измерить производительность или емкость. Высокое использование ЦП может указывать на то, что большее количество ЦП может ускорить работу службы, но лучшим показателем является средняя загрузка. Во-первых, это сообщит вам, ожидает ли работа обработки, но застряла в очереди выполнения, ожидая кванта времени, а также в Linux (и некоторых других операционных системах) планировщик начнет упреждающее выполнение задач, когда есть отставание задачи, ожидающие выполнения (у вас есть отставание, когда средняя загрузка превышает количество процессоров). Эта инъекция переключений контекста приводит к снижению пропускной способности, поскольку ОС пытается завершить tssk и удалить его из очереди выполнения.
В вашем описании 1 ядра на 100% и 3 простаивающих ядер может быть много историй, объясняющих это, и множество решений для более эффективного использования ваших «тысяч серверов». Вам нужно копнуть глубже, чтобы выяснить, является ли это проблемой конфигурации, отсутствием сегментирования задач со стороны приложения, плохим распределением IRQ или несколькими другими причинами.