Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tqgFA-008mq9-J8 for pgsql-general@arkaria.postgresql.org; Fri, 07 Mar 2025 22:32:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tqgF9-001BqB-3V for pgsql-general@arkaria.postgresql.org; Fri, 07 Mar 2025 22:32:35 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tqgF8-001BpU-PD for pgsql-general@lists.postgresql.org; Fri, 07 Mar 2025 22:32:34 +0000 Received: from mail-yw1-x1132.google.com ([2607:f8b0:4864:20::1132]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tqgF5-001a1o-0g for pgsql-general@lists.postgresql.org; Fri, 07 Mar 2025 22:32:34 +0000 Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-6f6c90b51c3so22371417b3.2 for ; Fri, 07 Mar 2025 14:32:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741386750; x=1741991550; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=lnfRnlFm+jE6RfEYXNASVjRn7y3zRRg3owdQgzpbze0=; b=CbIZP1abeBJxQ38+f2aXyNiEWCi3CZyky9GbFPDjVV5Q6kzX+2XssSzGF2o9bellqt QEbnGermn6ahPuGuFdHM+61Dna0vLTUw0TlHIIDV+gnW+czeomHhlF+OBMYqnL2ebMRx FS7wv6n9OZhQuOMuNOMVkFmIhlnmKpwojZjSWkNducUkI+Gdv8MLHFk6v7Vr8WgYAuzY /4EE3jb/0AF3c7s08JtsW+w+GEMIOyIBYNRB9qQwH4MNJfjyRep4FRCGkMpM/BEtPiRM 4ON40E1rqN5MGR71A5RD6jH6KC8BcHntklbdCsZyxnGj3uOtu8rui2L/oZxpPBHV+Jg2 RY3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741386750; x=1741991550; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=lnfRnlFm+jE6RfEYXNASVjRn7y3zRRg3owdQgzpbze0=; b=stoKui+eFo3dixJWzm2oP6KzO+2JXju4CuZ2dcH6/y2dQWKr5P2vjHmdE5YJkr2/kx vUBVe48nhoYx0b3Kqt2Rc2h8M5Knw9tcTiucBy/FrigALiaXm6z2/sQG2XmCUfWinkT1 h2dxbYGQX5Ucf6zM+mbM8e17PEPrjxok3pFdRgujhNA9IJZsvxANm+cK0h9YOEsmrG/y 2p8oAeC6+fE6f7TsxNeE2iD3hLwGCXoLyp0mN0jrf0hdwaBOA5UtGaCqlVhMO0RbL3o3 qDzqsRW8eqoY3wTzUZnWE/ROsccgKCpS3vqvf4Q4JqYglutB/II1kY7DWUSgNit98FcR ntuw== X-Gm-Message-State: AOJu0YzuysGJbUe6lY9TSGVq8X0+4CDiFm4zf3epGUhSOukFyb6Dn8jI g7ErxPQpPaCQWd9aTkdupvLcsipVmv1KsZoD2GMBXWZI73leyyRdI3LTsxZvVVe9eDIdNfr8gGm mhAZ2hdhYjj0QPA3mMUv4az2On/qtWGNb X-Gm-Gg: ASbGncuE/uv4UuV4o1dLAGirAmXEe2DpC1TMj+70Vwpgx6AbSmI5AfgB2Ah09Frib+k y7WUhnY0jnDfyjG8M7IW89A5dxJHeL0He+uKJwovdoWgHBocZKtSN/bJPsi/ehurZCnk/7o/7Yc +TKFy1A8d5MGSLEeii0hnCJ3uMCA== X-Google-Smtp-Source: AGHT+IFwvuPTJJv8UhL83jX8i1rOd0O8IhywjRDhXgEvrpCMfwKRMSm2lRSIwGCznviZ4RZIT7ewD2BcS95hn4cI2Og= X-Received: by 2002:a05:690c:6107:b0:6f9:af1f:fdcd with SMTP id 00721157ae682-6febf2e67femr86518027b3.11.1741386750270; Fri, 07 Mar 2025 14:32:30 -0800 (PST) MIME-Version: 1.0 From: Alexandru Lazarev Date: Sat, 8 Mar 2025 00:32:19 +0200 X-Gm-Features: AQ5f1JoK46VJkcZCrMxVFY35gUp6hZfbGRUbLdLv-BIhGsr1dKQfNUvA40QM7Ow Message-ID: Subject: Is pg_basebackup Performance Limited by Files Page Cache? To: pgsql-general@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi everyone, I'm a Java developer, so please bear with me if my description isn't perfect. I hope the community can help me understand this issue better. I have PostgreSQL 15 running in a Kubernetes Pod using the Zalando Spilo image, managed by Patroni. The container has a memory limit of 16 GB, and the database size is 40 GB (data dir on disk). When I reinitialize a replica with Patroni, it runs 'basebackup.sh', which in turn runs the 'pg_basebackup' command: "/usr/lib/postgresql/15/bin/pg_basebackup --pgdata=/home/postgres/pgdata/pgroot/data -X none --dbname='dbname=postgres user=standby host= port=5432' " I noticed that the first 16 GB are copied quickly, but the process slows down significantly afterward (I observed that after the copied size is approximately equal to container's memory limits). Increasing the container memory limit to 32 GB showed a similar pattern: the first 32 GB were copied quickly, then it slowed down. Running the command manually: "/usr/lib/postgresql/15/bin/pg_basebackup --pgdata=/home/postgres/pgdata/pgroot/dummy_dir -X none --dbname='dbname=postgres user=standby host= port=5432' " reproduced the issue. Once the container's total memory (including page cache, and including inactive files which are a lion's part of container MEM) reaches the limit, 'pg_basebackup' slows down. Other disk write operations (e.g., generating and copying large files with 'dd') are not affected by the memory limit and remain fast. When 'pg_basebackup' is slow and the container memory limit is reached, I tried discarding the page cache with: "sync && echo 3 > /proc/sys/vm/drop_caches" and this made 'pg_basebackup' fast again. Is 'pg_basebackup' performance limited by the files page cache? Do you need any additional information from me? Any suggestions? Thanks for your help! Regards, AlexL