Re: BUG #17269: Why is virtual memory usage of PostgreSQL growing constantly?

From: 菊池祐 <y(dot)kikuchi0714(at)gmail(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17269: Why is virtual memory usage of PostgreSQL growing constantly?
Date: 2021-11-09 06:52:51
Message-ID: CAGS+-sQhn--LSHWMk_EseU7H70yTrktz2=jHOXbX7DTZ6Sss=w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Thank you for the useful information.
I checked the number of connections, and I found there are about 3,000
connections from clients now.
I try to reduce it.

Let me check additionally.
1. This event that the virtual memory usage of PostgreSQL grows is due to a
large number of connections.
2. I didn't know that the moderate setting of max_connection is 100 to 200
or 300 on
a 128GB box. Where is it written in the PostgreSQL manual?

Best regards,
Yu Kikuchi

2021年11月8日(月) 10:00 Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>:

> At Fri, 5 Nov 2021 18:15:01 +0900, 菊池祐 <y(dot)kikuchi0714(at)gmail(dot)com> wrote in
> > I attached postgresql.conf file.
>
> > max_connections = 10000 # (change requires restart)
>
> I think the moderate setting of max_connection is 100 to 200 or 300 on
> a 128GB box. Depending on workload but it seems that you need to
> reduce it to the same range. 1000 might be possible for super-light
> weight workload but it is almost definite that 10000 don't fit 128GB
> memory, or on CPUs with 16-32 cores.
>
> I'm sure the clients are executing queries with quite low
> frequency. Maybe you want to use connection pooler such like Pgpool-II
> or pgbouncer, yandex/odyssey if the clients need to maintain their
> connections to the server for a long time.
>
> regards.
>
> --
> Kyotaro Horiguchi
> NTT Open Source Software Center
>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Semab Tariq 2021-11-09 06:55:57 Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data
Previous Message Noah Misch 2021-11-09 06:42:17 Re: BUG #17268: Possible corruption in toast index after reindex index concurrently