Добрый день, уважаемые читатели. Сегодня мы бы хотели предложить Вам сравнительный анализ VPS и аппаратного сервера, в котором мы рассмотрим как принципиальные отличия так и метрики производительности, которые были получены с помощью системы тестирования производительности sysbench.
Sysbench — стандартная система тестирования производительности, доступная в большинстве дистрибутивов linux и других unix. Sysbench позволяет протестировать производительности процессора, памяти, подсистемы потоков POSIX ОС, а так же MySQL.
В нашем обзоре мы будем тестировать преимущественно MySQL, так как данный тест включает прямо или косвенно остальные тесты.
В качестве подопытных мы используем следующие платформы:
- Vm Standard Instance (4 core/4GB RAM/10GB SSD RAID6), которая по факту выделилась на сервере Dual Xeon 5650/96GB RAM ECC — стоимость 630 рублей;
- Intel Core i5-4430/16GB RAM nonECC/2xSSD Plextor RAID1 — 2300 рублей.
Изначально можно отметить, что тактовая частота Core i5-4430 значительно выше чем Xeon X5650 (3GHz/4c/6MB Cache vs 2.66GHz/6c/12MB Cache). То есть, по частоте получаем преимущество, а по кэшу немного проигрыш (на самом деле тут все достаточно неочевидно, потому что на X5650 имеется HyperThreading, то есть ядер «как бы» 12 и, возможно, что и по кэшу проигрыш небольшой имеется. С платформами разобрались.
Рассмотрим дальнейшие свойства платформ:
| Свойство | Аппаратный сервер | Виртуальный сервер |
| ОС | Ubuntu 14.04 x86_64 | Ubuntu 14.04 x86_64 |
| Гипервизор | KVM | Отсутствует |
| Интерфейс дисков | Virtio/Qcow2/NFS | SATA3 |
| Дисковая подсистема | Adaptec 6405/Intel SSD/RAID5/Ext4 | 2xKingston 120GB SSD/MDADM/RAID1/LVM/Ext4 |
| MySQL | MariaDB 5.5 | MariaDB 5.5 |
Несколько комментариев к табличке.
Производительность
В целом, дисковая подсистема виртуализации (с точки зрения теории массового обслуживания) более производительна, но поскольку она расположена на NFS, да еще и на дисковом устройстве Qcow2, то для каждой виртуальной машины мы получим более низкую производительность, чем для накопителей SSD, присоединенных непосредственно (за счет сетевой задержки, задержки сервиса NFS, задержки гипервизора). Таким образом, виртуальная машина сможет получить меньше IOPS чем аппаратный сервер, но, например, 10 VM получат вместе значительно больше IOPS, чем аппаратный сервер.
MariaDB использована как наш стандарт defacto, который мы уже 2 года используем вместо MySQL, потому что в MariaDB включаются новые возможности, более производительные и надежные движки, а так же лучшая поддержка SSD. В общем, new black.
Надежность
В целом, надежность системы виртуализации сопоставима с надежностью аппаратного сервера, хотя имеются как определенные преимущества так и недостатки:
- Система виртуализации — система массового обслуживания, поэтому на VPS влияют другие VM, однако, самое узкое место — дисковая подсистема, а в нашем облаке, за счет использования аппаратных RAID контроллеров, сети данных 10G и SSD-накопителей данная проблема решена.
- Система виртуализации состоит из нескольких узлов и коммутаторов, соответственно возникает несколько возможных точек отказа, в следствие чего SLA по VPS несколько ниже чем для аппаратных серверов.
- В системе виртуализации происходит автоматический перезапуск VM на другом узле, если узел, на котором она выполняется вышел из строя, это несомненный плюс, поскольку обеспечивает более высокую надежность и автоматизацию.
- В системе виртуализации пользователь может гибко управлять контейнером VM, выбирая необходимую производительность, адекватную требованиям, в случае аппаратного сервера апгрейд — не самая быстрая задача.
- Система виртуализации позволяет легко клонировать, расширять, создавать снимки дисковых устройств, а пользователь не должен самостоятельно следить за состоянием дисковой подсистемы — это делают администраторы облака.
- Аппаратный сервер используется монопольно, а значит пользователь получает более предсказуемое поведение системы и отсутствие конкуренции за ресурсы.
- Мы делаем резервные копии виртуальных машин ежесуточно, поэтому данные VPS являются более защищенными. В случае аппаратного сервера все резервные копии администратор делает самостоятельно.
В целом, мы бы подвели итог таким образом: если вы не собираетесь использовать аппаратуру сервера на 100% (так сказать, выжимать все соки), то выгоднее использовать VPS, в противном случае стоит рассмотреть аппаратный сервер. Кроме того, необходимо учитывать «эластичность» сервиса, то есть то, как меняется нагрузка — это может быть как плавное увеличение-спад в течение суток, так и постоянные значительные хаотические всплески и падения нагрузки. Во втором случае так же желательно выбрать аппаратный сервер.
Теперь, когда мы понимаем перейдем непосредственно к тестам.
Тестирование производительности с помощью Sysbench
Наша задача при проведении тестирования обеспечить такой режим работы MySQL, чтобы мы больше читали данные с дисков, нежели из кэша оперативной памяти ОС, то есть редко попадали на повторные данные, для этого набор данных на диске должен быть достаточно большим. Мы будем использовать 10 млн. записей.
В то же время мы будем работать при тестировании с количеством запросов в 50 тыс. записей из 10 млн., таким образом, это составит ~ 0.5% от всего объема данных.
Будем производить тестирование в 8/16/32/64/128 потоков (одновременных запросов к MySQL). Кстати, MariaDB установлена с настройками по умолчанию, потому что так чаще всего и бывает у клиентов))
Перед проведением каждого теста выполняется последовательность команд, которая сбрасывает все кэши и выполняет рестарт сервера MySQL:
service mysql stop && free && sync && echo 3 > /proc/sys/vm/drop_caches && free &&service mysql start
Итак, заполняем таблицы MySQL:
sysbench --test=oltp --mysql-table-engine=innodb --oltp-table-size=10000000 \\ --mysql-user=root --mysql-password=XXXXXXX --db-driver=mysql --test=oltp prepare
Выполняем тестирование sysbench:
for i in 8 16 32 64 128; do sysbench --num-threads=$i --max-requests=50000 --oltp-table-size=10000000 \\ --mysql-user=root --mysql-password=XXXXXXX --db-driver=mysql --test=oltp run done
Данные тесты выполняются как на VPS, так и на аппаратном сервере. Результаты выполнения сведены в таблице ниже:
| Аппаратный сервер | Виртуальный сервер | |||
| Количество потоков | 95% время вып. (мс) | Среднее время вып. (мс) | 95% время вып. (мс) | Среднее время вып. (мс) |
| 8 | 33,64 | 11,69 | 154,54 | 24,94 |
| 16 | 46,98 | 16,83 | 208,78 | 52,43 |
| 32 | 84,77 | 29,56 | 320,33 | 91,26 |
| 64 | 123,06 | 53,39 | 481,57 | 177,6 |
| 128 | 263,22 | 98,85 | 899,43 | 341,08 |
Данные для времени выполнения 95% запросов так же приведены ниже в чарте:
Как мы можем видеть, начиная с 64 потоков, графики начинают резко загибаться вверх как для аппаратного сервера так и для VPS, причем для VPS больше. Это начинает сказываться перегрузка CPU и дисковой подсистемы (virtio) для VPS. Можно сказать, что до 64 одновременных потоков к СУБД нагрузка растет близко к линейной и нагрузка в 64 потока является критической точкой для обеих этих платформ.
Кроме того, Вы можете наблюдать изначальный проигрыш VPS аппаратной платформе, что вызвано задержкой сети, подсистемы виртуализации, сервиса NFS.
Данные метрики позволяют Вам оценить насколько Вам необходим VPS или аппаратный сервер. Надо отметить, что нагрузка в 64 параллельных запроса к СУБД является достаточно высокой и даже при ней VPS показывает себя достойно, выполняя запрос в 95% случаев в течение 0.5 секунды.
Дополнительно, стоит заметить, что в реальных условиях в дело всегда вступает буферный кэш и специализированные кэши СУБД (настройка), которые позволяют использовать не дисковую подсистему, а оперативную память и демонстрировать существенно большую производительность. Если принять, что допустимое время загрузки страницы составляет до 5 секунд, страница генерируется ~ 5 холодными запросами, и количество одновременных клиентов на сайте не превышает 16 каждую секунду (эта нагрузка является достаточно высокой ~ 100 тыс. просмотров страниц в сутки), то VPS в качестве сервера СУБД полностью Вас устроит.
Необходимо так же помнить, что дополнительная оперативная память на VPS и аппаратном сервере позволит Вам извлечь дополнительную производительность, поскольку Вы получаете возможность избавиться от запросов IO на чтение, сохранив их только для записи.
UPD: Обновление. Добавлен к сравнению сервер I5-4430/16GB/2xSATA