Piefed v1.6.10
Debian Linux 13 Trixie
Docker
kopitalk.net
Expectation: Piefed to load normally on browser.
Observation: There’s no pattern that I can make out, but since March 10, Piefed cannot be loaded on browser without warning. I checked the VPS and it functions as expected, I pulled the logs for “pyfedi-adminer-1”, “pyfedi-db-1”, and “pyfedi-redis-1”, each seemed to indicate time stamps that suggested things were still working in the background.
Efforts: I’m not really familiar with troubleshooting so I pulled the old off and on dance move here and restarted the docker. For what it’s worth the site loads normally at first, but quickly returns to being inaccessible. I ran a restore from backup 1 day back, and PieFed loaded normally without any issue.
Observation 2: Mar 11, I see the same issue happen overnight. Piefed is no longer accessible by browser. I repeated the check on the logs yesterday and it appears from timestamps that things are functioning in the background as expected.
Efforts: This time I decided to go further back, restoring from last week. I’m presently at Piefed v.1.6.8. I’m not sure if I should wait a bit and update to v.1.6.11.
That’s weird.
How much RAM does your server have? Maybe it’s running out - postgresql tends to start out using hardly any RAM and then it grows over time until it reaches the limit set by it’s configuration. Check what that is - it should be no more than half your RAM. In the compose.yaml near the start there is the bits you can tweak for postgresql.
Thanks! VPS has 4GB ram.
I have these defaults for the postgres
services: db: shm_size: 2gb image: postgres:17 restart: unless-stopped user: "1000:1000" env_file: - ./.env.docker command: - postgres # Memory - -c - shared_buffers=1GB - -c - effective_cache_size=3GB - -c - work_mem=32MB - -c - maintenance_work_mem=256MB # WAL / checkpoints - -c - checkpoint_completion_target=0.9 - -c - wal_buffers=16MB - -c - max_wal_size=4GB - -c - min_wal_size=1GB # Query planner - -c - random_page_cost=1.1 - -c - effective_io_concurrency=200 # Connections - -c - max_connections=150 - -c - jit=off volumes: - ./pgdata:/var/lib/postgresql/data networks: - pf_networkI tried searching around for tips on settings and stumbled on this.
Following those general tips then for a 4Gb RAM VPS
Step 1: Reserved 25% for the OS: 3Gb
Step 2: Adjust Shared Buffer to 25% to 40% of RAM (After Reserve): About 1Gb
Step 3: Adjust Working Memory for Concurrent Users: I adjusted for 150 Concurrent Users and about half of 4Gb. So 15Mb
150*15 = 2,250
Result: VPS RAM usage went down from the 80% range to around the 50% range.
Yeah that sounds better.
I normally use https://pgtune.leopard.in.ua/. Based on that I recommend:
shared_buffers = 1GB effective_cache_size = 2GB maintenance_work_mem = 256MB checkpoint_completion_target = 0.9 wal_buffers = 16MB default_statistics_target = 100 random_page_cost = 1.1 effective_io_concurrency = 200 work_mem = 16MB huge_pages = off min_wal_size = 1GB max_wal_size = 3GBI checked the memory records from last night and I do see the VPS hover in the 90% range, finally spiking to 98.9% when something probably finally choked.
Thanks for teaching me something new!
PieFed.social used to have 4 GB of ram so it’s totally doable, with a bit of tuning. I will tweak the default compose file to have smaller values because all servers are small at the start.
