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 1sxIlX-009CPc-3k for pgsql-bugs@arkaria.postgresql.org; Sun, 06 Oct 2024 04:21:07 +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 1sxIkW-009hC0-T6 for pgsql-bugs@arkaria.postgresql.org; Sun, 06 Oct 2024 04:20:04 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sxIkW-009hBr-7N for pgsql-bugs@lists.postgresql.org; Sun, 06 Oct 2024 04:20:04 +0000 Received: from m16.mail.163.com ([117.135.210.2]) by makus.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sxIkL-002jrp-Oi for pgsql-bugs@lists.postgresql.org; Sun, 06 Oct 2024 04:20:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:Subject:Date:Message-ID:MIME-Version: Content-Type; bh=DgwUflm33bFbW8hgwLR4nERAVVRY7SjS9e1bMf2R9SM=; b=IfWtZeI/P/LdOPekmDaZXjhzAbXMELJ1PFUvlw5gkcEBYKa+/alViX2kdzBaYC YCUbp3msZ59jSKfjPt5asSuO1oxj6bM10kT9xpJgM/k0wbJxJpYIT2ImMt/CZaZU 80Rk7Zsdij5iL8eedJfJuFXwAqQ2ehcEvkmcX5Tq+nc3k= Received: from lovely-coding (unknown [101.227.46.166]) by gzga-smtp-mtada-g0-0 (Coremail) with SMTP id _____wD3v4_iDwJnpVrfBA--.45674S3; Sun, 06 Oct 2024 12:19:47 +0800 (CST) From: Andy Fan To: Tomas Vondra Cc: DBA , "pgsql-bugs@lists.postgresql.org" Subject: Re: what are the things that occupy the session memory. In-Reply-To: <6962bb55-37fd-4b8d-83ca-822d2087b1a2@vondra.me> (Tomas Vondra's message of "Wed, 2 Oct 2024 10:47:42 +0200") References: <20240930023236.9EC5610AA47@wsmtpa1.ecounterp.com> <6962bb55-37fd-4b8d-83ca-822d2087b1a2@vondra.me> Date: Sun, 06 Oct 2024 12:19:46 +0800 Message-ID: <87zfnhkgm5.fsf@163.com> MIME-Version: 1.0 Content-Type: text/plain X-CM-TRANSID: _____wD3v4_iDwJnpVrfBA--.45674S3 X-Coremail-Antispam: 1Uf129KBjvJXoW7CryrCr1DJr4fAr15uFWfZrb_yoW8Gr18pF WSg3yjyw4DXFs3tryvyr17Gr1Y9an5Cr9rGFZ3ursrGw4fXw4kZrnFyrsIya42y3y8W3yj vFyIq3sxua4rZFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0zRrR6xUUUUU= X-Originating-IP: [101.227.46.166] X-CM-SenderInfo: x2klx3xlid0iqsrtqiywtou0bp/xtbBZx9wU2cCCYI+MAAAs7 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Tomas Vondra writes: > Anyway, I agree shared buffers 70GB is way too high - I'd reduce that to > maybe 8GB and only increase that if cache hit ratio is below 0.95 or > so. I'm always confused how should shared_buffers be set initially (saying monitor and adjust them later is not free.) Some places say 25% of physical memory but I don't know why is that. I'm not sure my question can have a answer, but just have a try. The known drawback of big shared buffer from me includes: a). Seize the memory from other component which may contribute to OOM. b). make some operation slower. e.g. drop / truncate table. > If not, try reducing work_mem. If you're doing OLTP queries, those > likely don't need wm=300MB (why did you set this value?). For OLAP > queries 300MB might make sense, but then maybe you shouldn't have 300 of > them. I want to have a metion of autovacuum_work_mem/maintenance_work_mem for a OLTP workload. In OLTP workload, user probably doesn't need a bigger work_mem but if user set it to a bigger value, it should not cause a big issue IIUC, since it just set a upper bound. However in OLTP workload, it probably has lots of updates/delete, and if they have lots of tables, it probably use up to {autovacuum_work_mem} memory per vacuum worker, which is more likely cause an issue. -- Best Regards Andy Fan