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.

  • 1.ceramics926@kopitalk.netOPEnglish
    1·
    4 days ago

    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_network
    • 1.ceramics926@kopitalk.netOPEnglish
      1·
      4 days ago

      I tried searching around for tips on settings and stumbled on this.

      https://dbadataverse.com/tech/postgresql/2025/02/postgresql-configuration-parameters-best-practices-for-performance-tuning

      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.

      • Rimu@piefed.socialEnglish
        3·
        4 days ago

        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 = 3GB
        • 1.ceramics926@kopitalk.netOPEnglish
          1·
          4 days ago

          I 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!

          • Rimu@piefed.socialEnglish
            4·
            4 days ago

            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.