Как мы все знаем, груз 1,00 на одном процессоре означает, что есть нагрузка 100%. Аналогично 4.00 нагрузка на четырехъядерный процессор будет 100%.
Как интерпретировать нагрузку на 4-ядерный 8-поточный процессор? Когда я достигну максимальной мощности процессора? В 4.00 или 8.00 ?
Не обязательно, но в основном на 1.00*n_cpu.
Загрузка означает следующее: если в системе с одним процессором есть несколько процессов, они, по-видимому, работают параллельно. Но это не так. Что практически происходит: ядро дает процессу 1/100 секунды, а затем прерывает его работу. И отдает следующую 1/100 секунды другому процессу.
Практически вопрос, «какой процесс должен получить следующий интервал в 1/100 секунды?», Будет решаться сложной эвристикой. Он называется задача планирование.
Конечно, процессы, которые заблокированы, например ожидают своих данных, которые они читают с диска, освобождаются от этого планирования задач.
Какая нагрузка говорит: сколько процессов в настоящее время ожидают своего следующего временного интервала в 1/100 секунды. Конечно, это среднее значение. Это потому, что вы можете видеть несколько чисел в cat /proc/loadavg.
Ситуация в системе с несколькими процессорами немного сложнее. Есть несколько процессоров, временные рамки которых могут быть назначены нескольким процессам. Это немного усложняет планирование задач, но не слишком сильно. Но ситуация такая же.
Ядро интеллектуально, оно пытается разделить системные ресурсы для оптимальной эффективности, и оно находится почти в этом (есть незначительные моменты оптимизации, например, лучше, если процесс будет выполняться как можно дольше на одном и том же cpu из-за соображений кеширования, но там они не имеют значения). Это потому, что если у нас есть load 8, это означает: на самом деле 8 процессов ждут своего следующего временного среза. Если у нас 8 процессоров, мы можем передать эти временные отрезки процессорам один к одному, и, таким образом, наша система будет использоваться оптимально.
Если вы видите top, вы можете видеть, что количество реально запущенных процессов на удивление мало: это процессы, отмеченные R там. Даже в не очень хардкорной системе он часто ниже 5. Это частично связано с тем, что процессы, ожидающие свои данные с дисков или из сети, также приостановлены (отмечены значком S вверху). Нагрузка показывает только использование процессора.
Существуют также инструменты для измерения нагрузки на диск, имхо они должны быть по крайней мере важны для мониторинга использования процессора, но почему-то это не так хорошо известно в нашем профессиональном мире системных администраторов.
Инструменты Windows часто делят нагрузку на фактическое количество процессоров. Это заставляет некоторых профессиональных системных администраторов Windows использовать системную нагрузку в этом смысле, разделенном по процессорам. Они не правы и, вероятно, будут счастливее, когда вы им это объясните.
Многоядерные процессоры - это практически несколько процессоров на одном кремниевом кристалле. Нет никакой разницы.
В случае гиперпотоковых процессоров есть интересный побочный эффект: загрузка процессора замедляет работу гиперпоточных пар. Но это происходит на более глубоком уровне, который обрабатывается при обычном планировании задач, хотя он может (и должен) влиять на решения планировщика, касающиеся перемещения процессов.
Но с нашей нынешней точки зрения - то, что определяет загрузку системы - тоже не имеет значения.
Средняя нагрузка не означает то, что вы думаете. Дело не в мгновенном использовании ЦП, а скорее в том, сколько процессов ожидают запуска. Обычно это из-за того, что многим нужен процессор, но не всегда. Распространенный виновник - это процесс, ожидающий ввода-вывода - диск или сеть.
Попробуйте бежать ps -e v и ищем флаги состояния процесса.
state The state is given by a sequence of characters, for example, "RWNA". The first character indicates the run state of the process:
D Marks a process in disk (or other short term, uninterruptible) wait.
I Marks a process that is idle (sleeping for longer than about 20 seconds).
L Marks a process that is waiting to acquire a lock.
R Marks a runnable process.
S Marks a process that is sleeping for less than about 20 seconds.
T Marks a stopped process.
W Marks an idle interrupt thread.
Z Marks a dead process (a "zombie").
Это из ps manpage, так что вы можете найти там более подробную информацию - R и D процессы, вероятно, представляют особый интерес.
Вы можете получить «пики» средней нагрузки по разным причинам, так что они на самом деле не являются хорошим показателем чего-либо, кроме «загружена ли эта система? Увязание в сопоставлении средней нагрузки с ядрами ЦП не принесет вам никакой пользы.
Поскольку гиперпоточность на самом деле не является вторым ядром, она никогда не будет доводить ядро до 200%, но для определенных рабочих нагрузок она может превышать 100%.
Таким образом, ваша максимальная нагрузка где-то неизвестна между 4 и 6
(конечно, это может возрасти при перегрузке, потому что на самом деле учитываются запускаемые процессы, особенно когда они ждут ввода-вывода)
В системе Linux для расчета нагрузки подсчитываются не только процессы в очереди выполнения, но и процессы, находящиеся в состоянии непрерывного сна, википедия, что приводит к резкому скачку нагрузки, когда у вас много процессов, ожидающих диска.
Я провел несколько экспериментов на нашей 24-ядерной системе Xeon (2 сокета по 12 ядер). Максимальная нагрузка в этом случае составляет 48,0 из-за того, как Linux устанавливает гиперпоточность.
Однако вы не получите эквивалент пропускной способности 48 ядер. Я заметил, что вы получаете около 90% пропускной способности первых 24 логических процессоров, т. Е. Если нагрузка достигает 24,0. Затем вы получаете дополнительную пропускную способность около 10% для оставшихся 24 логических процессоров (нагрузка составляет 48,0). Другой способ думать об этом заключается в том, что если вы запустите 48 потоков на 24 ядрах, вы получите прирост примерно на 10-20%, если вы включите гиперпоточность, а не отключите. Это не 100% -ный прирост, как предполагают маркетологи.
Например, один из способов проверить это наблюдение - иметь процесс, выполняющий 48 потоков (скажем, с использованием TBB или управляемой модели потоковой передачи), а затем запустить
time numactl --physcpubind=0-23 ./myprocess
а затем запустить
time numactl --physcpubind=0-47 ./myprocess
Последний должен работать примерно на 10-20% меньше времени. Если ваш процесс сильно заблокирован вводом-выводом, результат может быть другим.
Первый отключит гиперпоточность, разрешив потокам работать только на одном логическом процессоре (каждого ядра), а второй включит гиперпоточность, позволив потокам выполняться на 2 логических процессорах (каждого ядра).
Нагрузка в обоих случаях должна быть 48,0 ... что, как видите, вводит в заблуждение.