Объясните средние числа загрузки на Солярисе 10
«Загрузка» обычно представляет собой среднее значение первого столбца vmstat (столбец r , очередь выполнения). Первая загрузка усредняется за 1 минуту, вторая - за 5 минут, а последняя - за 15 минут. Как видите, в вашей системе vmstat в какой-то момент сообщил, что не менее 102 потоков проснулись для использования процессора (возможно, какое-то многопоточное приложение).
Но не беспокойтесь, так как этот всплеск рабочей нагрузки определенно обработан, и очередь выполнения вернулась к нулю при следующей проверке и продолжении. V245 имеет два процессора, каждый одноядерный и однопоточный, поэтому он может запускать два потока одновременно (т. Е. R = 2 означает, что потоку не требуется ждать процессорного времени).
Статистически это могло означает в среднем 35, но, как видите, это значение очень мало говорит о фактическом использовании системы. Пословица говорит: «Есть три вида лжи: ложь, проклятая ложь и статистика », и я думаю, что это служит хорошим заключением.
В более ранней версии Solaris средняя загрузка - это среднее количество выполняемых и работающих потоков. Другими словами, это количество потоков, выполняемых на ЦП, плюс количество потоков в очереди выполнения, ожидающих ЦП, усредненное по времени.
Итак ... CPU, который завершил обработку 10 потоков за последнюю секунду ... и имел еще 5 ожидающих обработки, покажет 15.
В отличие от этого ...
Средние нагрузки Linux рассчитываются как "перегрузка" ЦП ... то есть, сколько потоков ожидали процессорного времени в течение последнего периода времени, сколько было завершено. (в процентах)
Итак ... ЦП, который завершил обработку 10 потоков за последнюю секунду ... и имел еще 5 ожидающих обработки, показал бы 0,5
В Solaris 10 ... они изменили формулу немного ... и я не уверен на 100%, что это влечет за собой,
Довольно поздний ответ, но в принятом ответе все еще есть некорректные высказывания, пропущены части пункта, и предполагают, что статистика лежит, в то время как здесь нет причин не доверять тем, о которых сообщает ОС.
Приведем подробное объяснение наблюдаемой статистике.
Среднее значение нагрузки, сообщаемое командами uptime и другими командами, является плавающим средним значением 1 , 5 и 15 минут среднего количества потоков, ожидающих CPU (очереди выполнения), плюс среднее количество потоков, фактически выполняющихся на процессоре.
Идея заключается в том, чтобы сгладить отображение размера очереди выполнения и количества запущенных процессов, которое часто бывает очень нерегулярным.
Размер очереди выполнения - это первый столбец вывода vmstat (r). Любое не нулевое значение здесь означает, что ваша система работала бы быстрее, если бы у нее было больше CPU. Первая строка данных
vmstat показывает среднее значение с момента последней загрузки. Среднее значение 3 потоков ждали на вашей машине перед запуском vmstat. Это значение, как правило, бессмысленно, если оно предопределено длительными периодами неактивности, такими как выходные и другие нерабочие часы:
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 ↑
Все остальные примеры показывают пустую очередь на выполнение, за исключением второго, который показывает огромное среднее число потоков 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% занятых CPU) и ни один поток, активный в течение 7,6 секунды ведущего (0% занятого CPU).
Теперь мы знаем, что определенно существовало соперничество за процессор. Если бы вместо 2 было доступно более 408 CPU и предполагалось, что весь поток мог бы работать на полной скорости параллельно, то эти 2,5 секунды были бы уменьшены примерно до 6 мс. Это оказало бы значительное влияние на интерактивное приложение, но не так сильно на пакетное задание, так как оставшееся время все равно не выиграло бы от дополнительных процессоров.
Итог:
Если ваше приложение интерактивное, то ваша система серьезно перегружена, если нет, то она находится между слегка перегруженным и просто "обычным".
Нужно учитывать компромисс, 6 мс, скорее всего, "слишком хороша" для времени отклика и 408 процессоров слишком дорого. Если предположить, что 60 мс - более разумная цель, то около 40 процессоров могут справиться с этой задачей, и, конечно, если 2,5 с в порядке, то ваша система ведет себя корректно.
Обычно, лучшая практика заключается в том, чтобы предположить, что существует спор, когда общий средний размер очереди превысит количество процессоров, здесь ~37 против 2. Выяснить, является ли это проблемой или нет, можно, не проанализировав, на какие приложения и потоки это влияет и как это влияет на работу платформы
.