Стресс тесты для линукс

Стресс-тестирование систем в Linux – утилита stress-ng

Для организации и проведения нагрузочного стресс-тестирования в Linux-системах существует утилита stress-ng. С помощью неё несложно сгенерировать реальную рабочую нагрузку на тестируемые подсистемы и, соответственно, оценить её возможности. Утилита, традиционно для Linux, предоставляет для работы интерфейс командной строки. Однако, это ни в коей мере не делает её неудобной. Со своими задачами она справляется на «отлично». В данной статье приведены инструкции, отражающие основы работы с утилитой stress-ng для некоторых самых распространённых ситуаций в стресс-тестировании систем на основе Linux.

Основные особенности и возможности stress-ng

Возможности, которыми обладает утилита stress-ng, довольно широки. Об этом свидетельствует огромное количество всевозможных опций, которыми её наделили разработчики.
Но ключевой особенностью stress-ng является то, что это полноценный инструмент со встроенными тестами. В отличие от многих других аналогов, при выполнении теста не производится обращений к сторонним и/или внешним ресурсам. Таким образом, stress-ng абсолютно самодостаточна. Практически в любом дистрибутиве Linux она доступна в стандартном репозитории и устанавливается с помощью системы управления пакетами (СУП) дистрибутива. Например, в Ubuntu:

Кроме всего прочего, stress-ng в своём составе очень качественные тесты для тестирования процессоров, в совокупности позволяющие наиболее полно сгенерировать нагрузку на CPU, используя такие методы как целочисленные и с плавающей запятой, битовые операции, комплексные вычисления и т. д.

Синтаксис stress-ng

Как уже было отмечено, stress-ng имеет настолько огромный набор опций, что в рамках данной статьи целесообразнее остановиться лишь на основных, позволяющих протестировать все основные подсистемы: CPU, виртуальную память, а также дисковую подсистему.
Синтаксис stress-ng довольно прост:

Задаёт конкретный метод тестирования виртуальной памяти. По-умолчанию выполняются все доступные для данной категории тесты, последовательно друг за другом. Подробнее в официальном руководстве по команде man stress-ng.

—vm-method mЗадаёт конкретный метод тестирования виртуальной памяти. По-умолчанию выполняются все доступные для данной категории тесты, последовательно друг за другом. Подробнее в официальном руководстве по команде man stress-ng.

Основные опции stress-ng

В таблице ниже указаны основные опции утилиты

Опция	Значение
—class name	Задаёт тип теста. В качестве name указывается например cpu, memory, vm, io и другие.
—metrics	Указывает, что по завершению теста должна быть выведена статистика основных метрик, отражающих поведение системы во время теста.
—metrics-brief	То же, что и —metrics, но выводит ненулевые метрики.
—cpu-method method	Задаёт метод генерации нагрузки для процессора. По-умолчанию выполняются все доступные для данной категории тесты, последовательно друг за другом. Более подробно об этой опции можно узнать, выполнив команду man stress-ng.
—cpu N	Запускает для стресс-теста процессора N стрессоров для каждого его потока.
—cpu-ops N	Указывает, через какое количество bogo-операций необходимо остановить тест CPU.
—hdd-ops N	Указывает, через какое количество bogo-операций необходимо остановить тест жёстких дисков.
—hdd-bytes N	Записывает N байт для каждого процесса работы с жёстким диском. По-умолчанию равно 1 Гб.
—vm N	Запускает для стресс-теста виртуальной памяти N стрессоров.
—vm-bytes N	Размещает N байт для каждого процесса работы с памятью. По-умолчанию равно 256 Мб. Объём также может быть указан в процентах от общего объёма виртуальной памяти в системе. Значения можно задавать в бфйтах, килобайтах, мегабайтах и гигабайтах, используя суффиксы b, k, m и g соответственно.
—sequential N	Задает N количество потоков для выполнения тестов, если N не указано или равно 0, то количество потоков равно числу процессоров.

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

• что бы запустить несколько экземпляров каждого стресс-теста используется опция —all N, где N – необходимое количество экземпляров;
• для установки таймаута, т. е. времени продолжительности стресс-теста используется опция —timeout.

Тестирование процессора

Для подавляющего большинства ситуаций классическим примером стресс-теста можно использовать тест, выполняемый следующей командой:

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

Естественно количество потоков следует задавать в соответствии со спецификацией используемого процессора.

Тестирование дисковой подсистемы

Для проведения стресс-тестирования накопителей, таких как жёсткие диски можно для начала провести низкоуровневый тест ввода вывода

Вывод команды будет следующим

Еще один стресс-тест дисков можно выполнить командой

В данном случае будет запущено 5 стрессоров для жёстких дисков, которые будут остановлены по завершении 100 тыс. bogo-операций.

Во время тестирования можно смотреть загрузку командой iostat

Тестирование памяти

Что бы провести стресс-тест памяти используйте команду

После окончания мы получим результат проверки приблизительно следующего вида

Комплексное тестирование

Если необходимо провести комплексное стресс-тестирование, можно задействовать работу нескольких основных подсистем вместе одной командой:

Эта команда запустит тест для CPU в 8 потоков, тест виртуальной памяти с размещением в ней одного гигабайта данных, а также 4 стрессора для тестирования операций ввода/вывода.

Что бы запустить тестирование всего «железа», используется команда

Эта команда запустит все тесты. После выполнения результат будет выведен в консоль. Во время выполнения команды лучше компьютер не трогать

Заключение

В заключение стоит ещё раз отметить, что утилита stress-ng по своим возможностям очень универсальна и позволяет качественно протестировать любую систему. Приведенные выше примеры охватывают наиболее распространённые ситуации по нагрузочному тестированию Linux-систем. Для проведения специфичных или более сложных тестов рекомендуется обращаться к официальному руководству по использованию утилиты, доступному по команде man stress-ng.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

ИТ База знаний

Курс по Asterisk

Полезно

— Узнать IP — адрес компьютера в интернете

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Калькулятор инсталляции IP — АТС Asterisk

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Как провести стресс-тестирование вашей системы Linux

4 минуты чтения

Повышение нагрузки на серверы Linux может быть хорошей идеей, если вы хотите увидеть, насколько хорошо они работают, когда они загружены. В этой статье мы рассмотрим некоторые инструменты, которые помогут вам нагрузить сервер и оценить результаты.

Для чего вам необходимо подвергать свою систему Linux нагрузке? Потому что иногда вам может потребоваться узнать, как система будет вести себя, когда она находится под большим давлением из-за большого количества запущенных процессов, интенсивного сетевого трафика, чрезмерного использования памяти и т. д. Этот вид тестирования позволяет убедиться, что система готова к использованию.

Мини — курс по виртуализации

Знакомство с VMware vSphere 7 и технологией виртуализации в авторском мини — курсе от Михаила Якобсена

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

К счастью для тех, кому нужно знать, как система Linux отреагирует на нагрузку, есть несколько полезных методов, которые вы можете использовать, и есть инструменты, которые вы можете использовать, чтобы упростить этот процесс. В этой статье мы рассмотрим несколько вариантов.

Создаем циклы своими руками

Данный первый метод предполагает запуск некоторых циклов в командной строке и наблюдение за тем, как они влияют на систему. Этот метод нагружает ЦП, значительно увеличивая нагрузку. Результаты можно легко увидеть с помощью команды uptime или аналогичных команд.

В приведенной ниже примере мы начинаем четыре бесконечных цикла. Вы можете увеличить количество циклов, добавляя цифры или используя выражение bash , например <1..6>вместо «1 2 3 4».

В примере выше, команда, запускает четыре бесконечных цикла в фоновом режиме.

В этом случае были запущены задания 1-4. Отображаются как номера заданий, так и идентификаторы процессов.

Чтобы увидеть влияние на средние значения нагрузки, используйте команду, подобную показанной ниже. В этом случае команда uptime запускается каждые 30 секунд:

Если вы собираетесь периодически запускать подобные тесты, вы можете поместить команду цикла в скрипт:

В выходных данных вы можете увидеть, как средние значения нагрузки увеличиваются, а затем снова начинают снижаться после завершения циклов.

Поскольку показанные нагрузки представляют собой средние значения за 1, 5 и 15 минут, потребуется некоторое время, чтобы значения вернулись к нормальным для системы значениям.

Чтобы остановить циклы, выполните команду kill , подобную приведенной ниже — при условии, что номера заданий равны 1-4, как было показано ранее в этой статье. Если вы не уверены, используйте команду jobs , чтобы проверить ID.

Специализированные инструменты для добавления нагрузки

Другой способ создать системный стресс — это использовать инструмент, специально созданный для того, чтобы нагружать систему за вас. Один из них называется stress и может воздействовать на систему разными способами. Стресс-инструмент — это генератор рабочей нагрузки, который обеспечивает стресс-тесты ЦП, памяти и I/O.

С параметром —cpu команда stress использует функцию извлечения квадратного корня, чтобы заставить ЦП усердно работать. Чем больше указано количество ЦП, тем быстрее будет нарастать нагрузка.

Второй сценарий watch-it (watch-it-2) может использоваться для оценки влияния на использование системной памяти. Обратите внимание, что он использует команду free , чтобы увидеть эффект стресса.

Начало и наблюдение за стрессом:

Чем больше ЦП указано в командной строке, тем быстрее будет нарастать нагрузка.

Команда stress также может вызвать нагрузку на систему, добавив I/O и загрузку памяти с помощью параметров —io (input/output) и —vm (memory).

В следующем примере выполняется команда для добавления нагрузки на память, а затем запускается сценарий watch-it-2 :

Другой вариант для стресса — использовать параметр —io , чтобы добавить в систему действия по вводу/выводу. В этом случае вы должны использовать такую команду:

После чего вы можете наблюдать за стрессовым I/O с помощью iotop . Обратите внимание, что iotop требует привилегий root .

stress — это лишь один из множества инструментов для добавления нагрузки в систему.

Мини — курс по виртуализации

Знакомство с VMware vSphere 7 и технологией виртуализации в авторском мини — курсе от Михаила Якобсена

Источник

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

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

Источник