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
>
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 |