Sysbench тест производительности linux

Программы для бенчмарка CPU в Linux

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

Бенчмарк и стресс-тест это не одно и то же. И при бенчмарке и при стресс-тесте система получает полную нагрузку. Но главная цель бенчмаркинга это оценка производительности, а главная цель стресс-теста это проверка, сможет ли система функционировать на пределе своей загруженности, либо определить этот предел. Хотя, на самом деле, некоторые программы совмещают в себе обе функции.

Бенчмарк может выполняться дли системы в целом, либо для отдельных её составляющих: для центрального процессора, видеокарты, системы ввода-вывода.

В Линукс имеется несколько программ для оценки производительности центрального процессора, например: sysbench, stress-ng и phoronix-test-suite. Из них stress-ng в первую очередь выполняет функции стресс-теста, но она выводит получаемые метрики, поэтому вполне пригодна для оценки и сравнения производительности системы.

Бенчмарк в sysbench

sysbench — это утилита командной строки. Она создана для оценки производительности серверов с сильно нагруженными СУБД, но подходит и для проведения бенчмарков обычных систем.

Установка в Ubuntu, Linux Mint, Debian, Kali Linux:

Встроенные в программу тесты:

fileio — Тестирование файлового ввода/вывода
cpu — Тестирование производительности CPU
memory — Тестирование скорости функций памяти
threads — Тестирование производительности подсистемы потоков
mutex — тест производительности Mutex

Для запуска теста производительности центрального процессора:

Обратите внимание как запускается программа: в начале идёт название теста, затем опции (в первом примере их нет), а затем команда.

Для программы установлено два придела выполнения:

10000 операций с числами
10 секунд выполнения

В зависимости от того, что наступит первым, программа завершит свою работу или после 10000 событий, либо после 10 секунд.

Современные процессоры очень производительные и если программа завершилась очень быстро, то данные могут быть искажены. Например, при оценки производительности процессора играет роль, к примеру, троттлинг (сброс частот). Троттлинг начинается из-за перегрева или превышения TDP. Эти эффекты наблюдаются только на длительных дистанциях работы процессора. Если, к примеру, тест завершился за секунду и вы получили n обработанных операций, это не означает, что процессор за 60 секунд выполнит 60 * n операций, поскольку он будет сбрасывать частоты из-за перегрева и выхода за пределы установленного в TDP рассеивания тепла.

Для более длительного выполнения теста используются опции —cpu-max-prime и —time. Первая устанавливает максимальное количество выполненных операций, а вторая — максимальное время проведения бенчмарка. При одновременном использовании опций приоритет имеет —time.

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

По умолчанию sysbench запускает в один поток. Поэтому если вы хотите задействовать все ядра вашего процессора, используйте опцию —threads. У меня 6 физических и 12 логических ядер центрального процессора, поэтому я буду использовать значение 12, чтобы работали все процессоры.

При использовании опции —cpu-max-prime, чем меньше время завершения программы, тем производительныее центральный процессор:

Программа завершила работу слишком быстро — за 10 секунд вряд ли процессор успел подвергнуться серьёзному троттлингу. Поэтому с такими значениями тест подходит для оценки пиковой производительности на короткой дистанции.

CPU speed events per second означает количество выполненный в центральном процессоре операций за секунду — чем выше значение, тем производительнее система.

General statistics total time означает общее время выполнения операций.

General statistics total number of events означает общее количество выполненный событий.

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

Ещё один способ проверки троттлинга и оценки производительности процессора под длительной нагрузкой, это установка времени выполнении, в примере ниже установлено время в 300 секунд.

У меня при использовании опций —time и —cpu-max-prime CPU speed events per second различается в десятки раз — видимо или какой-то баг в программе, либо программа считает по каким-то другим правилам.

Бенчмарк в phoronix-test-suite

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

Предыдущая команда выведит список доступных бенчмарков.

Доступные наборы в версии Phoronix Test Suite v8.0.1

Звёздочкой отмечены частично поддерживаемые наборы.

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

Обратите внимание, что pts/cpu и другие бенчмарки занимают несколько гигабайт дискового пространства. К примеру, pts/cpu загрузит около 3 Гб данных и будет использовать примерно 7 Гб дискового пространства (в домашней директории пользователя).

О том, как контролировать текущую частоту и температуру процессора в Linux смотрите здесь.

Источник

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

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

Основная проблема в том, что выполнить оценку производительности сервера нужно быстро, без использования специальных (читай, сложных) инструментов и, разумеется, до релиза. Мы должны уметь снять с сервера некие метрики и, умножив их на известные показатели приложения, получить оценку производительности приложения на этом сервере.

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

В этой статье я хочу рассказать о тех приёмах и инструментах, которые мы используем для оценки производительности сервера.

Типичные ситуации

Команда разработчиков выходит на релиз и скоро готовится выпустить первую версию продукта. Следующий шаг — развернуть приложение на боевом сервере, который по условиям проекта нужно купить и настроить. На общем митинге руководитель проекта предлагает найти ответственного для решения этого «простого» вопросы: «Так, кто подберет хостинг и сервер? Я заложу необходимую сумму в бюджет следующей итерации». Как правило, желающих на эту задачу нет :). Более того, прямое делегирование — «Вася, займись этой задачей!» — тоже не работает: Вася мгновенно находит и перечисляет не менее десятка срочных/важных задач, которые вот прямо сейчас на нем висят и сдать их нужно вчера («и вообще, мы — не админы»). Повинуясь общему чувству самосохранения, команда слаженно подсказывает Руководителю Проекта, где именно нужно поискать такого специалиста (не ближе, чем в соседнем подразделении), и уж вот Он точно подберёт идеальную конфигурацию сервера.

По условиям проекта сервер предоставляет заказчик. Это выглядит как отличное условие на старте проекта, но оно не является таковым, когда мы подходим к релизу. На вопрос клиенту «А сервер-то мощный?» следует неизменный ответ: «А то!». После деплоя Руководитель Проекта грустными глазами смотрит на тайминги откликов веб-приложения. Появляются неприятные мысли «Кто виноват?» и «Что делать?». Приходит понимание того, что конфигурацию сервера нужно было подбирать самим, но, с другой стороны, специалист из соседнего подразделения так и не нашелся. По факту выходит, что этот мощный сервер — дешёвая VPS’ка, параметры которой выглядят хорошо, но она делит ресурсы хоста с армией своих собратьев-соседей. Клиент оплатил сервер на пять лет вперед 🙂 и менять что-либо не собирается (раньше нужно было говорить).

Адвансед-уровень — у клиента есть сервер и админ. Параметры сервера не вызывают нареканий, но после деплоя приложения мы видим страшные тормоза, лаги, задержки. Наш девелоперский сервер по параметрам в три раза слабее, но приложение работает в восемь раз быстрее. Ни одно из наших предложений о замене сервера или покупке нового не принимается, так как у админа свое мнение — тормозит «ваше» приложение. Клиент не знает, кому верить; идея, влекущая новые расходы, ему тоже не нравится, поэтому аргумент админа засчитывается. Руководитель Проекта требует от команды четкого объяснения «почему приложение тормозит» и доказательств с цифрами «вины» сервера. У команды, как всегда, полно свободного времени, поэтому все с удовольствием берутся за решение задачи и ставят пиво специалисту из соседнего отдела за подсказку «куда копать».

Резюмируем, с какими ситуациями мы сталкиваемся и какие задачи нужно уметь решать:

— Подбор сервера под приложение и нагрузку
— Оценка возможностей имеющегося сервера
— Уметь ответить на вопрос «Почему так медленно?»

Требования к инструментам измерения

Наиболее точный способ измерения производительности сервера является одновременно и самым очевидным: нужно установить приложение на сервер и активировать реальную нагрузку. Такой способ хоть и даёт точный результат, но является бесполезным 🙂 по ряду причин:

Мы хотим знать оценку сервера заранее, до запуска в продакшн.
Метод измерения должен быть быстрым и дешёвым.
Инструмент измерения должен быть простым в использовании и установке на сервер.
Результат измерения должен быть легко интерпретируемым и сравниваемым.

Объект измерения

Сервер куплен, операционная система установлена, sshd запущен. Открываем консоль и входим на сервер. Черная консоль, зеленые буквы и мигающий курс немо вопрошают тебя: «Что дальше?». Самое время задуматься, что будем измерять и из чего складывается производительность.

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

От чего в большей степени зависит производительность веб-приложения:

Скорость работы связки CPU + RAM
Скорость дисковой подсистемы
Производительность среды исполнения языка (в нашем случае это PHP)
Настройка базы данных (у нас это MySQL или PostgreSQL)
И, конечно, от самого приложения (от того, какие ресурсы оно использует)

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

для компонентов сервера: CPU+RAM и Дисковая подсистема
для программных компонентов: MySQL и PHP

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

Инструменты измерений

sysbench

Описать инструмент лучше, чем это сделал автор, нельзя, поэтому цитирую:

SysBench is a modular, cross-platform and multi-threaded benchmark tool for evaluating OS parameters that are important for a system running a database under intensive load.
The idea of this benchmark suite is to quickly get an impression about system performance without setting up complex database benchmarks or even without installing a database at all.

Это то, что нужно! Sysbnech позволяет быстро получить представление о производительности системы без установки сложных бенчмарков и специальных инструментов.

Установить sysbench просто:
apt-get install sysbench

Можно скомпилировать:
$ ./autogen.sh

$ ./configure

$ make

Проверяем производительность CPU

Для этого запускаем вычисление двадцати тысяч простых чисел.
$ sysbench —test=cpu —cpu-max-prime=20000 run

По умолчанию вычисление будет выполняться в одном потоке. Используем ключ —num-threads=N, если хотим производить параллельные вычисления.

Результат работы теста:

Самое интересное в этом тесте — это значение total time. Запуская данный тест на нескольких серверах, мы можем сравнивать показания.

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

G2 примерно в три раза быстрее, чем A3
Простая VPS’ка на регру за 250 руб/мес сравнима с G2 🙂
Виртуалка на базе Xeon X3440 отработала так же, как и NUC i5
Удивляет одинаковость результатов на четырех серверах
Возможно, вычисление простых чисел происходит на одних и тех же блоках CPU, которые не отражают общей производительности процессора

Тестируем дисковую подсистему

Проверка дисковой подсистемы выполняется в три шага:

Подготовить (сгенерировать) набор тестовых файлов
Выполнить тестирование, снять показатели
Убрать за собой мусор

Подготовка тестовых файлов:
$ sysbench —test=fileio —file-total-size=70G prepare

Команда создаст набор файлов общим размером на 70 гигабайт. Размер должен заметно превосходить объем оперативной памяти, чтобы на результат тестирования не влиял кэш операционной системы.

Выполнение теста:
$ sysbench —test=fileio —file-total-size=70G —file-test-mode=rndrw —init-rng=on —max-time=300 —max-requests=0 run

Будет произведен тест в режиме случайного чтения (rndw) в течение 300 секунд, после чего будут показаны итоги. Опять таки, по умолчанию тестирование будет выполняться в одном потоке (Number of threads: 1).

Очистка временных файлов:
$ sysbench —test=fileio cleanup

Пример результат выполнения теста:

В качестве меры производительности дисковой подсистемы можно использовать значение средней скорости передачи данных (в данном примере это 21.659Mb/sec).

Посмотрим, что показал этот тест на моих серверах:

Бросаются в глаза подозрительно низкие значения скорости на всех испытанных серверах
На NUC i5 установлен ssd диск, сколько бы раз я не запускал тест, значение скорости передачи данных всегда было в интервале от 1.5 до 2 Mb/sec
На моем рабочем MacBook Pro 2015 с ssd значение скорости в этом тесте равно 140Mb/sec 😎

Тест MySQL OLTP

Тест проверяет скорость выполнения транзакций MySQL сервера, причем каждая транзакция состоит как из запросов на чтение, так и на запись.

Очень удобно изменять параметры сервера в my.cnf, перезапускать его и прогонять серию тестов, — сразу видно, как меняется производительность.

Подготовка к тестированию:
$ sysbench —test=oltp —oltp-table-size=1000000 —mysql-db=test —mysql-user=root —mysql-password=pass prepare

Запуск теста:
$ sysbench —test=oltp —oltp-table-size=1000000 —mysql-db=test —mysql-user=root —mysql-password=pass —max-time=60 —oltp-read-only=off —max-requests=0 —num-threads=8 run

Параметр —oltp-read-only можно установить в значение on, тогда будут выполняться только запросы на чтение, что позволит оценить скорость работы СУБД в режиме, например, slave-базы.

Результат выполнения теста:

Самый интересный параметр в отчете — это количество транзакций в секунду (transactions per sec).

Как этот тест показал себя на серверах:

На всех серверах конфигурация MySQL была одинаковая
Удивляет отсутствие существенных различий между серверами A3 и G2
NUC i5 сравним с G2

Как измерить производительность PostgreSQL?

К сожалению, инструмент sysbench не имеет встроенных средств для тестирования PostgreSQL. Но это нам совершенно не мешает, так как можно использовать утилиту pgbench.

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

Для создания тестовых данных выполняем команду:
$ pgbench -h localhost -U test_user -i -s 100 test

Выполняем тестирование:
$ pgbench -h localhost -U test_user -t 5000 -c 4 -j 4 test

Ключи команды означают, что 4 клиента будут выполнять 5000 транзакций в 4 потока. В итоге будет выполнено 20000 транзакций.

Самое главное здесь — это tps.

Сравнительных тестов на разных серверах, к сожалению, нет 🙂

А как же производительность PHP?

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

Однако возникают ситуации, когда sysbench показал хороший результат, а php-приложение на этом сервере демонстрирует совершенно посредственные показатели производительности.

Разумеется, на результат оказывают влияние такие параметры, как:

Версия PHP
Наличие акселератора
Как и чем скомпилирован PHP
Какие расширения активированы

Очень хотелось бы иметь инструмент, который бы легко устанавливался и после запуска выдавал понятную метрику производительности текущего PHP на сервере. Причем, хотелось, чтобы на этот инструмент не влияла производительность дисковой подсистемы (или сетевой) — измеряем только работу интерпретатора PHP на связке Процессор+Память.

Простое гугление/размышление привело к мысли, что:

Существующего инструмента нет
Нужно написать свой эталонный алгоритм (скрипт)
В силу неизменности алгоритма получаемые результаты можно сравнивать

Что и было сделано: github.com/florinsky/af-php-bench

Скрипт собран в phar-архив, что заметно облегчает его скачивание и запуск на произвольном сервере.

Минимальная версия PHP для запуска — 5.4.

Для запуска:
$ wget github.com/florinsky/af-php-bench/raw/master/build/phpbm.phar

$ php phpbm.phar

Скрипт выполняет десять тестов, разделенных на три группы:

Первая группа — это общие операции (циклы, rand, создание/удаление объектов)
Вторая группа тестов проверяет строковые функции, implode/explode, вычисление хешей
Третья — работа с массивами
Все измерения выполняются в секундах

Отчет о выполнении теста:

Скрипт позволяет не только оценить общую производительность PHP на данном сервере (total time), но и увидеть, из чего она складывается. Неоднократно видел, что посредственный общий результат складывался только из-за одного теста: где-то это может быть медленная работа генератора случайных чисел, а где-то работа с длинными строками.

На странице результатов (https://github.com/florinsky/af-php-bench/blob/master/RESULTS.md) я записывал получаемые отчеты и группировал их в общую таблицу. Иногда результаты удивляют 🙂

Заключение

Я бы хотел добавить, что указанные выше инструменты позволяют оценить производительность сервера лишь прямо сейчас, в момент замера. Необходимо понимать, что на работу сервера могут оказывать влияние параллельно работающие процессы. И если замер показал вам хороший результат, это не значит, что он будет таким всегда.

Особенно остро эта проблема проявляется, если вы анализируете сервер клиента, который уже эксплуатируется «в полный рост». Вы не знаете, какие cron-задачи выполняются, какие процессы дремлют и ждут своего события, чтобы включить долгий gzip/tar, еще тут работает антивирус/спам-фильтр и десяток виртуалок, в которых происходит загадочное.

Для анализа поведения сервера во времени нам помогают atop и iostat. Копим статистику за несколько дней (или больше), после чего можно её просмотреть.

Запись данных в файл:
$ atop -w /tmp/atop.raw 1 60

Прочитать запись:
atop -r /tmp/atop.raw

iostat

Замер загрузки CPU:
$ iostat -c 1

Замер загрузки дисковой подсистемы:
$ iostat -xd /dev/sda 1

И, разумеется, можно использовать Munin и ему подобные, чтобы собирать статистику с сервера в длинном хронологическом порядке.