Меню Рубрики

Cpu linux stress test

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.

Суть построения подобных связок из команд следующая:

  1. Что-то откуда-то беспрерывно считываем и перенаправляем в /dev/null;
  2. Выполняем бесконечный анализ данных какой-то программой или утилитой.

Следующая связка позволяет загрузить одно ядро под самый потолок:

Рис. 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:

В общем: поставленную для себя задачу я решил и даже лучше – появилась целая надстройка над тестовыми утилитами. Осталось ноутбук разобрать и поменять таки термопасту с прокладками: как вспомню – аж страшно становится.

Источник


Adblock
detector