Правильный способ интерпретации загрузки системы на 4-ядерном 8-поточном процессоре

Как мы все знаем, загрузка 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.

Ситуация в системе с несколькими процессорами немного сложнее. Существует несколько процессоров, временные рамки которых могут быть заданы нескольким процессам. Это делает планирование задач немного - но не слишком - сложнее. Но ситуация такая же.

Ядро интеллектуально, оно пытается разделить системные ресурсы для достижения оптимальной эффективности, и это близко к этому (есть незначительные вещи оптимизации, например, лучше, если процесс будет запущен как можно дольше того же времени процессор из-за соображений кэширования, но они не имеют значения там). Это потому, что если у нас нагрузка 8, это означает: на самом деле 8 процессов ждут своего следующего интервала времени. Если у нас есть 8 процессоров, мы можем дать эти временные интервалы процессору один к одному, и, таким образом, наша система будет оптимально использована.

Если вы видите a top, вы можете видеть, что число реально запущенных процессов удивительно мало: это процессы, отмеченные Rтам. Даже в не очень хардкорной системе это часто ниже 5. Это частично потому, что процессы, ожидающие свои данные с дисков или из сети, также приостановлены (отмечены Sсверху). Загрузка показывает только использование процессора.

Существуют также инструменты для измерения нагрузки на диск, хотя они должны быть как минимум важны для мониторинга использования процессора, но почему-то это не так хорошо известно здесь, в нашем профессиональном мире системных администраторов.

Инструменты Windows часто делят нагрузку с фактическим числом процессоров. Это заставляет некоторых профессиональных системных администраторов Windows использовать загрузку системы в этом смысле, разделенном на процессор. Они не имеют права и, вероятно, будут счастливее после того, как вы им это объясните.

Многоядерные процессоры - это практически несколько процессоров на одном кремниевом чипе. Нет никакой разницы.

В случае с многопоточными ЦП есть интересный побочный эффект: загрузка процессора замедляет работу его многопоточных пар. Но это происходит на более глубоком уровне, чем обычное планирование задач, хотя оно может (и должно) влиять на решения планировщика о перемещении процессов.

Но с нашей текущей точки зрения - что определяет нагрузку на систему - это тоже не имеет значения.

Поскольку гиперпоточность на самом деле не является вторым ядром, оно никогда не поднимется до 200%, но превысит 100% для определенных рабочих нагрузок.

Таким образом, ваша максимальная нагрузка где-то неизвестна между 4 и 6

(конечно, это может возрасти при перегрузке, потому что фактически учитывает выполняемые процессы, особенно когда они ожидают ввода-вывода)

Средняя нагрузка не означает, что вы думаете, что это значит. Дело не в мгновенном использовании процессора, а в том, сколько процессов ожидает запуска. Обычно это происходит из-за того, что многие хотят процессор, но не всегда. Распространенным виновником является процесс, ожидающий ввода-вывода - диск или сеть.

Попробуйте запустить 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справочной страницы, так что вы можете найти более подробную информацию там - Rи Dпроцессы, вероятно, представляют особый интерес.

Вы можете получить средние значения «пиков» нагрузки по разным причинам, поэтому они не являются хорошим показателем чего-либо, кроме «занята ли эта система». Застревание в отображении средней нагрузки на ядра процессора не принесет вам никакой пользы.

В системе 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 ... что, как вы можете видеть, вводит в заблуждение.