История изменений
Исправление
commagray,
(текущая версия)
:
Зависит от характера использования. Если взаимодействие с федерацией будет минимальным, будет комфортно и на VPS (насчёт RPi3 сказать не могу, у меня такой нет для тестирования). Как ранее уже сказали, нагрузка не от количества пользователей, а от того, а с каким количеством комнат одновременно синхронизируется сервер.
Теперь ньюансы насчёт федерации и не только.
- Вложения не удаляются, они перманентные — желательно иметь S3/удалённую файлопомойку. Твой сервер также реплицирует вложения из других серверов. Для S3 и дедупликации файлов я использую matrix-media-repo. Оно забагованное местами, но ситуацию исправляют и последние выпуски уже без критических неисправностей (раньше оно удаляло и портило файлы).
- История комнат по факту тоже перманентная, хоть и есть какой-то механизм её удаления — не пользовался, да и оно настолько «удобное», что отбивает всякое желание пробовать. При активном использовании федерации ожидай гигабайты истории из внешних комнат, в которых находятся твои пользователи. Зато поиск по ней есть.
- При входе в комнату синхронизируется история. Не только сообщений, но и других системных событий. Это тоже многомегабайтные блобы информации. При входе в условный #matrix:matrix.org твой сервер удивится количеству поступаемой информации от тысяч пользователей в комнате и будет сильно стараться, чтобы это обработать, полностью забирая себе процессорное время и пару гигабайт памяти под временный кэш. Если ресурсов не хватает, он умрёт на месте. Возможно, вместе с VPS.
Но даже после того, как я перешёл на сервер с 32 гигабайтами памяти, Synapse в простое выглядит так:
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
7edf7eee8b95 matrix_synapse_1 2.77% 354.4MiB / 31.18GiB 1.11% 694MB / 519MB 164MB / 0B 21
Так что потребление ресурсов — это ситуационная проблема, а не постоянная.
Исходная версия
commagray,
:
Зависит от характера использования. Если взаимодействие с федерацией будет минимальным, будет комфортно и на VPS (насчёт RPi3 сказать не могу, у меня такой нет для тестирования). Как ранее уже сказали, нагрузка не от количества пользователей, а от того, а с каким количеством комнат одновременно синхронизируется сервер.
Теперь ньюансы насчёт федерации и не только.
- Вложения не удаляются, они перманентные — желательно иметь S3/удалённую файлопомойку. Для S3 и дедупликации файлов я использую matrix-media-repo. Оно забагованное местами, но ситуацию исправляют и последние выпуски уже без критических неисправностей (раньше оно удаляло и портило файлы).
- История комнат по факту тоже перманентная, хоть и есть какой-то механизм её удаления — не пользовался, да и оно настолько «удобное», что отбивает всякое желание пробовать. При активном использовании федерации ожидай гигабайты истории из внешних комнат, в которых находятся твои пользователи. Зато поиск по ней есть.
- При входе в комнату синхронизируется история. Не только сообщений, но и других системных событий. Это тоже многомегабайтные блобы информации. При входе в условный #matrix:matrix.org твой сервер удивится количеству поступаемой информации от тысяч пользователей в комнате и будет сильно стараться, чтобы это обработать, полностью забирая себе процессорное время и пару гигабайт памяти под временный кэш. Если ресурсов не хватает, он умрёт на месте. Возможно, вместе с VPS.
Но даже после того, как я перешёл на сервер с 32 гигабайтами памяти, Synapse в простое выглядит так:
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
7edf7eee8b95 matrix_synapse_1 2.77% 354.4MiB / 31.18GiB 1.11% 694MB / 519MB 164MB / 0B 21
Так что потребление ресурсов — это ситуационная проблема, а не постоянная.