Избавляемся от кипятильника: 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

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

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

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

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