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.

mostly unrelated but - i’m still not friends with docker

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

We generally use svlogd in production to handle logs and log rotation like this in the docker compose: command: dumb-init sh -c 'relay serve 2>&1 | svlogd -b100000000 /log' volumes: - type: bind source: ${LOG_DIR_ON_HOST} target: /log And add a 'config' file: s1000000000 n2

So your logging dir on the host should have a {path}/config with: s1000000000 n2 and the docker compose should point at {path} for the volume bind mount this handles high volumes of logs much more performantly than leaning on podman/docker log routing

with a unix pipe and all! thank you!!!!!!! will do this next time i restart 💜

ok this is awesome. going full-throttle (reconnecting 10 of the big mushrooms), svlogd is ~1.2% of cpu time, relay 72%, postgres 23% feeling pretty good about this utilization!