Я понимаю среднюю нагрузку в Linux, но меня немного озадачивает средняя нагрузка на устаревшей машине Solaris 10, на которой работает мое приложение. Средние нагрузки кажутся невероятно высокими. Вот результат.
[netcool1 (root)/]$ uptime
11:49am up 580 day(s), 10:51, 3 users, load average: 35.50, 38.54, 39.03
[netcool1 (root)/]$ uname -a
SunOS netcool1 5.10 Generic_139555-08 sun4u sparc SUNW,Sun-Fire-V245
[netcool1 (root)/]$ psrinfo -v
Status of virtual processor 0 as of: 01/11/2012 11:52:52
on-line since 06/10/2010 01:58:29.
The sparcv9 processor operates at 1504 MHz,
and has a sparcv9 floating point processor.
Status of virtual processor 1 as of: 01/11/2012 11:52:52
on-line since 06/10/2010 01:58:27.
The sparcv9 processor operates at 1504 MHz,
and has a sparcv9 floating point processor.
[netcool1 (root)/]$
Я не понимаю, как можно получить среднюю нагрузку 35 на двухпроцессорной системе. Мне это кажется невероятно высоким. Когда я просматриваю процессы с помощью top, система простаивает около 60-70%. Может кто-нибудь помочь объяснить это?
vmstat 10 6
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr rm s0 s2 -- in sy cs us sy id
3 0 0 8747008 5562704 865 1866 188 63 63 0 0 -0 9 40 0 762 8588 1495 26 8 66
0 0 0 7715256 5068016 73 23 5 17 17 0 0 0 110 66 0 1135 3888 9855 59 12 30
0 0 0 7717936 5069128 0 5 0 6 6 0 0 0 100 4 0 1071 3273 4191 62 6 32
0 0 0 7717952 5027912 0 11649 0 5 5 0 0 0 115 21 0 1017 26370 3260 32 15 53
102 1 0 7717952 4979088 0 1 0 0 0 0 0 0 112 4 0 900 3464 7683 15 9 76
0 0 0 7717952 4978936 0 1 0 0 0 0 0 0 105 4 0 886 3379 8698 19 9 72
В более ранней версии Solaris средняя нагрузка - это среднее количество выполняемых и работающих потоков. Другими словами, это количество потоков, выполняемых на ЦП, плюс количество потоков в очереди выполнения, ожидающих ЦП, усредненное по времени.
Итак ... ЦП, который завершил обработку 10 потоков за последнюю секунду ... и имел еще 5 ожидающих обработки, покажет 15.
Напротив...
Средние значения загрузки Linux рассчитываются как «перегрузка» ЦП ... то есть, сколько потоков ожидали процессорного времени в течение последнего периода времени, сколько было завершено. (в процентах)
Итак ... процессор, который завершил обработку 10 потоков за последнюю секунду ... и имел еще 5 ожидающих обработки, покажет 0,5
В Solaris 10 ... они немного изменили формулу ... и я не уверен на 100%, что это влечет за собой, но это должно быть довольно близко.
Довольно запоздалый ответ, но в принятом ответе все еще есть неправильные утверждения, отсутствуют части сути и предполагается, что статистика лжет, хотя здесь нет причин не доверять тем, о которых сообщает ОС.
Вот подробное объяснение наблюдаемой статистики.
Средняя нагрузка сообщается uptime и другие команды - это плавающее среднее значение 1, 5, и 15 минут среднего количества потоков, ожидающих ЦП (очередь выполнения), плюс среднее количество потоков, фактически выполняемых на ЦП.
Идея состоит в том, чтобы сгладить отображение размера очереди выполнения и количества запущенных процессов, которое часто бывает очень нерегулярным.
Размер очереди выполнения - это первый столбец вывода vmstat (r). Любое ненулевое значение здесь означает, что ваша система работала бы быстрее, если бы в ней было больше процессоров.
vmstat первая строка данных показывает среднее значение с момента последней загрузки. В среднем 3 потоки ждали на вашем компьютере, прежде чем вы запустили vmstat. Это значение обычно бессмысленно из-за длительных периодов бездействия, таких как выходные и другие нерабочие часы:
р b w swap free re mf pi po fr de sr rm s0 s2 -- in sy cs us sy мне бы 3 0 0 8747008 5562704 865 1866 188 63 63 0 0 -0 9 40 0 762 8588 1495 26 8 66 ↑
Все остальные образцы показывают пустую очередь выполнения, кроме второй последней, которая показывает колоссальное среднее количество 102 потоки:
102 1 0 7717952 4979088 0 1 0 0 0 0 0 0 112 4 0 900 3464 7683 15 9 76 ↑ ↑
Тем не менее, процессор 76% простоя в течение 10 секунд, что вас озадачивает.
Чтобы понять кажущееся несоответствие, нужно понимать 102 это средний значение для этого образца. Один из способов получить это - предположить, что очередь выполнения удерживала 1020 потоков в течение одной секунды, а затем была пустой в течение оставшихся 9 секунд. Также возможна любая другая комбинация, приводящая к этому числу 102, например, 204 потока в течение 5 секунд и ни одного потока в течение других 5 и так далее.
Однако из vmstat последний столбец, мы знаем, что ваша система была 76% простаивает в этот период. Правдоподобное значение, учитывающее среднюю очередь выполнения и простаивающий ЦП, будет 408 темы, конкурирующие во время 2,4 секунды (ЦП загружены на 100%) и во время 7,6 секунды ведущий (0% загруженного ЦП).
Теперь мы знаем, что была определенная конкуренция за ЦП. Если бы у вас было больше, чем 408 ЦП доступны вместо 2 и предполагая, что весь поток мог бы работать на полной скорости параллельно, вы бы уменьшили эти 2,5 секунды вокруг 6 мс. Это оказало бы сильное влияние на интерактивное приложение, но не так сильно на пакетное задание, так как оставшееся время в любом случае не получит выгоды от дополнительных процессоров.
Нижняя граница:
Если ваше приложение интерактивное, ваша система серьезно перегружена, если нет, то она находится между слегка перегруженной и просто «обычной».
Необходимо учитывать компромисс, 6 мс вероятно, "слишком хорошо" для времени отклика и 408 CPU слишком дорого. Предполагая 60 мс это более разумная цель вокруг 40 процессоров может сработать и, конечно, если 2,5 с в порядке, ваша система работает правильно.
Как правило, лучше всего предполагать наличие разногласий, когда общий средний размер очереди выполнения превышает количество процессоров, здесь ~ 37 против 2. Определить, является ли это проблемой или нет, невозможно без анализа приложений и потоков. затронуты и как это влияет на работу платформы.
"Нагрузка" обычно представляет собой среднее значение первого столбца vmstat (столбец r, очередь выполнения). Первая загрузка усредняется за 1 минуту, вторая - за 5 минут, а последняя - за 15 минут. Как видите, в вашей системе vmstat в какой-то момент сообщил, что не менее 102 потоков проснулись для использования процессора (возможно, какое-то массово многопоточное приложение).
Но не беспокойтесь, поскольку этот всплеск рабочей нагрузки определенно обработан, и очередь выполнения вернулась к нулю при следующей проверке и продолжении. V245 имеет два процессора, каждый одноядерный и однопоточный, поэтому он может запускать два потока одновременно (т. Е. R = 2 означает, что потоку не нужно ждать процессорного времени).
Статистически это мог в среднем 35, но, как вы можете видеть, это значение очень мало говорит о реальном использовании системы. Пословица говорит: "Есть три вида лжи: ложь, проклятая ложь и статистика", и я думаю, что это хороший вывод.
Средняя нагрузка >> 1 и высокий процент простоя обычно являются признаком интенсивного ввода-вывода на диск. это может быть полезно выяснить, почему.