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 1su1sW-003YGZ-JB for pgsql-general@arkaria.postgresql.org; Fri, 27 Sep 2024 03:42:49 +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 1su1rW-001pVA-G7 for pgsql-general@arkaria.postgresql.org; Fri, 27 Sep 2024 03:41:46 +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 1su1rW-001pV1-1Z for pgsql-general@lists.postgresql.org; Fri, 27 Sep 2024 03:41:46 +0000 Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1su1rR-001IJb-C9 for pgsql-general@lists.postgresql.org; Fri, 27 Sep 2024 03:41:45 +0000 Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a8ce5db8668so257966266b.1 for ; Thu, 26 Sep 2024 20:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727408502; x=1728013302; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ohQag3R+3QLQyCgl2VmW3w7Ny+/6ULh0ZHjwI3480bA=; b=FHKcy3tx98niFKamdgpaVF3jfs8bZC1u5P/9dYBEWU3/xHajn+j2hp6Wm9EAqtW/0a MG7+m4DAAC2pEe316PT7DNQR0jKsgco8xLs1g/sxsZ5W3pzE7cAFJVFWiJhR7s+pdko3 LTfiRtpVRKXJGwNf2Q7KbA5HpAGIYMUPzYXeki27mSCtQUCxBMoSdSBHAdRj3V96q399 wgcil6aO0WZhwNgMOIHpz2L4GYxyo2QO/+r1qoOEDuRKIl76TqFHm/eK82UmkRawAMO/ LeGINTeotvYLiZuxTZMGq9BIZ02HJckXiDXQyJ/TSzjomLv0ZXLID5zouaBlhf/WWj66 hMLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727408502; x=1728013302; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ohQag3R+3QLQyCgl2VmW3w7Ny+/6ULh0ZHjwI3480bA=; b=v9mqo6dQnQYZnzZgjyxlPdLzXoP+J4qgE8zCQRhb0Zz24WGuEFT1Hp39fwbEgSBV74 bdh0XLXB/uELOQ6JdAPhKG1MZkdyU8G6rj9LWfe38+4oDPnA6hbuYOtWEGuni8vqIHbW oTe0BWUdXWBCeV6EckkKi9UrlFQyhd82O15nUVchrx6SuJNbmY2X6msTzEy1s81iClRW tUpyPxuuV3R0LZPaoSueQ0JgYMGHJOETPIVSdbNon9q/DKTDA50+mgBRfgFKmErEGCPa aJGgNq/uno3rYnBktCQxdVZuqGu758Ur+aegASNLm/EgBrcDleUfSDxEAxk5HR5//RGT icxA== X-Gm-Message-State: AOJu0YwkLZqyJxNYc8yMpEpnU+v+ZBL91j3+mNogpUQOarRXu9R+RQF/ 1zKStcta2BCLRUng+a7CI0/hdwW6/682qeYGK3FeLEEVISgdWj8ggl1+tKwfZnFBBdTsE4vJukO t+xXEaba1EhEWxAWc9TXvJPQdTQdOlA== X-Google-Smtp-Source: AGHT+IHf4ZGGc31OzL7VNmBNkJIJgwaTatDgJz59aZ0hS9WyefRw78NZd87PW5QCE2bJYD6rejqd7ocGvLJjQ+dG59Q= X-Received: by 2002:a17:907:6094:b0:a86:c372:14c3 with SMTP id a640c23a62f3a-a93c4a4e0e5mr169751266b.48.1727408501391; Thu, 26 Sep 2024 20:41:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: veem v Date: Fri, 27 Sep 2024 09:11:28 +0530 Message-ID: Subject: Re: Suggestion for memory parameters To: yudhi s Cc: pgsql-general Content-Type: multipart/alternative; boundary="0000000000001b88a3062311a22b" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000001b88a3062311a22b Content-Type: text/plain; charset="UTF-8" On Thu, 26 Sept 2024 at 16:33, yudhi s wrote: > Hello All, > > In a RDS postgres we are seeing some select queries when running and doing > sorting on 50 million rows(as its having order by clause in it) , the > significant portion of wait event is showing as "IO:BufFileWrite" and it > runs for ~20minutes+. > > Going through the document in the link below, it states we should monitor > the "FreeLocalStorage" metric and when monitoring that, I see it showing up > to ~535GB as the max limit and when these queries run this goes down till > 100GB. Note- (it's a R7g8xl instance) > > > https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-waits.iobuffile.html > > We were thinking of bumping up the work_mem to a higher value in database > level , which is currently having size 4MB default. But we will also have > ~100 sessions running at same time and majority were from other > applications which execute other single row "insert" queries and I hope > that will not need high "work_mem" . And setting it at database level will > consume 100 times that set work_mem value. So how to handle this situation? > Or > Is it fine to let it use "FreeLocalStorage" unless it goes till zero? > > Also I am confused between the local storage (which is showing as 535GB) > vs the memory/RAM which is 256GB for this instance class with ~128TB max > storage space restriction, how are these storage different, (mainly the > 535GB space which it's showing vs the 128TB storage space restriction)? > Appreciate your guidance. > > select query looks something as below with no Joins but just single table > fetch:- > > Select.... > from > where > order by column1, column2 LIMIT $b1 OFFSET $B2 ; > > > My 2 cents I think you should set the work_mem on specific session level , if your sorting queries are only from specific handful of sessions, as because setting it up at database level will eat up your most of RAM(which you said is 256GB) and you said 100+ sessions getting spawned at any point in time. --0000000000001b88a3062311a22b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, 26 Sept 2024 at 16:33, yudhi s &l= t;learnerdatabase99@gmail.co= m> wrote:
Hello All,

In a RDS postgres we are seeing some se= lect queries when running and doing sorting on 50 million rows(as its havin= g order by clause in it) , the significant portion of wait event is showing= as "IO:BufFileWrite" and it runs for ~20minutes+. =C2=A0

= Going through the document in the link below, it states we should monitor t= he "FreeLocalStorage" metric and when monitoring that, I see it s= howing up to ~535GB as the max limit and when these queries run this goes d= own till 100GB. Note-=C2=A0 (it's a R7g8xl instance)

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-waits.io= buffile.html

We were thinking of bumping up the work_mem to a hi= gher value in database level , which is currently having size 4MB default. = But we will also have ~100 sessions running at same time and majority were = from other applications which execute other single row "insert" q= ueries and I hope that will not need high "work_mem" . And settin= g it at database level will consume 100 times that set work_mem value. So h= ow to handle this situation?
=C2=A0Or
=C2=A0Is it fine to let it use = "FreeLocalStorage" unless it goes till zero?

Also I am con= fused between the local storage (which is showing as 535GB) vs the memory/R= AM which is 256GB for this instance class with ~128TB max storage space res= triction, how are these storage different, (mainly the 535GB space which it= 's showing vs the 128TB storage space restriction)?=C2=A0 Appreciate=C2= =A0your guidance.

select query looks something as below with no Join= s but just single table fetch:-

Select....
from <table_name&g= t;
where
order by column1, column2 LIMIT $b1 OFFSET $B2 ;


My 2 ce= nts=C2=A0
I think you should=C2=A0set the work_mem on specific se= ssion level , if your sorting queries are only from specific handful of ses= sions, as because setting=C2=A0it up at database level will eat up your mos= t of RAM(which you said is 256GB) and you said 100+ sessions getting spawne= d at any point in time.
--0000000000001b88a3062311a22b--