Стресс тест процессора в 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:
В общем: поставленную для себя задачу я решил и даже лучше — появилась целая надстройка над тестовыми утилитами. Осталось ноутбук разобрать и поменять таки термопасту с прокладками: как вспомню — аж страшно становится.
Источник
Загрузка процессора 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 с помощью различных утилит. Как системных, так и сторонних. А какие утилиты для таких целей используете вы? Напишите в комментариях!
Источник
Как загрузить процессор на 100% в linux?
md5sum /dev/urandom — Single thread CPU test
stress —cpu 4 —timeout 300s — Multi threadCPU test
cat /dev/zero | bzip2 -c > /dev/null — CPU Stress Test
cat /dev/sda3 | pipebench -q > /dev/null — RAW Read Speed Test
dd bs=16k count=102400 oflag=direct if=/dev/zero of=test_data — Write Test
dd bs=16K count=102400 iflag=direct if=test_data of=/dev/null — Read Test
while true в несколько потоков без задержки — хана процу
Диск еще проще читай из /dev/urandom в несколько потоков и пиши на это диск потом с него же читай в /dev/null — хана диску
Да и память туда же уйдет
Для дисков еще dd неплох
Эммм , что вы имеете в виду под хана ? VPS может уйти в даун ?
Мне нужно на пару минут протестить.
Если есть возможность , то по подробней, нужно скриптяру написать ?
Напишите пример ?
Дико тупая хрень но должно работать (не проверял 🙂 )
Источник
