3 ms·

Have you tried running Mastodon and Matrix on a Pi? I'm not so confident it'd work, these aren't lean servers. I would love a tiny server I can run on my home

Have you tried running Mastodon and Matrix on a Pi? I'm not so confident it'd work, these aren't lean servers. I would love a tiny server I can run on my home server (for my tiny message volume), but Mastodon and Synapse are optimized for large servers.

walrus01 6y ago
synapse is actually quite tiny, but its use of an sqlite db on disk and other disk-write related activities, over a long term of months or years, seems quite likely to destroy a raspberry pi microsd card in much the same way that ordinary logging will destroy a microsd card. yes the rpi4 can boot from a USB-connected 'real' sata device now, which is an improvement.
- StavrosK 6y ago
  > synapse is actually quite tiny Hmm, is it really? My server has a SSD so I don't care about writes, I just want it to be low on CPU and memory requirements.
  - walrus01 6y ago
    an entire synapse with its python environment is about 150MB of disk space occupied, before any user data starts getting written to the database. chat for a group of about twenty people runs fine on a VM with 512MB of RAM. After boot about 300MB of the system RAM is occupied by the base minimal debian OS and other daemons (snmpd, etc), leaving plenty for python3. this same machine also has a minimal nginx setup as the standard reverse proxy configuration for TLS1.2/TLS1.3 in front of the synapse daemon, which isn't set up for any crypto and only listens on localhost.
    - Arathorn 6y ago
      It's worth noting that this sounds to be an unfederated server. The reason Synapse has a reputation for being resource hungry is on publicly federated servers: if one of the users starts going and joining a bunch of large busy public rooms from their new server, then those rooms get dutifully replicated onto the server, which inevitably consumes resources. The more users and the more servers in the room, the more changes of gnarly forks and merge resolution problems, and the more the risk of CPU spikes. We're constantly working on the memory footprint and state resolution algorithm (e.g. https://github.com/matrix-org/synapse/blob/develop/docs/auth_chain_difference_algorithm.md https://github.com/matrix-org/synapse/blob/develop/docs/auth... landed a few days ago), so the situation is improving, but this is the root cause.
      - walrus01 6y ago
        Yes, absolutely, this is for company internal use only. I imagine the resources for a server that talks to the outside world are much greater.
vihren 6y ago
I have tried it on a RPi3 and it is painfully slow. I would not recommend this to anyone.

walrus01 6y ago

synapse is actually quite tiny, but its use of an sqlite db on disk and other disk-write related activities, over a long term of months or years, seems quite likely to destroy a raspberry pi microsd card in much the same way that ordinary logging will destroy a microsd card. yes the rpi4 can boot from a USB-connected 'real' sata device now, which is an improvement.

StavrosK 6y ago
> synapse is actually quite tiny Hmm, is it really? My server has a SSD so I don't care about writes, I just want it to be low on CPU and memory requirements.
- walrus01 6y ago
  an entire synapse with its python environment is about 150MB of disk space occupied, before any user data starts getting written to the database. chat for a group of about twenty people runs fine on a VM with 512MB of RAM. After boot about 300MB of the system RAM is occupied by the base minimal debian OS and other daemons (snmpd, etc), leaving plenty for python3. this same machine also has a minimal nginx setup as the standard reverse proxy configuration for TLS1.2/TLS1.3 in front of the synapse daemon, which isn't set up for any crypto and only listens on localhost.
  - Arathorn 6y ago
    It's worth noting that this sounds to be an unfederated server. The reason Synapse has a reputation for being resource hungry is on publicly federated servers: if one of the users starts going and joining a bunch of large busy public rooms from their new server, then those rooms get dutifully replicated onto the server, which inevitably consumes resources. The more users and the more servers in the room, the more changes of gnarly forks and merge resolution problems, and the more the risk of CPU spikes. We're constantly working on the memory footprint and state resolution algorithm (e.g. https://github.com/matrix-org/synapse/blob/develop/docs/auth_chain_difference_algorithm.md https://github.com/matrix-org/synapse/blob/develop/docs/auth... landed a few days ago), so the situation is improving, but this is the root cause.
    - walrus01 6y ago
      Yes, absolutely, this is for company internal use only. I imagine the resources for a server that talks to the outside world are much greater.

vihren 6y ago

I have tried it on a RPi3 and it is painfully slow. I would not recommend this to anyone.