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 1tBIkU-002xox-U9 for pgsql-general@arkaria.postgresql.org; Wed, 13 Nov 2024 19:09:54 +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 1tBIkS-00G9sW-9z for pgsql-general@arkaria.postgresql.org; Wed, 13 Nov 2024 19:09:52 +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 1tBIkR-00G9sM-S5 for pgsql-general@lists.postgresql.org; Wed, 13 Nov 2024 19:09:52 +0000 Received: from mail-yw1-x112d.google.com ([2607:f8b0:4864:20::112d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tBIkO-001lMj-7h for pgsql-general@lists.postgresql.org; Wed, 13 Nov 2024 19:09:51 +0000 Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-6ea5b97e31cso9832057b3.1 for ; Wed, 13 Nov 2024 11:09:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731524987; x=1732129787; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=6p/GseC+Nt7Tos+BbYJaJXeEosyv1BugOAvF8nNUn4o=; b=jrKOW+7cDLjGcz14hSXSr5z/vpbvpjzZ4+yAS6si3JefgX7ENxgAWmSmnBbccYCZ3M sC3/HelVceqQzgO3scmS1CF0F56/AZtp2kXX8XzjjJRsS2W1PjogF3VC9rML3N6mJ5Dc Poj5Q1FSC9cg7X6hMy72OsJGEPWw/1zp819A9L+IpiXfrgTqii+iZVJsi8ziwCBNvxXv nFvMVfbCahCSac+ExQ13HNg8v9WCz9+mZjOUnC2aYwe92smceZiLWIa3VM36+toawq+F A5M0oiHetPoRFafggDIaC4GDGx/1qa8MrPuSk4lgZmHy9SJW5nAtBGfcieDJcsNtcM4W 5k8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731524987; x=1732129787; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=6p/GseC+Nt7Tos+BbYJaJXeEosyv1BugOAvF8nNUn4o=; b=EF+BRHsUPfNvfrHHWYxTd0Q9to2IvBMYTHomIwNxuum384pJM2nEuqYP0POcALZE0V jpugRGloHKEmJue9pBtJEPI+FUUSGmQ1KEf2PYCQOrr+YxuqOqyR5yWGl8TSDiAN/yZ7 bQvLdbUY5lMA1XayT9cqWrbFF2lvd2keYXNC/6lxmaI7rFIM0vRcX1rOrt/ZPPDa1KOQ BNtx/4Je2VkjKQJxKypiD/UmLmSyYuOyeU0TZyjj6YQ6fOUYXxhFQ2yK2tXFtI8a6S41 lRWnt0jsj9IIZ9NP+4IGPbbC+oeCB7lsXG6myeL7eF+ldVu4N+tICQV7qVdfAE2guC5I d9xA== X-Gm-Message-State: AOJu0YzBY5ToJjKFXIEMgNC+gKyNjdBWi+/A6oOJTnvWBVlmIWeaCqbm ciHBWtUs9G8elGguEETcTVwdbOEFr1PUq/x5dEhD55wHcl6obEnPJFdy0P3u1oVCx4m6/D/goF8 VQXKQMeuGOdKnPB7umFO9gCRkaqpPDaN2 X-Google-Smtp-Source: AGHT+IF5YZ/aM6mQSM231qVH3ehDymuhZcffSa7Tc6aTrQF2ZHqIx4TIityiBjkRO3ENluyOfNAqrh/VWTEXuY/mN6Q= X-Received: by 2002:a05:690c:c8e:b0:6e9:c117:760b with SMTP id 00721157ae682-6ee3d337026mr7765957b3.5.1731524986530; Wed, 13 Nov 2024 11:09:46 -0800 (PST) MIME-Version: 1.0 From: Alexandru Lazarev Date: Wed, 13 Nov 2024 21:09:35 +0200 Message-ID: Subject: work_mem RAM Accounting in PostgreSQL To: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000bdf4200626d01301" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000bdf4200626d01301 Content-Type: text/plain; charset="UTF-8" Hello Everyone, I have some questions regarding how the "work_mem" parameter affects the overall RAM usage of PostgreSQL processes within a physical host or container. Each backend process during SQL execution may allocate N * "work_mem" simultaneously. For example, if "work_mem" is set to 32MB and N=5 (i.e. 5 simultaneous and/or sequential ORDER and hash operations), and the initial RAM usage (RSS - Resident Set Size) of the backend is 10MB, I would expect the backend process to use 160MB (32MB * 5) + 10MB, resulting in a total RAM usage of 170MB. My questions are as follows: 1. What happens to the allocated "work_mem" after the execution of query nodes? Are these memory allocations freed? 2. If they are freed, do they remain in the RSS of the PostgreSQL backend? 3. From various sources, I understand that these allocations are freed after each node execution due to memory contexts, but they might remain in some sort of backend memory pool for future reuse. Is this correct? 4. If so, will this memory be accounted for as used RAM on my Linux/Container system after the backend returns to an idle state (e.g., connection pooling)? Additionally: If the above is true, and my PostgreSQL host or container is limited to 16GB of RAM, what would happen if I have 100 pooled connections, each gradually allocating those 160MB? Will this memory be reclaimed (if I understood it correctly as a kind of inactive anon mem), or will the OOM Killer be triggered at some point (because it is real allocated memory)? Thank you for your insights. Best regards, AlexL Java Dev --000000000000bdf4200626d01301 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Everyone,

=
I have some questions regarding how the "work_mem" parameter= affects the overall RAM usage of PostgreSQL processes within a physical ho= st or container.

Each backend process during SQL e= xecution may allocate N * "work_mem" simultaneously. For example,= if "work_mem" is set to 32MB and N=3D5 (i.e. 5 simultaneous and/= or sequential ORDER and hash operations), and the initial RAM usage (RSS - = Resident Set Size) of the backend is 10MB, I would expect the backend proce= ss to use 160MB (32MB * 5) + 10MB, resulting in a total RAM usage of 170MB.=

My questions are as follows:

=
1. What happens to the allocated "work_mem" after the execut= ion of query nodes? Are these memory allocations freed?
2. If the= y are freed, do they remain in the RSS of the PostgreSQL backend?
3. From various sources, I understand that these allocations are freed aft= er each node execution due to memory contexts, but they might remain in som= e sort of backend memory pool for future reuse. Is this correct?
= 4. If so, will this memory be accounted for as used RAM on my Linux/Contain= er system after the backend returns to an idle state (e.g., connection pool= ing)?

Additionally: If the above is true, and my P= ostgreSQL host or container is limited to 16GB of RAM, what would happen if= I have 100 pooled connections, each gradually allocating those 160MB? Will= this memory be reclaimed (if I understood it correctly as a kind of inacti= ve anon mem), or will the OOM Killer be triggered at some point (because it= is real allocated memory)?

Thank you for your ins= ights.

Best regards,=C2=A0
AlexL
Java Dev
--000000000000bdf4200626d01301--