Мой домашний сервачок имеет долгую историю. Начиналось все со старого 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 если память не изменяет быстрее.
Собственно, опытом доработки этой шелезяки напильником я и хочу поделиться.
Первое, с чем я столкнулся, это питание. Корейцы по ходу его развели левой пяткой в полнолуние, потому начальные тесты выявили интересную особенность. Если ВНЕЗАПНО загрузить все 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 было нельзя.
Проблема номер два — это разъем питания. Под него у меня были шнурки, но держался он в гнезде хреново, иногда отходил, потому вместе с кондером я туда впаял шнурок с JST. Питать я это хозяйство планировал от ATX блока питания, который до этого питал мой интель атом.
Больше аппаратных проблем не наблюдалось, потому я перешел к настройке софтовой части. Так как жесткий диск теперь был по усб, это не могло не сказаться на производительности дисковой подсистемы. Самый простой тест показал:
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
почему именно ab а не siege?
@domov0y: был на слуху
Ты хотел сказать, не могло не сказаться
@webconn: Спасибо, починил.