Избавляемся от кипятильника: x86 -> armv7l для домашнего сервера

Мой домашний сервачок имеет долгую историю. Начиналось все со старого Pentium 4, с 20GB HDD и FreeBSD 6.2 в далеком… Какой это год-то был?
Так или иначе, после нескольких лет работы, трижды паянная материнка была отправлена в шкаф к прочему хламу, и была заменена на свеженький тогда intel atom D410, фряху где-то в районе 7 с чем-то заменил linux, сначала debian, потом agilia, потом арч. В общем сервер был хороший, тихий, не пытающийся взлететь на вентиляторах. И в общем-то хватало, у меня же тут чай не вебсервис на овер 9000 хитов в минуту.
В общем, жило это себе тихо мирно, иногда падало под HAD-эффектом, но хватало.
Теперь, же пришла мне в голову мысля выпилить этот тормозной кипятильник по имени x86, и поставить что-то на armv7l. Плюсы на лицо:

  • Жрет 10 ватт в пике
  • Пассивное охлаждение
  • Реактивный eMMC для системы
  • 4 ядра
  • Есть всегда терминал на последовательный порт — в случае факапа не надо тащить в, пардон, туалет (да, там у меня серверная) монитор, или изымать оборудование оттуда. К бивису на дешевых материнках по уарту не достучишься.

Итак, железкой был выбран ODROID-X2 на самсунговском Exynos4412 Prime, как нечто самое оптимальное. ODROID-U2 мне не понравился тем, что NAND впаян, eMMC как-то проще заменить, да и eMMC если память не изменяет быстрее.

IMG_20130521_133759

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

IMG_20130516_104144

Первое, с чем я столкнулся, это питание. Корейцы по ходу его развели левой пяткой в полнолуние, потому начальные тесты выявили интересную особенность. Если ВНЕЗАПНО загрузить все 4 ядра, то от просадки напруги отваливается в биореактор все, что сидит на USB. HSIC. LAN95x тупо ресетится. Самый простой тест который это демонстрирует см. в листинге ниже:

#!/bin/bash
cat /dev/urandom > /dev/null&
cat /dev/urandom > /dev/null&
cat /dev/urandom > /dev/null&
cat /dev/urandom > /dev/null&

 

Потыркавшись осциллом минут пять, да почесав свой мыслительный орган я сварганил вот такой вот воркэраунд — посадил бочку в 4700uF на вход питания. Да, оверкилл, но зато действенно. Там как раз есть тестовая дырка и земля на плате (см. рисунок), между которыми оно отлично садится. Больше просадок питания я не наблюдал, даже когда втыкал в USB на горячую жесткие диски, которые при раскрутке жрут резко и много. До этого такого сделать не отресетив все, что сидит на HSIC было нельзя.

odroid_power

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

IMG_20130521_133914

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

HDD подключенный по USB:

necromant@fireblade:~$ sudo dd if=/dev/sda of=/dev/null
1198177+0 records in
1198176+0 records out
613466112 bytes (613 MB) copied, 31.2201 s, 19.6 MB/s

Упс, забыл отключить usb storage verbose debug в ядре.

necromant@fireblade:~$ sudo dd if=/dev/sda of=/dev/null 
1975674+0 records in
1975673+0 records out
1011544576 bytes (1.0 GB) copied, 46.847 s, 21.6 MB/s

SD карта:

necromant@fireblade:~$ sudo dd if=/dev/mmcblk0 of=/dev/null 
258017+0 records in
258016+0 records out
132104192 bytes (132 MB) copied, 12.2988 s, 10.7 MB/s

eMMC:

necromant@fireblade:~$ sudo dd if=/dev/mmcblk1 of=/dev/null 
718049+0 records in
718048+0 records out
367640576 bytes (368 MB) copied, 11.4995 s, 32.0 MB/s

Это собственно и решило вопрос. eMMC — система, SD — вебстраницы, где важна не столько скорость, сколько высокая скорость случайного доступа, HDD для данных, логов и прочего мусора. Для начала, я прошелся flashbench’ем по eMMC и SD, и форматнул их согласно вот этому туториалу, чтобы продлить их срок службы.
Судя по всему, на eMMC bl1/bl2/tz/uboot зашиты в отдельный раздел, который доступен из юзерспейса только на чтение через /dev/mmcblk1boot0, а на /dev/mmcblk0 хранятся только окружение убута. Исходя из этого, я сделал такую разметку eMMC:

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk1p1            2423        4095         836+  83  Linux
/dev/mmcblk1p2            4096       32767       14336    b  W95 FAT32
/dev/mmcblk1p3           32768    15269887     7618560   83  Linux

Как выяснилось, в убуте поломан к чертям ext2load, ext4load там и не пахнет, ибо убут 2010го года (sic!), а uImage образы не грузятся в принципе — только zImage, только fatload. Надежды грузить всегда свежее ядро по tftp с роутера тоже не оправдались, хардкернель повесили ethernet на HSIC через LAN95x, а не на встроенный в йухунос MII, видимо решили сэкономить на PHY, убут это, разумеется не может. В общем, обычный треш и угар в исполнении наркомано^Wинженеров самсунга. Справедливости ради отмечу, у них концентрация костылей далеко не рекордная. Мой костылеметр показал где-то 0.32 реалтека =)
Итак, первый раздел у меня создан исключительно для быстрого доступа к окружению убута, второй это boot с ядром, третий это корень. Остальное монтируется согласно намеченному плану использования, и особого академического интереса не представляет.
Ethernet тут только 100mbit, которые честно протягивает. Так как сетка дома все равно сотня, да и больше как-то не надо было, этого вполне себе хватает.

Наконец, Apache Bench Intel Atom D410 vs Exynos сделанный снаружи. Конфиги вебсервера, php и mysql при этом были полностью идентичны.

Atom D410:

    ab -n 1000 -c 100 http://ncrmnt.org/
    Server Software: awesome
    Server Hostname: ncrmnt.org
    Server Port: 80
    Document Path: /
    Document Length: 37804 bytes
    Concurrency Level: 100
    Time taken for tests: 33.119 seconds
    Complete requests: 1000
    Failed requests: 0
    Write errors: 0
    Total transferred: 38100000 bytes
    HTML transferred: 37804000 bytes
    Requests per second: 30.19 [#/sec] (mean)
    Time per request: 3311.930 [ms] (mean)
    Time per request: 33.119 [ms] (mean, across all concurrent requests)
    Transfer rate: 1123.42 [Kbytes/sec] received
    Connection Times (ms)
     min mean[+/-sd] median max
    Connect: 31 46 90.6 36 2016
    Processing: 202 3110 1081.8 3225 9784
    Waiting: 163 2956 885.8 3167 5907
    Total: 237 3157 1065.2 3261 9819
    Percentage of the requests served within a certain time (ms)
     50% 3261
     66% 3283
     75% 3295
     80% 3307
     90% 3423
     95% 5098
     98% 6112
     99% 6466
     100% 9819 (longest request)

Exynos:

ab -n1000 -c100 http://ncrmnt.org/
Server Software: awesome
Server Hostname: ncrmnt.org
Server Port: 80
Document Path: /
Document Length: 37804 bytes
Concurrency Level: 100
Time taken for tests: 34.914 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 38102552 bytes
HTML transferred: 37804000 bytes
Requests per second: 28.64 [#/sec] (mean)
Time per request: 3491.388 [ms] (mean)
Time per request: 34.914 [ms] (mean, across all concurrent requests)
Transfer rate: 1065.75 [Kbytes/sec] received
Connection Times (ms)
 min mean[+/-sd] median max
Connect: 32 63 192.1 35 3758
Processing: 150 2806 3082.1 1945 30606
Waiting: 78 699 1052.0 292 9206
Total: 184 2869 3098.2 2012 30655
Percentage of the requests served within a certain time (ms)
 50% 2012
 66% 3161
 75% 4218
 80% 4394
 90% 5738
 95% 7662
 98% 10636
 99% 17378
 100% 30655 (longest request)

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

Добавлено: На siege держит стабильно 150 конкаррентов, что пахнет лютой победой.
Да, я готов к HAD-эффекту.

Transactions: 2691 hits
Availability: 100.00 %
Elapsed time: 37.74 secs
Data transferred: 97.58 MB
Response time: 1.53 secs
Transaction rate: 71.30 trans/sec
Throughput: 2.59 MB/sec
Concurrency: 109.01
Successful transactions: 2691
Failed transactions: 0
Longest transaction: 1.79
Shortest transaction: 0.07

4 thoughts on “Избавляемся от кипятильника: x86 -> armv7l для домашнего сервера

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

    Ты хотел сказать, не могло не сказаться

Добавить комментарий

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.