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

- 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

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

I should double-check but the intention is that it doesn't pull backfill window for PDS instances when initially crawling.

yeah, total data by the end seems too low for it to have been backfill, i assume it was just did resolution and normal sync stuff. never thought 250mbit would feel slow heh.

but for the backfill window/persistence setting: i put it at 48h, so i should expect it to start from zero in a new instance // wait at least that long before trying to estimate space usage?