Linux cpu load test

Загрузка процессора 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-серверов: 5 открытых инструментов

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

В список вошли утилиты, предлагаемые резидентами GitHub и участниками тематических тредов на Reddit, — Sysbench, UnixBench, Phoronix Test Suite, Vdbench и IOzone.

/ Unsplash / Veri Ivanova

Sysbench

Это — утилита для нагрузочного тестирования MySQL-серверов, основанная на проекте LuaJIT, в рамках которого разрабатывается виртуальная машина для языка Lua. Автор инструмента — программист и эксперт по MySQL Алексей Копытов. Проект начинался как хобби, но со временем обрел признание сообщества. Сегодня sysbench используют в своей работе крупные университеты и ИТ-организации вроде IEEE.

Во время конференции SECR-2017 (запись выступления есть на YouTube) Алексей рассказал, что sysbench позволяет оценить производительность базы данных при переносе на новое оборудование, обновлении версии СУБД или резком изменении числа запросов. В общем случае синтаксис команды для проведения теста выглядит следующим образом:

Эта команда определяет тип (cpu, memory, fileio) и параметры нагрузочного теста (количество потоков, число запросов, скорость обработки транзакций). В целом инструмент способен обрабатывать миллионы событий за секунду. Подробнее об архитектуре и внутреннем устройстве sysbench Алексей Копытов рассказал в одном из выпусков подкаста Software Development Podcast.

UnixBench

Набор инструментов для оценки производительности Unix-систем. Его представили инженеры из университета Монаша в 1983 году. С того момента поддержкой инструмента занималось множество людей, например, авторы журнала о микрокомпьютерных технологиях Byte Magazine и участник LKML Дэвид Ниеми (David Niemi). За выход следующей версии инструмента отвечает Энтони Воэлм (Anthony Voellm) из Microsoft.

UnixBench представляет собой набор индивидуальных тестов. Они сопоставляют скорость выполнения кода на машине под управлением Unix с производительностью эталонной системы, в роли которой выступает SPARCstation 20-61. На основе этого сравнения генерируется балл, определяющий производительность.

Среди доступных тестов числятся: Whetstone, который описывает эффективность операций с плавающей точкой, File Copy, оценивающий скорость копирования данных, и несколько 2D и 3D-бенчмарков. Полный список тестов можно найти в репозитории на GitHub. Многие из них используют для оценки производительность виртуальных машин в облаке.

Phoronix Test Suite

Этот комплекс тестов разработан авторами веб-ресурса Phoronix, на котором публикуются новости о дистрибутивах GNU/Linux. Впервые Test Suite представили в 2008 году — тогда он включал 23 различных теста. Позже разработчики запустили облачный сервис OpenBenchmarking.org, на котором пользователи могли публиковать собственные тестовые сценарии. Сегодня на нем представлено около 60 бенчмарк-наборов, в том числе связанных с машинным обучением и технологией ray-tracing.

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

Во время тестирования Test Suite самостоятельно контролирует состояние оборудования (температуру CPU и скорость вращения кулеров), защищая систему от перегрева.

/ Unsplash / Jason Chen

Vdbench

Инструмент для генерации I/O-нагрузки на дисковые системы, разработанный Oracle. Он помогает оценить производительность и целостность СХД (о том, как посчитать теоретическую производительность дисковой системы, мы подготовили краткую справку).

Работает решение следующим образом: на реальной системе запускается программа SWAT (Sun StorageTek Workload Analysis Tool), которая создает дамп со всеми обращениями к диску за определённый период. Записываются метка времени, тип операции, адрес и размер блока данных. Далее, используя файл с дампом, vdbench эмулирует нагрузку на любой другой системе.

Список параметров для управления утилитой есть в официальном документе Oracle. Исходный код утилиты можно найти на сайте компании.

IOzone

Консольная утилита для оценки производительности файловых систем. Она определяет скорость чтения, записи и перезаписи файлов. В разработке инструмента приняли участие десятки программистов, но автором его первой версии считается инженер Уильям Норкотт (William Norcott). Разработку поддержали такие компании, как Apple, NetApp и iXsystems.

Для управления потоками и их синхронизации во время тестирования инструмент использует стандарт POSIX Threads. По завершении работы IOzone выдает отчет с результатами или в текстовом формате, или в виде электронной таблицы (Excel). Также инструмент имеет в составе скрипт gengnuplot.sh, который строит по данным таблиц трехмерный график. Примеры таких графиков можно найти в документации к инструменту (стр. 11–17).

IOzone доступен в качестве тестового профайла в уже упомянутом Phoronix Test Suite.

Дополнительное чтение из наших блогов и социальных сетей:

Баг в Linux 5.1 приводил к потере данных — корректирующий патч уже вышел
Есть мнение: технология DANE для браузеров провалилась

Зачем нужен мониторинг?
Резервное копирование файлов: как подстраховаться от потери данных
Как перенести системный жесткий диск в виртуальную машину?

Все говорят об утечках ПД — чем поможет IaaS-провайдер
Короткий ликбез: как устроена ЭЦП
Справочная: как работает закон о персональных данных

Источник

Стресс тест процессора в 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:

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

Источник