Hi Merlin, Its configured high value for max_conn, but active and idle session have never crossed the count 50. DB Size: 20 GBTable size: 30MBRAM: 16GBvC: 4
yes, its view earlier I posted and here is there query planner for new actual view, "Append (cost=0.00..47979735.57 rows=3194327000 width=288)"" -> Seq Scan on msghist (cost=0.00..15847101.30 rows=3162700000 width=288)"" -> Seq Scan on msghist msghist_1 (cost=0.00..189364.27 rows=31627000 width=288)" Thanks,Rj On Tuesday, February 18, 2020, 10:51:02 AM PST, Merlin Moncure <mmonc...@gmail.com> wrote: On Tue, Feb 18, 2020 at 12:40 PM Justin Pryzby <pry...@telsasoft.com> wrote: > This is almost certainly unrelated. It looks like that query did a seq scan > and accessed a large number of tuples (and pages from "shared_buffers"), which > the OS then shows as part of that processes memory, even though *shared* > buffers are not specific to that one process. Yeah. This server looks highly overprovisioned, I'm in particularly suspicious of the high max_connections setting. To fetch this out I'd be tracking connections in the database, both idle and not idle, continuously. The solution is most likely to install a connection pooler such as pgbouncer. merlin
