Подключен к комнатам по 3-5 тыс. участников — задержек нет. У меня база данных (Postgres) — вынесена на отдельный сервер — может поэтому я не испытывал проблем. В конфигурации по умолчанию, наверное, будет работать плохо.
Это сообщение трехлетней давности — «Help!!! Synapse eats all my RAM!Synapse's architecture is quite RAM hungry currently — we deliberately cache a lot of recent room data and metadata in RAM in order to speed up common requests.»
Интересно, а способна ли группа этих спутников концентрировать свое излучение на одной конкретной точке в пространстве? Может мы наблюдаем развертывание электромагнитного оружия на орбите? Которое может быть использовано (в том числе хакерами — в случае взлома системы управления спутниками) для уничтожения других спутников / наземных целей?
Наверное придется так и сделать, если начнутся проблемы с производительностью. Пока этого нет — бесшумные мало потребляющие электричество железки мне больше нравятся. Спасибо за комментарии!
Настроен hot standby базы + бэкапы базы + экспорт базы + отдельно делаются резервные копии фронтенда. Основная база передает логи на standby, т.е. имеется вторая база, которая синхронизируется с основной базой, задержка составляет менее секунды. Один раз (спустя примерно месяц после запуска системы), когда файлы основной базы были на MicroSD карте (а не как сейчас, на подключенном внешнем USB диске), начались ошибки в файловой системе, часть файлов основной рабочей базы данных было повреждено.
Активация standby базы и переключение фронтенда на эту базу позволило быстро и без потерь пережить инцидент — все данные были в целости и сохранности в standby базе.
Проявился инцидент (кроме ошибок в логах) следующим образом — 2 пользователя не могли получить сообщение от третьего пользователя — транзакция не могла завершиться commit'ом в базе. Еще раз прочувствовал мощь standby — в standby базу попадают только завершенные транзакции — standby база сохранила свою целостность несмотря на серьезный сбой основной базы.
Пользовался только инструкциями Github, которые находятся в репозитории сервера Synapse (ссылка в начале статьи). Гораздо сложнее было настроить Zabbix, агентов, плагин для мониторинга PostgreSQL и дисков, оповещение о сбоях / проблемах на email / смартфон и т.п. Также несколько раз пришлось переключаться на standby базу PostgreSQL во время миграции с одного мини-сервера на другой.
Платформа сейчас активно развивается, выходят обновления не реже чем раз в месяц. За 3 года многое улучшилось. Как видно, даже такие слабые мини-серверы не нагружены, проблем с производительностью в данный момент нет.
Цены всем известны, Raspberry Pi — $35, ODROID-XU4 — $59. Здесь смысл в количестве устройств, на двух устройствах сложно организовать отказоустойчивую систему.
Нет, не смотрел. Я думаю что 5 устройств на Intel все-таки будут дороже. Все что описано, конечно можно реализовать на одном десктопном компьютере / ноутбуке. В моем случае хотелось, чтобы при выходе из строя любой железки ее функциональность можно было бы перенести на оставшиеся — обеспечить отказоустойчивость.
«Отскоковый тонометр» — несколько лет назад был куплен Icare HOME tonometer — производят в Финляндии. Используется в домашних условиях для самостоятельного измерения внутриглазного давления несколько раз в день. Очень рекомендую, но стоил дорого тогда, около трех тысяч долларов.
Поделюсь своим опытом тестирования похожей (ограниченной) системы. На смартфоне Meizu Pro 5 Ubuntu Edition в chroot установил и запустил БД PostgreSQL + Synapse server (Matrix) + web сервер с Matrix клиентом. Загрузил дамп в PostgreSQL базу смартфона с Production Synapse сервера (там содержатся логины и пароли пользователей). Перевел смартфон в режим точки доступа (отключил все остальные сети), теперь по WiFi подключаются клиенты (ноутбуки, другие смартфоны и т.д.), запускают клиента (через браузер вводят ip точки доступа) и общаются между собой.
Это было сделано в первую же очередь. Установлена Ubuntu на Macbook Pro, загрузка с флешки 128 Gb Sandisk Extreme Pro USB 3. Работает прекрасно — скорость как на SSD, да и у ноута 16 Gb ОЗУ, но, к сожалению, перезагружаться туда-сюда очень неудобно.
Как показывает top, когда экран телефона выключен, работает только 1 (одно) ядро. Остальные 7 CPU отключены. При повышении нагрузки / или при включении экрана смартфона пробуждается 4 или 8 ядер. Вот сейчас пишу этот комментарий, работает одно ядро. Тормозов при наборе текста нет.
Активация standby базы и переключение фронтенда на эту базу позволило быстро и без потерь пережить инцидент — все данные были в целости и сохранности в standby базе.
Проявился инцидент (кроме ошибок в логах) следующим образом — 2 пользователя не могли получить сообщение от третьего пользователя — транзакция не могла завершиться commit'ом в базе. Еще раз прочувствовал мощь standby — в standby базу попадают только завершенные транзакции — standby база сохранила свою целостность несмотря на серьезный сбой основной базы.
Например, ipfs.io/ipfs/QmZBP8s22PydTsfKBfyHPuVb5vYLdMqUXg6BkXocFy42xk или ipfs.express/ipfs/QmZBP8s22PydTsfKBfyHPuVb5vYLdMqUXg6BkXocFy42xk или любой другой из списка
top — 14:57:36 up 10 days, 3:50, 14 users, load average: 10.90, 12.09, 11.92
Tasks: 441 total, 30 running, 410 sleeping, 0 stopped, 0 zombie
%Cpu0: 62.0 us, 23.9 sy, 0.0 ni, 13.5 id, 0.0 wa, 0.0 hi, 0.6 si, 0.0 st
KiB Mem: 3807748 total, 441368 free, 2115268 used, 1251112 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 1412406 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
23633 rp2 20 0 760040 188932 83052 S 16.8 5.0 3:49.85 /usr/lib/chromium-browser/chromium-browser --enable-pinch
2791 rp2 20 0 298096 28208 16392 R 13.6 0.7 0:00.43 /usr/lib/chromium-browser/chromium-browser --type=renderer --enable-pinch --primordial-+
11085 rp2 20 0 160972 67080 43832 S 11.1 1.8 56:56.46 Xtightvnc
Когда все ядра задействованы:
top — 15:04:31 up 10 days, 3:57, 14 users, load average: 11.57, 11.68, 11.77
Tasks: 444 total, 3 running, 441 sleeping, 0 stopped, 0 zombie
%Cpu0: 0.6 us, 88.4 sy, 0.0 ni, 9.4 id, 0.0 wa, 0.0 hi, 1.6 si, 0.0 st
%Cpu1: 2.7 us, 4.1 sy, 0.0 ni, 92.8 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu2: 2.1 us, 2.1 sy, 0.0 ni, 95.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu3: 3.5 us, 1.7 sy, 0.0 ni, 94.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu4: 6.8 us, 10.8 sy, 0.0 ni, 82.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu5: 4.1 us, 12.3 sy, 0.0 ni, 83.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu6: 3.8 us, 16.7 sy, 0.0 ni, 79.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu7: 26.1 us, 4.5 sy, 0.0 ni, 69.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 3807748 total, 446268 free, 2100916 used, 1260564 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 1427114 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1507 root 20 0 0 0 0 R 79.5 0.0 1604:33 mc_fastcall
2425 rp2 20 0 24128 1204 0 S 14.7 0.0 225:40.05 mcDriverDaemon
11085 rp2 20 0 144204 63960 40712 S 9.4 1.7 57:30.88 Xtightvnc
2427 1021 20 0 28380 4844 2436 S 6.5 0.1 124:24.49 gpsd
Установил linephone:
apt-get install linphone
В Settings показывает:
Audio Playback device: «ALSA: Meizu-Primary», «ALSA: Meizu-HiFi», «ALSA: default device», «PulseAudio: default»
Audio Capture device: «ALSA: Meizu-Primary», «ALSA: default device», «PulseAudio: default»
microSD LEXAR 1800x Professional Micro SDXC UHS-II 128GB
флеш-карта:
# hdparm -tT --direct /dev/mmcblk0
/dev/mmcblk0:
Timing O_DIRECT cached reads: 150 MB in 2.03 seconds = 74.05 MB/sec
Timing O_DIRECT disk reads: 222 MB in 3.02 seconds = 73.56 MB/sec
внутренняя память:
# hdparm -tT --direct /dev/sda44
/dev/sda44:
Timing O_DIRECT cached reads: 440 MB in 2.00 seconds = 219.72 MB/sec
Timing O_DIRECT disk reads: 746 MB in 3.00 seconds = 248.46 MB/sec