Post

learned so far: - 4 cores seems _enough to run_ but on this particular host it’s kind of marginal. 16GB ram seems plenty. - it’s been dropping pds websockets, and doesn’t seem to recover on its own. not sure why. - bandwidth is less than i was expecting. - +jetstream on this server is too much

fig (aka:[phil])@bad-example.com

kinda still a relay noob but uh i think it’s doing the thing non-us jurisdiction (montreal) non-us-company-cloud-provider relay. chillin.

7 reposts92 likes

dropping the pds websockets is interesting, i do wonder if this is because the PDSs arent requestCrawling this relay like they are for our relay. (the relay might have a bug and we can paper over it in our prod relay because the pds's ask us to crawl them all the time)

Related. Are there plans for a Relay Registry that a PDS could hit, and all Relays listen to? Thinking PubSub, or some other async mechanism so as new PDS come online, all Relays can periodically be notified “you should look at this PDS”. Relays could choose to ignore or filter by domain host etc.

yeah i’ll look into it more in the coming days. (i don’t have a great sense of how the pds socket is meant to be managed yet) my relay is not accessible via public inbound connections yet (though idk how a pds would even know which host it should be requestCrawl’ing to if the relay initiates)

yeah, for now the PDSs just have a hardcoded value that is the relay they want to make sure sees them. it should be configurable per PDS, but its not meant to just ask any relay that exists (theres not really a discovery system there)

- pds backfill is rough on this server, cpu pegs 100% - made worse by having jetstream on the same server trying to do a higher event rate - also interesting: jetstream just crashes when it’s relay websocket closes? fine if the supervisor auto-restarts it i guess.

- 4 shared cores on a 2017-era 2ghz epyc is not enough for a relay. could probably tune some things to get it there—seeing significant overhead from userspace networking + logging—but i def want more performance margin than this. for $5.5CAD i can get two more shared cores, or double that for 8

Run your container in host network mode, I bet 80% of that CPU is copying network packets around. Alternatively don't use a user space proxy for your container.

will try!! on my list before ditching this server to just drop the whole container and run it in the host (it’s a dedicated vm for it already) then to remember enough iptables to restrict public interface traffic from reaching it directly, or hack it bind on localhost instead of 0.0.0.0

this provider has a very tempting “dedicated 4 cores” offering that might work but it can’t be configured with enough storage for much of a replay window. otherwise i’m looking at ~$120/mo and that gets me a whole big real dedicated *machine*. maybe if i push for some kofi/github sponsors i could.

i *should* know more about what’s happening but: i think it’s doing a full sync for each pds? would be nice to say “just trust the latest root and validate going forward from there” with sync1.1, but maybe i don’t know what i’m talking about. manual requestCrawl per PDS and letting it finish is ~3m

see, i will come back to do something with docker after a while not needing to touch it and i just do not want to have to remember things like “quotes are interpreted as literal around values in .env files” (seems this is why relay_trusted_domains and log level weren’t working)

because of the log thing, about 65% of one of the four cpu cores is just journalctl+syslog(?!) (thanks podman) i’m in to deep syncing bluesky pdss now to restart for it, it’s just slowing things down til next time indigo/relay hit list new item - [ ] set up runtime slog level changes