- PVSM.RU - https://www.pvsm.ru -
Одно из преимуществ работы на компанию, занимающуюся производством программ, заключается в том, что вам часто представляется возможность протестировать прототипы нового железа. Однако не в данном случае – я купил себе Raspberry Pi4 потому, что она очень дешёвая!
На Raspberry Pi4 стоит четырёхъядерный ARM Cortex A72, до 4 ГБ памяти и гигабитный порт Ethernet – и всё это всего за $35.
На Raspberry Pi4 есть ОС Raspbian [1] (на основе Debian), и готовая библиотека продуктов, поэтому я вставил в неё SD-карточку, чтобы побыстрее загрузиться. Я искал syslog и заметил, что и ядро, и все пользовательские программы скомплированы как armv7 – то есть, для 32-битной памяти.
Я знаю, что Raspberry Pi4 поддерживает 64 бита, поэтому я не захотел запускать на ней 32-битную ОС. Я взял другую карту памяти и поставил на неё Debian. Debian, не содержащий ничего лишнего, скомпилированный как aarch64 [2] – что означает 64-битную память.
Загрузив 64-битную ОС, я заинтересовался, насколько лучше она работает 32-битной, поэтому провёл несколько тестов.
Первое, что пришло мне в голову, был старый тест drystone, существующий с начала времён. Эту программу написали в 1988 году, и она занимается математическими вычислениями. Она вряд ли способна симулировать современную нагрузку, и мы можем использовать её только для того, чтобы сохранить некую связность со старым железом и программами.
Современное приложение, обрабатывающее цифры, лучше симулировать вычислением хэшей, поэтому я захотел провести тест с SHA1. К сожалению, утилита sha1sum скомпилирована без поддержки libssl или криптографических функций ядра, поэтому мне пришлось компилировать её из исходников.
Чтобы избежать узких мест в I/O, я подсчитываю хэш файла размером 2 Гб с опцией truncate -s 2GB, так что никакого ввода и вывода данных с карты не было:
SHA1 – более реалистичный тест, чем dhrystone, поскольку этот алгоритм используется в большом количестве приложений – торрентах, git, и т.п.
64-битная система обеспечивает доступ к памяти по 8 байт на одно чтение/запись. Я написал простую программу [3], размещающую большой буфер – она его пишет, а потом читает. Чтобы гарантировать реальное выделение памяти [4] я использовал mlock(). В данном тесте объём буфера равен 2 ГБ: буфер в 3 ГБ работал в 64-битном режиме, а в 32-битном выдавал ошибку «недостаточно памяти».
Я обратил внимание на то, что многие пользователи Raspberry Pi4 используют компьютер в качестве медиацентра, поэтому я запустил задачи на кодирование аудио с двумя самыми популярными кодеками.
Я кодировал композицию Pink Floyd «Echoes», потому что это довольно длинный трек, и с него можно получить измеряемые значения. Чтобы избежать I/O задержек, исходник и конечный файл хранились на ramfs:
Ещё один вариант использования Raspberry Pi4 – в качестве VPN или файервола. Не рекомендую использовать такие системы в подобных целях, но у многих людей всё ещё есть медленное подключение к интернету (менее 100 Мб), поэтому они могут не обращать внимания на медленную работу Raspberry Pi4.
Первый вопрос: сколько трафика способна обработать Raspberry Pi4? Нам нужно измерить чистую сетевую мощность компьютера, без ограничений физических интерфейсов, поэтому я запустил сессию iperf3 между двумя контейнерами. Однако контейнеры обмениваются данными через пару veth, а veth ускоряет трафик посредством ложных разгрузок.
Разгрузка подсчёта контрольной суммы IP осуществляется просто отказом от её подсчёта, а разгрузка сегментации TCP – отказом от сегментации и повторной сборки трафика: большой кусок данных на 64К просто передаётся в память как есть.
Чтобы избежать таких моментов, я запретил разгрузку командой
ethtool -K veth0 tx off rx off tso off gro off gso off
Самое быстрое, на что способно сетевое оборудование – отбрасывать часть трафика, а быстрее всего это делать через правило TC. Чтобы не доходить до максимально возможной скорости, я использовал минимальный размер фрейма Ethernet, 64б.
Хотя обе системы не дошли до максимальной скорости передачи (1,5 Мб/с), 64-битно ядро показало чуть большую скорость, чем 32-битное. Если вы хотите использовать Raspberry Pi4 в качестве файервола, обязательно используйте ядро на 64 бита.
Ещё один частый вариант использования Raspberry Pi4 – VPN-сервер, а точнее, OpenVPN. Я же предпочитаю WireGuard, поэтому я проверил обе программы, поскольку они обе отличаются простотой установки:
Как и ожидалось, OpenVPN в 10 раз медленнее WireGuard. Чего не ожидалось, так это того, что OpenVPN работает с одинаковой скоростью на 32 и 64 б. WireGuard почти насыщает гигабитный порт в обоих случаях – возможно, мы достигли предела NIC.
Чтобы узнать, не может ли WireGuard работать ещё быстрее, я провёл ещё один тест с двумя контейнерами, не задействующий физический Ethernety. Единственная проблема была в том, что и клиент, и сервер iperf3 работали на Raspberry Pi4, загружая два ядра.
Как и ожидалось, OpenVPN и 32-битный WireGuard, ограниченный CPU, отработали хуже, а 64-битный WireGuard отработал лучше.
Я часто читаю заявления типа «оно того не стоит», «ты выиграешь несколько миллисекунд», и т.д., просто из-за того, что Raspberry Pi4 не особо мощный компьютер. Это не так! Как знает любой человек, занимающийся встраиваемым оборудованием, на медленном железе оптимизация софта ещё важнее, чем на быстром.
Я уже знал, что 64-битная ОС будет лучше работать на Raspberry Pi4, но я не знал, насколько лучше. Поэтому я провёл все эти тесты. Надеюсь, вам понравилось!
Автор: Вячеслав Голованов
Источник [5]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/odnoplatny-e-komp-yutery/346517
Ссылки в тексте:
[1] Raspbian: https://www.raspberrypi.org/downloads/raspbian/
[2] aarch64: https://ru.wikipedia.org/wiki/ARM_(%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0)
[3] простую программу: https://pastebin.com/ZHyjehtD
[4] реальное выделение памяти: http://engineering.pivotal.io/post/virtual_memory_settings_in_linux_-_the_problem_with_overcommit/
[5] Источник: https://habr.com/ru/post/488120/?utm_source=habrahabr&utm_medium=rss&utm_campaign=488120
Нажмите здесь для печати.