- Чем длительно нагрузить CPU на полную?
- Как я могу произвести высокую загрузку процессора на сервере Linux?
- Загрузка процессора Linux
- Как посмотреть загрузку процессора в Linux
- 1. Утилита htop
- 2. Файл /proc/loadavg
- 3. Утилита mpstat
- 4. Команда nmon
- 5. CoreFreq
- Выводы
- Стресс тест процессора в Linux
- Стресстест процессора в терминале Linux
Чем длительно нагрузить CPU на полную?
Собственно, вопрос в заголовке. Есть ноутбук, в нем i7-4702HQ. Хочу дать ему непрерывную максимальную нагрузку чтобы посмотреть на температуру и узнать, способна ли установленная система охлаждения справится с таким режимом работы.
На ум приходит встроенный бенчмаркинг 7z или geekbench в цикле. Может запустить какую-то компиляцию?
Вангую, что не сможет.
libreoffice, llvm, qtwebengine
вот где бы светоч пригодился
install gentoo + emerge firefox libreoffice qtwebengine
Я лично в таких случаях делаю
Запустить многопоточный архиватор с максимальным сжатием из /dev/urandom
Установи кучу говно-приложений на Electron. Запусти их все. Но может не выйти, скорее всего, раньше отвалится твоя оперативка. Уйдёт в своп и всё зависнет 🙂
Если компиляция, то chromium — вот это жесть.
А так, да urandom неплохой вариант. iotop, емнип, тоже грузит одно ядро на полную
There are several options for the torture test (menu option 15).
Small FFTs (option 1) to stress the CPU
вообще-то для таких случаев есть stress — ка раз для стресс-тестирования системы. Не только для проца, умеет в рам, хдд и своп, вроде.
Странно, что никто не посоветовал.
Факториал большого числа.
Вдобавок к вышеупомянутым программам советую попробовать cpuburn.
Тесты в cpuburn однопоточные, для многоядерных процессоров нужно запускать соответствующее количество экземпляров одного и того же теста. Здесь описаны примеры: https://www.hecticgeek.com/2012/03/cpuburn-cpu-stress-test-ubuntu-linux/
Несмотря на то, что кодовая база проекта для платформы x86 не обновлялась с 2004 года (кроме баг-фиксов), всё же он может быть более полезным для стресс-теста конкретно охлаждения, чем вышеупомянутые аналоги. Он может сильнее нагрузить процессор, чем аналогичный тест, который делает лишь простую целочисленную арифметику. То есть, при одинаковой загруженности процессора в 100% его температура может отличаться в зависимости от задач, которые он решает.
Универсальные бенчмарки вроде Geekbench исполняют кучу различных тестов, обычно по очереди. Это и однопоточные операции, и многопоточные, и целочисленная арифметика, и задействование FPU и различных расширений. Но эти тесты не ставят перед собой задачу максимально нагреть процессор. Теоретически, процессор может даже немного остывать в менее затратных по электроэнергии тестах.
Да, вот конкретно на примере Geekbench 4 указаны куча тестов для CPU https://www.geekbench.com/doc/geekbench4-cpu-workloads.pdf. Но при этом там есть такая заметка:
Geekbench inserts a pause (or gap) between each workload to minimize the effect thermal issues have on workload performance.
То есть, Geekbench 4 умышленно делает паузу, чтобы дать процессору немного остыть между тестами. Именно это совсем не подходит для твоей задачи. Насколько я понял, там можно регулировать эту паузу, но я не знаю, насколько.
С другой стороны, если в Geekbench можно запустить выполнение конкретного теста в режиме нон-стоп без всяких пауз, то почему бы и нет? Там есть ряд тестов, которые используют новые расширение, новые инструкции. Возможно, один из этих тестов может оказаться наиболее «горячим» для конкретно твоего процессора.
Вернемся к cpuburn. Конечно, за 14 лет многое изменилось, в тестах cpuburn нет новых инструкций, не проводились оптимизации для новых поколений процессоров. И тем не менее, было бы интересно посмотреть, до каких предельных температур нагревают современные процессоры разные тесты.
Источник
Как я могу произвести высокую загрузку процессора на сервере Linux?
В настоящее время я нахожусь в процессе отладки установки Cacti и хочу создать загрузку ЦП для отладки графиков загрузки ЦП.
Я попытался просто запустить cat /dev/zero > /dev/null , который прекрасно работает, но использует только 1 ядро:
Есть ли лучший метод тестирования / максимизации системных ресурсов под нагрузкой?
Попробуйте stress Это в значительной степени эквивалент Windows consume.exe :
Нет необходимости устанавливать какой-либо дополнительный пакет, ваш старый добрый шелл может сделать это самостоятельно.
Этот однострочный загрузит ваши четыре ядра 1 на 100%:
Как это работает, довольно просто, он запускает четыре бесконечных цикла. Каждый из них повторяет нулевую инструкцию ( : ). Каждый цикл способен загружать ядро процессора на 100%.
Если вы используете bash , ksh93 и другие оболочки поддерживаете диапазоны, (т.е. не dash старше ksh ), вы можете использовать это не портативный синтаксис:
Замените 4 на количество процессоров, которые вы хотите загрузить, если отличается от 4 .
Предполагая, что при запуске одного из этих циклов у вас уже не было фоновой работы, вы можете остановить генерацию нагрузки с помощью этой команды:
Отвечая на комментарий @ underscore_d, вот улучшенная версия, которая значительно упрощает остановку загрузки, а также позволяет указать тайм-аут (по умолчанию 60 секунд.) A Control — C также уничтожит все циклы разгона. Эта функция оболочки работает как минимум под bash и ksh .
1 Обратите внимание, что с процессорами, поддерживающими более одного потока на ядро (Hyper-threading), ОС распределяет нагрузку на все виртуальные процессоры. В этом случае поведение загрузки зависит от реализации (для каждого потока может быть указано, что он занят на 100% или нет). ,
Источник
Загрузка процессора Linux
Чтобы узнать хватает ли мощности процессора вашему серверу или компьютеру надо посмотреть загрузку процессора в данный момент или за последнее время. Это значение показывает на сколько процентов используется вычислительная мощность процессора.
В этой статье мы рассмотрим несколько способов решения этой задачи с помощью привычных системных утилит и более сложных инструментов.
Как посмотреть загрузку процессора в Linux
1. Утилита htop
Самый простой способ узнать насколько процессор загружен в данный момент — воспользоваться утилитой htop. Она показывает не только процент загрузки по каждому ядру процессора отдельно, но и позволяет найти процессы, которые нагружают систему больше всего. Для установки htop в Debian или Ubuntu выполните:
sudo apt install htop
А в CentOS или REHL:
sudo yum install htop
Главное окно программы выглядит вот так:
Здесь в верхней части окна выводится загрузка ядер процессора в виде наглядных шкал, а ниже процессы. В данном примере у процессора 12 ядер и каждое из них загружено не больше чем на один процент.
2. Файл /proc/loadavg
Если надо сориентироваться какая была нагрузка на процессор в последнее время, тут htop не поможет. Можно воспользоваться файлом /proc/loadavg. Его создаёт ядро и в нём содержится информация о средней нагрузке за одну, пять и пятнадцать минут. Но обратите внимание, данные, находящиеся в этом файле не такие однозначные. Во первых, это не проценты, во вторых, они отображают не нагрузку на процессор, а нагрузку на систему в целом.
Первые три значения в этом файле означают среднее количество процессов или потоков, которые выполняются, находятся в очереди на выполнение или ждут завершения операций ввода/вывода за 1, 5 и 15 минут. Вот:
Обычно, если значение больше единицы — значит нагрузка уже большая и надо разбираться почему. Если значение за минуту меньше значений за пять и пятнадцать минут — нагрузка падает, если больше — растёт. Таким образом можно немного сориентироваться насколько загружена ваша система. Эти значения можно использовать для общего ориентирования или отправки уведомлений на почту, а для разбора полётов уже применять другие метрики и программы.
Четвертое значение здесь — это количество процессов — выполняемых в данный момент, обычно соответствует количеству процессоров, следующее число через слеш — это общее количество таких процессов в системе. Последнее значение — PID последнего созданного процесса.
3. Утилита mpstat
Утилита mpstat позволяет посмотреть подробную статистику по использованию процессора. Можно посмотреть не только информацию по каждому из ядер, но и куда используются ресурсы — на ввод/вывод, ядро или программы пространства пользователя. Для установки программы в Ubuntu или Debian выполните:
sudo apt install sysstat
В CentOS или REHL:
sudo yum install sysstat
Для просмотра общей информации выполните такую команду:
А для просмотра подробностей по каждому ядру процессора используйте опцию -P с параметром ALL:
Вот значения колонок в выводе этой программы:
- CPU — номер ядра процессора;
- %usr — потребление программами пространства пользователя;
- %nice — потребление ресурсов в процентах программами в пространстве пользователя с повышенным приоритетом;
- %sys — потребление ресурсов процессора ядром;
- %iowait — затраты на ожидание ввода/вывода;
- %irq — ресурсы, потраченные на прерывания для работы с аппаратным обеспечением;
- %soft — ресурсы, потраченные на программные прерывания;
- %steal — украденные процессорные ресурсы, актуально для виртуальных машин;
- %guest — ресурсы, потраченные на работу виртуального процессора;
- %idle — неиспользованные ресурсы.
Как видите, в данном случае нагрузка на процессор не достигает даже трех процента для некоторых ядер.
4. Команда nmon
Утилита nmon позволяет выводить данные, в виде, похожем на htop, но только немного подробнее. Для установки её в Ubuntu и Debian выполните:
sudo apt install nmon
Для установки в CentOS или REHL:
sudo yum install nmon
После запуска надо нажать кнопку c для того чтобы отобразить информацию о нагрузке на ядра процессора:
Здесь кроме наглядной шкалы по каждому ядру выводится информация в процентах по таким показателям:
- User% — ресурсы, потраченные программами в пространстве пользователя;
- Sys% — ресурсы, потраченные ядром;
- Wait% — ресурсы, которые идут на ожидание ввода/вывода;
Здесь уже можно сориентироваться насколько всё загружено и в чём проблема.
5. CoreFreq
Если всей полученной ранее информации о производительности вам мало, можно воспользоваться утилитой CoreFreq. Её нет в официальных репозиториях, поэтому придется собирать программу из исходников. Но зато она имеет свой модуль ядра, который устанавливает свои счетчики производительности в ядре и возвращает утилите наиболее подробные данные. Сначала установите необходимые компоненты. В Ubuntu:
sudo apt install dkms git libpthread-stubs0-dev
В CentOS или REHL:
sudo yum group install ‘Development Tools’
Затем скачайте репозиторий утилиты с GitHub и соберите её:
git clone https://github.com/cyring/CoreFreq.git
Загрузите модуль ядра такой командой:
sudo insmod corefreqk.ko
Запустите её сервис:
Затем запускайте программу:
Вверху программы отображается информация о процессоре, ниже шкалы с загруженностью каждого ядра, а её ниже различные показатели по каждому ядру: частота — Freq, ускорение — Turbo, C0-C7 — значения состояний C-State процессора. В данном примере, большинство ядер процессора работают на минимальной частоте и большую часть времени находятся в состоянии C1. Это состояние означает, что ядро не активно, но может в любой момент перейти к выполнению инструкций. Состояние C0 — означает, что ядро активно и выполняет какие-то действия.
С помощью этой утилиты вы сможете узнать максимально подробную информацию о загрузке процессора и о самом процессоре в целом.
Выводы
В этой небольшой статье мы рассмотрели как определяется загрузка процессора Linux с помощью различных утилит. Как системных, так и сторонних. А какие утилиты для таких целей используете вы? Напишите в комментариях!
Источник
Стресс тест процессора в Linux
Прогнал я тест Linpack и задумался: а не пора ли мне поменять термопасту на своём ноутбуке?
Да, по результатам нескольких тестов подряд (не буду захломлять статью картинками) видно, что процессор уходит в троттлинг (пропуск тактов и сброс частоты при нагреве), но вот, как быстро он начинает это делать?
Стресстест процессора в терминале Linux
Задавшись этим вопросом и поискав в интернете утилиты, я понял, что основная проблема в решении поставленной мной задачи — одновременный запуск, как минимум пары утилит и разбегающиеся глаза в двух окнах. И я пришёл к выводу, что мне больше подходит консольный вариант, нежели разноцветные окна открытых программ.
Начал я с sysbench:
sudo apt install sysbench
sysbench —num-threads=4 —test=cpu —cpu-max-prime=100000 run
- —num-threads=4 — это количество потоков, у меня двухъядерный четырёхпотоковый Intel® Core™ i7-640M, поэтому 4;
- —cpu-max-prime=100000 — это максимальное количество выполненных операций, я выставил в 100000, т.к. по умолчанию — 10000, слишком быстро завершают тест.
Потом я перешёл на Linpack. Так как процессор у меня от Intel и я имею некоторую долю лени (лень — двигатель прогресса), то я взял, скачал и распаковал готовый Intel-овский Linpack, предварительно создав в домашнем каталоге директорию linpack:
mkdir ./linpack
cd ./linpack
wget http://registrationcenter-download.intel.com/akdlm/irc_nas/9752/l_mklb_p_2018.3.011.tgz
tar -xvzf ./l_mklb_p_2018.3.011.tgz
Для AMD процессоров такой вариант я бы не стал пробовать, так как компилятор от Intel вставляет закладки, проверяющие процессор и если он не Intel. ну, подумаешь сотню-другую лишних инструкций процессор выполнит и заведомо проиграет в производительности. Для AMD лучше собрать Linpack из исходников, например, из этих. В данной статье сборку из исходников рассматривать не буду — читайте README в source code.
Вернёмся к Intel-овскому Linpack-у. Там много чего лишнего и мне не нужного, а то, что нужно рассмотрю относительно версии 2018.3.011. Сразу же перейду в нужную директорию, чтоб потом не набирать длинные команды:
Так как по умолчанию Intel-овский Linpack заточен под тестирование серверных Xeon-ов, создадим свой файл, который будет использоваться в качестве входных опций — просто уменьшим количество тестов, иначе устанем «пару-тройку дней» ждать завершения теста. У меня Linux Mint LMDE 3, поэтому я использую текстовый редактор xed, да и нравится он мне бОльшим функционалом, особенно, когда из-под root-а его запускать — он цвет на красный меняет. И так, создаём в этой же директории, в которую перешли, файл, например, my_test:
И в созданный файл копируем следующее содержимое:
Shared-memory version of Intel(R) Distribution for LINPACK* Benchmark. *Other names and brands may be claimed as the property of others.
Sample data file lininput_xeon64.
5 # number of tests
1000 2000 5000 10000 20000 # problem sizes
1000 2000 5008 10000 20000 # leading dimensions
4 2 2 2 1 # times to run a test
4 4 4 4 4 # alignment values (in KBytes)
Ну, и собственно запуск Linpack с созданным файлом:
./xlinpack_xeon64 -i ./my_test
Можно ещё заюзать stress-ng или stress, но поставленной мной задачи это всё-равно не решает. Вывода температуры, частот и времени от начала старта эти утилиты мне не показывают.
Температуру может показать sensors — подробнее про установку этой утилиты здесь. И эта утилита понадобится в дальнейшем рассмотрении моего вопроса. Линукс — велик и могуч: одна и та же задача может решаться по-разному. За Си мне лень было браться и я написал недостающую мне часть на BASH, ибо строк получилось не так уж и много. Без установленной sensors мой скрипт работать не будет. Фиксацию троттлинга естесственно не стал писать — его и так будет видно по сбросу частоты и температуре. Вот сам скрипт:
Сильно не ругайте за скидывание управляющих символов в stderr (1>&2), но это дело привычки, если вдруг потом вывод скрипта в файл отправлять, а там все эти ESC-апе последовательности точно не нужны, вот так и будет терминал цветным, а файл чистым. Что-то я отвлёкся.
Я создал файл chk в директории с linpack-ом и записал скрипт в него, Вы можете сделать тоже самое, за исключением xed, если у Вас его нет:
И собственно то, ради чего всё затевалось — тест Linpack cо скриптом:
./chk ./xlinpack_xeon64 -i ./my_test
Да, я вижу, одно ядро нагрелось до критического TDP в 105°C за 86 секунд, но это мне ни о чём не говорит, а вот то, что с 50°C до 80°C процессор нагревается за 2 секунды — это уже показатель: термопасту точно пора менять — два года не менял, а вот с системой охлаждения останется вопрос, который проявят тесты после замены термопасты и термопроводящих прокладок на моём ноутбуке.
Почему именно 80°C я взял за отправную точку? Да просто потому, что именно эта температура заложена в BIOS, как температуры начала скидывания частот, да ещё и начало включения кулера выставлена в 55°C в угоду энергосбережению, но BIOS — InsydeH20, да ещё и с проверкой своей хэш-суммы и белым списком девайсов — та ещё головная боль. будет программатор — займусь им вплотную.
Скрипт писал на скорую руку и с ориентиром на Linpack, но он так же свободно работает и с другими консольными утилитами. Вот запуск с вышеизложенным sysbench:
./chk sysbench —num-threads=4 —test=cpu —cpu-max-prime=100000 run
Как видно из скриншота sysbench не даёт полную нагрузку на процессор, в отличии от Linpack-а.
Вот запуск с утилитой stress (подробнее про stress — здесь):
./chk stress —cpu 16
Естественно выход/окончание теста с утилитой stress осуществляется вручную по CTRL+C, отсюда и Error: 1 выведенная моей переменной PS1 из-за подобной реализации выхода из скрипта через exit 1.
Скрипт можно запустить и без опций, но тогда он только температуру и частоты в почти реальном времени показывает:
В любом случае выход из скрипта осуществляется автоматически, по окончании теста или можно выйти, нажав CTRL + C:
В общем: поставленную для себя задачу я решил и даже лучше — появилась целая надстройка над тестовыми утилитами. Осталось ноутбук разобрать и поменять таки термопасту с прокладками: как вспомню — аж страшно становится.
Источник