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 1svdXI-00GZ78-F9 for pgsql-general@arkaria.postgresql.org; Tue, 01 Oct 2024 14:07:33 +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 1svdXH-00HPDo-L7 for pgsql-general@arkaria.postgresql.org; Tue, 01 Oct 2024 14:07:31 +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 1svdXG-00HPDP-OM for pgsql-general@lists.postgresql.org; Tue, 01 Oct 2024 14:07:31 +0000 Received: from fhigh-a2-smtp.messagingengine.com ([103.168.172.153]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1svdXD-001y4a-HL for pgsql-general@lists.postgresql.org; Tue, 01 Oct 2024 14:07:29 +0000 Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfhigh.phl.internal (Postfix) with ESMTP id A47151141431; Tue, 1 Oct 2024 10:07:26 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-11.internal (MEProxy); Tue, 01 Oct 2024 10:07:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aklaver.com; h= cc: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=1727791646; x=1727878046; bh=M34SflhovhzMkOuA7LX32VVJezdG/gKI7UT+bss9R5Q=; b= swG1s95wJWjoWxuwXdN3BnjvEPIBW0BbFdbGhrEUEd7TUwdl9VNnTVkHIkMl+u8j P8ajF1/L2hGKfAvKSXfgo9h11YI736NHv1A02xiy84BJeptoLVGemEvT6Wq2JTgJ KKpePvpWjo3VrJQBZBH7al7U8Hd8kNzsnbKms912Kcr+3nnHSwaJoIoVs2Ys7NKP oIbA14khYfrEEbdMRV800J0JFMrxiYgRuKFo76L5LdfK76BSqUVG/EESRz1Uwd5h NoVggjgP2gvg09xdheJVxU94o20kbUfUDVPWbvW9DEP8M6XY2V1h+eWFsxpkBuxy 47TyMtGbMfCc8oOqlgVfIQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=1727791646; x= 1727878046; bh=M34SflhovhzMkOuA7LX32VVJezdG/gKI7UT+bss9R5Q=; b=d rbJn/nJ2mm6g5DJy1IX8hIor997tgGEi4EwY1ASfoMm/Td5DQ47eOREVL6AepxHB tO6Kqf9dUlpBTTgDNDgR+q2Db6teAnrBCECyUoEjBy7148FFudokQ7fgmZWHCz2y chDR/hfdGxRGX94BqKLDTlMeOdDeA2p7kpopRJyrkfb8R7N3htI0wSBre8OfylFg KtO+wOV8TqZK48jRvUfxfdn4ir8/pC8tGLxXD0pLtNbw5n5L0xAyolgnbPB+o5ic hgj4oAFc7JVycTEY3YXVFjQdxX7PLC09ERTCe/EQXeOP8mryAzdv1IvweDiHAoPv Aqfwgc7yeMLoj5cuhWmBg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvddujedgjeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfg fuvfevfhfhjggtgfesthekredttddvjeenucfhrhhomheptegurhhirghnucfmlhgrvhgv rhcuoegrughrihgrnhdrkhhlrghvvghrsegrkhhlrghvvghrrdgtohhmqeenucggtffrrg htthgvrhhnpefgudefkefhveefleevieeuveehvdduudekuddvvdelhfeuueeijedtuedv vedvueenucffohhmrghinhepphhoshhtghhrvghsqhhlrdhorhhgnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprggurhhirghnrdhklhgrvhgv rhesrghklhgrvhgvrhdrtghomhdpnhgspghrtghpthhtohepvddpmhhouggvpehsmhhtph houhhtpdhrtghpthhtohepshhuughsudegfeegsehgmhgrihhlrdgtohhmpdhrtghpthht ohepphhgshhqlhdqghgvnhgvrhgrlheslhhishhtshdrphhoshhtghhrvghsqhhlrdhorh hg X-ME-Proxy: Feedback-ID: i76984098:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 1 Oct 2024 10:07:25 -0400 (EDT) Message-ID: <531a5550-dee1-4659-a2b8-45ad52fe7e11@aklaver.com> Date: Tue, 1 Oct 2024 07:07:25 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Question on session timeout To: sud Cc: pgsql-general References: <3133182a-35c4-4a81-be60-8ab227c0fbc0@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 9/30/24 22:57, sud wrote: > > > On Tue, Oct 1, 2024 at 4:10 AM Adrian Klaver > wrote: > /Where are you getting the ~2000  count from?/ > Seeing this in the "performance insights" dashboard and also its > matching when I query the count of sessions from pg_stat_activity. From your OP: "... whereas the total number of active sessions in pg_stat_activity staying <100 at any point in time." So: 1) They don't match. 2) ""performance insights" dashboard" does not actually tell us anything. What program and what is it actually measuring? > > /What do you mean by ~120 sets, in particular what is a set? > /These are the values set as mentioned in the properties file which the > application team uses for connection pooling Again this does not tell us anything. 1) A set of what? 2) What properties file? > > /Using what pooler? > /I need to check on this as Its Java application(jdbc driver for > connecting to DB), so I thought it must be using standard connection > pooling. Will double check. Since pooling is what you are concerned with this is should be the starting point of your investigation. > > /How often do to keep alive queries run? > /Need to check. But I am not sure, in general , if these "keep alive" > queries are used for keeping a transaction alive or a session alive? With an idle_in_transaction_session_timeout of 24 hrs I don't see that it makes a difference. > > As you described, a long time open transaction with a session state as > "idle" will be threatening as that will cause locking and "transaction That would be idle_in_transaction. > ID wrap around" issues to surface whereas having "idle sessions" of a > closed transaction may not cause any issue as they will do no harm. Does > it mean we can have any number of idle sessions or we should also have > some non zero "timeout" setup for the "ide_session_timeout" parameter > too (maybe ~1hr or so)? Other then it takes up connections. > > Is it correct to assume the session in pg_stat_activity with very old > XACT_START are the one which are part of long running open > transaction(i.e. driven by idle_in_transaction_session_timeout) whereas > the ones with older BACKEND_START or QUERY_START are the one are just > the idle session(driven by idle_session_timeout) but not tied to any > open transaction? I would read this descriptions here: https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ACTIVITY-VIEW > > Few observations:- > > I do see, "MaximumUsedTransactionIDs" staying consistently ~200M for a > long time then coming down. And its matching to > "autovacuum_freeze_max_age" which is set as 200M. Hope it's expected. We > have max_connections set as 5000. > > "Database connection" touching ~2000 then coming down till 200. And we > see uneven spikes in those, it seems to be matching with the pattern , > when we have some errors occurring during the insert queries which are > submitted by the Java application to insert the data into the tables. > This would have been a good thing to lead with. -- Adrian Klaver adrian.klaver@aklaver.com