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 1sL86f-00DbPi-UU for pgsql-general@arkaria.postgresql.org; Sat, 22 Jun 2024 21:17:10 +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 1sL86c-00FvFd-F2 for pgsql-general@arkaria.postgresql.org; Sat, 22 Jun 2024 21:17:06 +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 1sL86b-00FvEh-1u for pgsql-general@lists.postgresql.org; Sat, 22 Jun 2024 21:17:06 +0000 Received: from fhigh7-smtp.messagingengine.com ([103.168.172.158]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sL86S-0032Ti-Q6 for pgsql-general@lists.postgresql.org; Sat, 22 Jun 2024 21:17:04 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 0640311400CF; Sat, 22 Jun 2024 17:16:54 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 22 Jun 2024 17:16:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aklaver.com; h= cc:content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1719091014; x=1719177414; bh=KjuGlYPz15RXmXCsbq+YpiTEDz0mCCNpJUeeeBodbFg=; b= pf2raFVk/ZWn71fUWka/D2LQ7ADqkiypQ/Kh7AOnAOL7ad4C82DcpFLpMPXBL7ci bsmBMg0COcgQC3ifTH1guaLpnrrxSLihqcNPZM7HLjlTPyFtHDxJamtlpXVqSqcN Ax0r+fkEIeJeGSt1dF4hppB808wOLZmAmPAd7QyjVXb75YycqzdtmuVT9k7F0/Qr er3Zx/th5qLym2oYUT7WeW6iGHGYeOaNhfqHik5LDT5wWgbDGU77kMWRGH9zgdVA HHuX1R3F9/yZ9h3ySE1HOR3bT6HS3t9ojlq6uOKeyeuW7GKJs6EGH+NgwdV5tD8w ulubO+STZpzSbpj2QXMMew== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1719091014; x= 1719177414; bh=KjuGlYPz15RXmXCsbq+YpiTEDz0mCCNpJUeeeBodbFg=; b=v a541W7xRFdmGLTK/2cHozTPxhrVdlqPJMBXfIuAY9K4WPQ6rCwgzArc1ygeoPY6y JkiroMBKG07DJxJfcY2vJMnrh7z7K03vLm1D5+y1diLY5iDvn8igYTCcRoNiOOt2 E1sewxqd7HmfmFTSdYhkv8VxyCfXlJNSPbaBsr/9rYw7eDk97Sz7ewIJioLA1+NQ yeAVvBoiDh/oIquSB9ofMSeIhG1ggXuFD4V67rH76Eboao4a9dJ0XO2ciJVGkpeF dvjrXvT25wNs5WLZe0Rjv1m1n/BQkAqK2+s4AFyQDvXWIvpgKvWYjtfz5UMbZhmg bM9bmbiePWoT84WEivTgw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfeefiedgudeivdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfhfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeetughr ihgrnhcumfhlrghvvghruceorggurhhirghnrdhklhgrvhgvrhesrghklhgrvhgvrhdrtg homheqnecuggftrfgrthhtvghrnhepleegveekkeekueeigfdtveeileeuhfefudefteek jeffkeejueejheegheegkedtnecuffhomhgrihhnpehpohhsthhgrhgvshhqlhdrohhrgh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrughr ihgrnhdrkhhlrghvvghrsegrkhhlrghvvghrrdgtohhm X-ME-Proxy: Feedback-ID: i76984098:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 22 Jun 2024 17:16:52 -0400 (EDT) Message-ID: Date: Sat, 22 Jun 2024 14:16:51 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Autovacuum, dead tuples and bloat To: "Shenavai, Manuel" , Achilleas Mantzios , "pgsql-general@lists.postgresql.org" References: <2f2aafe6-3e29-4305-a279-1b3d56e9389e@cloud.gatewaynet.com> <53da5a20-ca35-40fa-85a3-c59d4302a512@aklaver.com> Content-Language: en-US From: Adrian Klaver In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 6/22/24 13:13, Shenavai, Manuel wrote: > Thanks for the suggestion. This is what I found: > > - pg_locks shows only one entry for my DB (I filtered by db oid). The entry is related to the relation "pg_locks" (AccessShareLock). Which would be the SELECT you did on pg_locks. > - pg_stat_activity shows ~30 connections (since the DB is in use, this is expected) The question then is, are any of those 30 connections holding a transaction open that needs to see the data in the affected table and is keeping autovacuum from recycling the tuples? You might need to look at the Postgres logs to determine the above. Logging connections/disconnections helps as well at least 'mod' statements. See: https://www.postgresql.org/docs/current/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHAT for more information. > > Is there anything specific I should further look into in these tables? > > Regarding my last post: Did we see a problem in the logs I provided in my previous post? We have seen that there are 819294 n_live_tup in the toast-table. Do we know how much space these tuple use? Do we know how much space one tuple use? You will want to read: https://www.postgresql.org/docs/current/storage-toast.html Also: https://www.postgresql.org/docs/current/functions-admin.html 9.27.7. Database Object Management Functions There are functions there that show table sizes among other things. > > Best regards, > Manuel > > -----Original Message----- > From: Adrian Klaver > Sent: 21 June 2024 22:39 > To: Shenavai, Manuel ; Achilleas Mantzios ; pgsql-general@lists.postgresql.org > Subject: Re: Autovacuum, dead tuples and bloat > > On 6/21/24 12:31, Shenavai, Manuel wrote: >> Hi, >> >> Thanks for the suggestions. I found the following details to our >> autovacuum (see below). The related toast-table of my table shows some >> logs related the vacuum. This toast seems to consume all the data >> (27544451 pages * 8kb ≈ 210GB ) > > Those tuples(pages) are still live per the pg_stat entry in your second > post: > > "n_dead_tup": 12, > "n_live_tup": 819294 > > So they are needed. > > Now the question is why are they needed? > > 1) All transactions that touch that table are done and that is the data > that is left. > > 2) There are open transactions that still need to 'see' that data and > autovacuum cannot remove them yet. Take a look at: > > pg_stat_activity: > > https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ACTIVITY-VIEW > > and > > pg_locks > > https://www.postgresql.org/docs/current/view-pg-locks.html > > to see if there is a process holding that data open. > >> >> Any thoughts on this? >> >> Best regards, >> Manuel >> > > > -- > Adrian Klaver > adrian.klaver@aklaver.com > -- Adrian Klaver adrian.klaver@aklaver.com