CPU стресс-тест в Linux, как нагрузить все ядра микропроцессора
Иногда возникает необходимость выполнить частичную или полную загрузку микропроцессора на персональном компьютере или сервере. Это может понадобиться для стресс-тест системы, для проверки стабильности работы, оценки эффективности системы охлаждения и измерения потребляемой компьютером или сервером мощности под нагрузкой.
В статье приведены конструкции из простых и всегда доступных консольных команд в GNU Linux, которыми можно нагрузить одно или все ядра процессора. Также рассмотрим компактный но очень мощный пакет для стресс-тестов под Линукс, который можно установить одной командой. Все подробно и с примерами!
Утилизация мощности двух ядер CPU (40%+70%)
Опытный пользователь операционной системы (ОС) GNU Linux не раз сталкивался со случаями когда простая команда с небольшой ошибкой могла загрузить микропроцессор под самую завязку. Этим мы и воспользуемся, только у нас будет все продумано и с конкретной целью.
Сперва рассмотри достаточно интересную связку из двух отдельных команд, соединенных через конвейер (символ «|», перенаправление ввода-вывода).
Ее суть: читаем случайные данные из файла «/dev/urandom» используя утилитку ‘dd’, через конвейер «|» перебрасываем эти считанные данные программе-архиватору «bzip2», указываем максимальный уровень сжатия (9) и выводим данный в «черную дыру», то есть в никуда — для этого есть специальный файл «/dev/null».
Таким образом, пока команда запущена (прервать ее можно нажав CTRL+C), архиватор будет сжимать непрерывный поток случайных данных и пересылать результат в вечно пустой файл. На физические диски и файловые системы ничего не пишется, а процессору есть немало работы.
Данная связка из команд загрузит два ядра CPU (Central Processor Unit) таким образом:
- «dd if/dev/urandom» — загрузит одно ядро примерно на 40%;
- «bzip2 -9» — загрузит второе ядро примерно на 70%.
Для чтобы загрузить дополнительные ядра микропроцессора нужно открыть дополнительные окна терминала и запустить несколько клонов данной команды.
Наблюдаем за нагрузкой отдельных ядер CPU
Для удобного наблюдения за нагрузкой на каждое из ядер микропроцессора можно использовать программу «System Monitor», которая входит в состав рабочего окружения KDE. Программа с похожим функционалом и таким же названием есть и в среде GNOME.
Рис. 1. Мониторим загрузку двух ядер CPU в GNU Linux используя System Monitor из KDE.
На рисунке результат загрузки двух ядер связкой из двух команд которая были рассмотрена выше. Одно ядро — оранжевй график (70%), другое ядро — желтый график (40%).
С такой же задачей, только в консоли, отлично справляется утилита «htop», которая должна быть знакома почти каждому системному администратору. Если у вас она не установлена то исправить ситуацию можно командой:
Для запуска этого консольного монитора ресурсов используем одноименную команду:
Ниже приведен пример работы этого консольного монитора ресурсов, загружены два ядра все той же связкой из команд dd и bzip2.
Рис. 2. Мониторинг нагрузки двух ядер CPU в GNU Linux используя HTOP.
Что же означают в HTOP красные и зеленые отметки в прогресс-барах для ядер CPU? — все проще простого:
- зеленый цвет — количество ресурсов процессора, выделенные под процессы с нормальным приоритетом;
- красный цвет — ресурсы CPU, выделяемые процессам с приоритетом ядра.
О том как узнать частоту установленного микропроцессора(ров), режимы работы ядер и другую полезную информацию я писал в одной их предыдущих статей о CPU в GNU Linux.
Утилизация 100% мощности одного или нескольких ядер CPU
Для этой цели можно использовать команды, которые обрабатывают непрерывный поток данных на очень высокой скорости, без периодических колебаний нагрузки как в случае с bzip.
Скажем микропроцессору «yes». только очень много раз!
С виду простая и безобидная команда, а нагрузит она одно ядро CPU примерно на 100% и без скачков. Суть этой конструкции проста: выводим слово «yes» бесконечное количество раз и перенаправляем вывод в «черную дыру» — /dev/null.
Рис. 3. Нагружаем одно ядро CPU на 100% командой yes в GNU Linux.
Другие связки из простых команд для загрузки ЦПУ
Пример с командой «yes» — это наиболее простой и доступный способ нагрузить одно или несколько ядер центрального процессора.
Кроме того, можно поэкспериментировать и с другими командами и программами, которые по умолчанию доступны почти в каждом дистрибутиве GNU Linux.
Суть построения подобных связок из команд следующая:
- Что-то откуда-то беспрерывно считываем и перенаправляем в /dev/null;
- Выполняем бесконечный анализ данных какой-то программой или утилитой.
Следующая связка позволяет загрузить одно ядро под самый потолок:
Рис. 4. Нагружаем одно ядро CPU по максимуму на 100% командой cat в GNU Linux.
Суть команды: при помощи команды «cat» выполняем вывод бесконечного потока дынных из псевдо-устройства «/dev/zero» (генерирует нули, 000) в пустоту «/dev/null»;
Как видим процесс у нас выполняется с высоким приоритетом (приоритет ядра ОС) и требует для выполнения всю вычислительную мощность одного процессорного ядра.
Для считывания данных из файла псевдо-устройства можно использовать программу «dd».
Суть команды: с помощью программы «dd» (if — input file, of — output file) читаем поток случайных данных из /dev/urandom и отправляем их в «никуда» — /dev/null.
Результат мониторинга загрузки ядер в HTOP получим такой же как и на рисунке 4.
А теперь загрузим процессор подсчетом контрольной суммы бесконечного файла с нулями:
В htop мы сможем видеть то же то и на рисунке 3, правда плотность загрузки будет более стабильной.
Грузим CPU просчитывая MD5-сумму бесконечного потока случайных данных:
График загрузки будет идентичен тому что на рисунке 4, микропроцессор загружен процессом, который работает на уровне ядра ОС, очень высокий приоритет.
Грузим процессор на 100% используя pbzip2
В начале статьи был представлен пример с bzip2, которая поотдельности может нагрузит одно ядро микропроцессора. Существует также мультипоточная реализация данного архиватора — pbzip2.
Установить pbzip2 можно командой:
Для нагрузки всех доступных ресурсов процессора достаточно запустить следующую команду:
Вместо источника потока «/dev/zero» можно использовать «/dev/urandom» или же собрать еще более простую конструкцию:
Stress — пакет комплексных нагрузочных тестов ПК
О применении утилиты «stress» в GNU Linux я уже писал в статье о самостоятельном ремонте ПК. Там она использовалась в связке с другими программами для получения такого себе нагрузочного стресс-набора на подобии AIDA64 под Windows.
Этой программой можно нагрузить сразу все доступные ядра CPU или же указать конкретно сколько ядер должны трудиться в поте лица. Для установки пакета ‘stress’ достаточно выполнить команду:
Итак, запускаем программу с указанием загрузить 4 ядра микропроцессора:
Результаты производительности приведены ниже.
Рис. 5. Нагружаем все ядра CPU по максимуму на 100% командой stress в GNU Linux.
Рис. 6. Смотрим результат работы программы stress в htop.
В заключение
Как видим, нагрузить отдельное ядро процессора или же несколько ядер без установки специального программного обеспечения в GNU Linux — задача достаточно простая. Каждый может выбрать себе связку команд, которую легко запомнить и использовать, к тому же зная принцип работы строить подобные связки самостоятельно можно буквально на лету.
Тем не менее, установив программу «stress» можно решить задачу комплексно и с дополнительными возможностями. Также для нагрузки и тестов можно использовать такой пакет программ как «phoronix-test-suite», но это уже отдельная история.
Стресс тест процессора в 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 — здесь):
Естественно выход/окончание теста с утилитой stress осуществляется вручную по CTRL+C, отсюда и Error: 1 выведенная моей переменной PS1 из-за подобной реализации выхода из скрипта через exit 1.
Скрипт можно запустить и без опций, но тогда он только температуру и частоты в почти реальном времени показывает:
В любом случае выход из скрипта осуществляется автоматически, по окончании теста или можно выйти, нажав CTRL + C:
В общем: поставленную для себя задачу я решил и даже лучше — появилась целая надстройка над тестовыми утилитами. Осталось ноутбук разобрать и поменять таки термопасту с прокладками: как вспомню — аж страшно становится.