Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oSc0v-0005gA-Fb for pgsql-admin@arkaria.postgresql.org; Mon, 29 Aug 2022 10:29:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oSc0t-0002AF-UF for pgsql-admin@arkaria.postgresql.org; Mon, 29 Aug 2022 10:29:03 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oSc0t-0002A6-IN for pgsql-admin@lists.postgresql.org; Mon, 29 Aug 2022 10:29:03 +0000 Received: from mail-qt1-x830.google.com ([2607:f8b0:4864:20::830]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oSc0o-0002x9-Og for pgsql-admin@lists.postgresql.org; Mon, 29 Aug 2022 10:29:03 +0000 Received: by mail-qt1-x830.google.com with SMTP id g14so5732652qto.11 for ; Mon, 29 Aug 2022 03:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc; bh=dDBc0+vq3PhPcIQZevybUYOzwT5CMNG6WgPtLoguhqM=; b=fJwvYPtx68b2GLhspR6qN6VSZsE+FtGbjORKLWJ7NvqblZfbaozq9QgTzNqiBlQpeC K9KNc5azlfzUawQozytviVIxfMLrk+Q7RBtpYibw2LUgNqbCLFBELxAWXV8SccsveYV+ DpgwKxt8HX20XZ5nGl9WVwAChSqA4TCSbO7gJMcINPqTuf1zEiDI6TDApEn86z7DjYj/ FrN+qe869fsDNUoiceA8mhODU2WzbupHq3Htw7I2+ic0P3uzh9/Wm7IXURxHCaBQDjm0 O1YdbpaqDsvdgOxWf59Nyj3GDcz3HVgC8oEOjmzudugvOOxIxF/2QezCoGt8wLqkR7Ba TPUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc; bh=dDBc0+vq3PhPcIQZevybUYOzwT5CMNG6WgPtLoguhqM=; b=qmNTE+gQmBE76QmvlKk6hEKFQ+SiJuGp4/vqdXGkaDMKzHBodUIxuwaO8tyW9UtVwV aII+VEdpgSENDbbhUFvlANtztNS1Egy4DQ0Be08RvggBk8eZ+9M9FQrEIMr9aqTYRrZy C/ibkW+kPeGYwkkTtZuRy7bZxOcr8w6FDZ9a8oswR3yXiq8LXlNCRhXZRhTIpX9XUkXV gvvHicpi8DUxgRDgi+Yk99pIPgmfRFP9ueiOUj6iH+DMc9nDhE7Kg3+ck73Ww/3Jdz/j oQ/wFXWJqB1Doh5ZAqbK/10Air2OlmT8iYdq5B64SvElzjq7Cizgynld6ypKVAWwtbRa C/RQ== X-Gm-Message-State: ACgBeo3SXeBYGnz4QyfQ9Fg/+ZsNrGyAFMxroqV0S2injd1ftXdCwRo9 FvAlNfSOZYMlPLrdVjg1NKF7i+ugM55t8w== X-Google-Smtp-Source: AA6agR5MHAwwXgdo/SrgK8KlDpyyD8jA/kT1cCC5CSW9FSaVeSe6EfXbyswraOg1HvAs0iqCCt329w== X-Received: by 2002:a05:622a:15c7:b0:344:5321:5874 with SMTP id d7-20020a05622a15c700b0034453215874mr9411407qty.506.1661768936797; Mon, 29 Aug 2022 03:28:56 -0700 (PDT) Received: from smtpclient.apple ([209.33.119.45]) by smtp.gmail.com with ESMTPSA id bx4-20020a05622a090400b00342fcdc2d46sm4914048qtb.56.2022.08.29.03.28.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Aug 2022 03:28:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: John Scalia Mime-Version: 1.0 (1.0) Subject: Re: WAL restore is very slow Date: Mon, 29 Aug 2022 06:28:55 -0400 Message-Id: References: Cc: pgsql-admin@lists.postgresql.org In-Reply-To: To: Madhu Sudan X-Mailer: iPad Mail (19G82) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk First off, why are you still running on a rather small r5 instance? AWS has h= ad r6 instances available for some time, and they=E2=80=99re faster and more= efficient. Of my some 30 instances which I take care of, I haven=E2=80=99t h= ad any r5=E2=80=99s in quite some time. And it sounds here that you=E2=80=99re running on an EC2 instance as well. I= s there some reason you haven=E2=80=99t gone to RDS? Cluster configuration i= n RDS uses an internal RDS specific replication method that does not involve= WAL files. =E2=80=94 John Sent from my iPad > On Aug 29, 2022, at 6:10 AM, Madhu Sudan wrote:= >=20 > =EF=BB=BF > Hi >=20 > We have PG-14 with a huge data set of 14 TB running on r5b.2xlarge. We hav= e set up WAL archiving and restoring them onto a replica server. The WAL res= tore on the replica is very slow and we are not able to achieve the 4 hour d= elayed replica. It is always behind 30 hrs with the huge WAL generation. >=20 > I have checked the following and they look fine > 1. Bottlenecks on the replica server > 2. Memory consumption and swap > 3. EFS IO throughput > 4.checkpoint_completion_target =3D 0.9 > 5. wal_buffers =3D 16MB > 6. wal_log_hints =3D on > 7. Verified logs and didn't find anything useful related to the issue >=20 > Can you please suggest how to improve the WAL restore performance=20 >=20 > Thank you=20 > Madhu Sudan >=20 >=20 >=20