Hi Merlin,
Its configured high value for max_conn, but active and idle session have never crossed the count 50.
DB Size: 20 GB
Table size: 30MB
RAM: 16GB
vC: 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 <mmoncure@xxxxxxxxx> wrote:
On Tue, Feb 18, 2020 at 12:40 PM Justin Pryzby <pryzby@xxxxxxxxxxxxx> 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
> 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
