Тестируем ARM платформу Marvel Armada XP как хостинг для Python проекта

Благодаря GlobaTel смог получить на тест один из серверов (модулей) как из этой статьи Сервер на ARM? Made in Russia!. Как вы понимаете хостинг на ARM, а не набившем оскомину x86, это как минимум свежо и возможно будет модно. Спасибо GlobaTel.

В этой заметке я не хочу сильно подымать тему производительности (но она будет), куда интереснее посмотреть насколько безпроблемно заведётся всё ПО моего проекта. Разворачивал я только ПО, базу картинок я никуда не перемещал. Так что под катом anime-pictures.net т.е. nginx, Python+Pylons+SQLAlchemy, PostgreSQL, Memcached, Redis.
Сразу оговорюсь — заметка будет не последней, это только первое впечатление.

Установка

На сервере стоит стабильная Ubuntu 12.04, мой проект так же запущен на этой версии ОС в hetzner, только платформа более стандартная i7-3770 и 32 гигабайта RAM. После удаления и остановки ненужных сервисов стал ставить нужные мне пакеты:

• PostgreSQL: apt-get install и он стоит, никаких проблем. Для начала использовал все настройки по умолчанию (кроме доступа) и минут за 10 развернул дамп базы.
• Memcached, Redis: Всё так же установилось из репозитория без проблем и запустилось, всё аналогично тому как это было на x86.
• Pylons: поставил pip через apt-get и после, уже через pip установил virtualenv, и внутри сделал pip install pylons, который тянет за собой десяток пакетов. Всё прошло идеально, даже то, что требовало gcc (само собой были установлены dev пакеты для python).
• SQLAlchemy: Так получилось что через pip поставил 0.9, 0.8, 0.7 и все ставились великолепно. Но из-за изменения API для postgres.ARRAY пришлось оставить 0.7 .
• Pillow (PIL): Вот тут я думал будут проблемы. Дело в том, что в ubuntu 12.04 идёт устаревшая версия PIL, а не новый форк Pillow. Pillow, это библиотека для работы с изображениями и в ней много C кода и линковки ко всяким libjpeg, libpng… Кроме того, на их сайте они заявляют подержку только 386, amd64 и PPC. Так вот pip install Pillow и всё собирается без каких-либо проблем.
• uwsgi: Это то же специфический проект с кодом на Си. Установка через pip так же прошла идеально.
• nginx: Всё так же без проблем. Настроил и заработало.
• newrelic: Думаю все знают этот хороший сервис для мониторинга системы и приложений. Вот с ним увы не получилось. Свой клиент они распространяют бинарно, а пакеты есть только для i386 и amd64. Написал в тех поддержку и получил более или менее радующий ответ:
  

  Thanks for letting us know about your requirements for ARM support on the Linux server monitor.
  I have added this as a feature request on your behalf. This information you have provided in this ticket will be passed along to the development team.

  
  так что вполне возможно скоро такая поддержка появится.

Производительность

Очень серьёзных замеров я не делал, так как о производительности ARM писали много (в этой статье и на сайте phoronix.com). Производительность маленькая и этого никто не скрывает.
К примеру время рендринга тестовой страницы (одной из страниц с картинкой на сайте) было от 0.200 до 0.230 секунды, а после дополнительной настройки СУБД смог добиться 0.120-0.160 секунды, для сравнения, на i7 страница рендрится где то за 0.050 секунды. Разница в 3-4 раза не кажется страшной.
Дальше я при помощи apache bench протестировал сколько страниц в секунду сможет генерировать сервер. Сразу оговорюсь, я проверял с 4 и с 8 процессами для uwsgi и разницы не было. Так вот, наш 4 ядерный ARM сервер выдавал 20 запросов в секунду, тогда как i7-3770 до 30 запросов в секунду. Это говорит, что где то у меня есть узкое горлышко и я надеюсь его на днях поправить. По моим оценкам, я должен выдавать не меньше 200 запросов в секунду (раньше были такие результаты).

Мысли

1. Не стоит бояться новой архитектуры, как минимум в python всё работает из коробки.
2. Это отличная замена VPS! Чисто по субъективным ощущениям, ARM работает как средний/верхний сегмент VPS. Если вам нужно больше RAM и больше HDD, то сервер на ARM вполне может заменить VPS. Надеюсь цены будут сопоставимыми.
3. Запускать тяжёлые приложения на таких фреймворках как Pylons и Django затея глупая. Так можно делать только если у вас очень маленькое посещение.
4. Для таких серверов идеально подходят асинхронные приложения на Python/Tornado или сразу на C++. Сейчас частенько встречаются конфигурации с Single Page Application, где backend это просто интерфейс к таким быстрым БД как Redis или MongoDB.

На самом деле мне хочется написать небольшое приложение (не сферический бенчмарк в вакууме) на Tornado, специально для этого сервера, и посмотреть на результат. Надеюсь всё получится и я напишу ещё одну заметку на эту тему.

cat /proc/cpuinfo

Processor: Marvell — PJ4Bv7 Processor rev 2 (v7l)
processor: 0
BogoMIPS: 1325.46

processor: 1
BogoMIPS: 1325.46

processor: 2
BogoMIPS: 1325.46

processor: 3
BogoMIPS: 1325.46

Features: swp half thumb fastmult vfp edsp vfpv3 tls
CPU implementer: 0x56
CPU architecture: 7
CPU variant: 0x2
CPU part: 0x584
CPU revision: 2

Hardware: Marvell Armada XP GP Board
Revision: 0000
Serial: 0000000000000000

cat /proc/meminfo

MemTotal: 8019640 kB
MemFree: 4065896 kB
Buffers: 115744 kB
Cached: 3421572 kB
SwapCached: 0 kB
Active: 2119148 kB
Inactive: 1654100 kB
Active(anon): 354668 kB
Inactive(anon): 22808 kB
Active(file): 1764480 kB
Inactive(file): 1631292 kB
Unevictable: 0 kB
Mlocked: 0 kB
HighTotal: 7299036 kB
HighFree: 3635332 kB
LowTotal: 720604 kB
LowFree: 430564 kB
SwapTotal: 16777212 kB
SwapFree: 16777212 kB
Dirty: 48 kB
Writeback: 0 kB
AnonPages: 235956 kB
Mapped: 33484 kB
Shmem: 141548 kB
Slab: 156072 kB
SReclaimable: 92748 kB
SUnreclaim: 63324 kB
KernelStack: 912 kB
PageTables: 2904 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 20787032 kB
Committed_AS: 587816 kB
VmallocTotal: 122880 kB
VmallocUsed: 21376 kB
VmallocChunk: 60648 kB

df -h

Filesystem Size Used Avail Use% Mounted on
/dev/sda2 277G 4.6G 259G 2% /
udev 3.9G 4.0K 3.9G 1% /dev
tmpfs 1.6G 296K 1.6G 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 3.9G 0 3.9G 0% /run/shm
/dev/sda1 1008M 19M 938M 2% /boot