Re: PostgresSQL 9.5.21 very slow to connect and perform basic queries

bruno da silva <brunogiovs@gmail.com>

From: bruno da silva <brunogiovs@gmail.com>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: pgsql-performance@lists.postgresql.org
Date: 2022-07-21T20:37:23Z
Lists: pgsql-performance
It has been running at least since 2018.

I got that from the tail

=> /sys/kernel/mm/ksm/run <==
0

==> /sys/kernel/mm/transparent_hugepage/defrag <==
[always] madvise never

==> /sys/kernel/mm/transparent_hugepage/enabled <==
always madvise [never]

==> /sys/kernel/mm/transparent_hugepage/khugepaged/defrag <==
[yes] no

==> /proc/sys/vm/zone_reclaim_mode <==
0


On Thu, Jul 21, 2022 at 4:32 PM bruno da silva <brunogiovs@gmail.com> wrote:

> Thanks, I will check it out.
>
> On Thu, Jul 21, 2022 at 4:21 PM Justin Pryzby <pryzby@telsasoft.com>
> wrote:
>
>> On Thu, Jul 21, 2022 at 03:59:30PM -0400, bruno da silva wrote:
>> >   OS/version: CentOS release 6.9 (Final)
>>
>> How are these set ?
>>
>> tail /sys/kernel/mm/ksm/run
>> /sys/kernel/mm/transparent_hugepage/{defrag,enabled,khugepaged/defrag}
>> /proc/sys/vm/zone_reclaim_mode
>>
>> I suspect you may be suffering from issues with transparent huge pages.
>>
>> I suggest to disable KSM and THP, or upgrade to a newer OS.
>>
>> I've written before about these:
>> https://www.postgresql.org/message-id/20170524155855.GH31097@telsasoft.com
>> https://www.postgresql.org/message-id/20190625162338.GF18602@telsasoft.com
>> https://www.postgresql.org/message-id/20170718180152.GE17566@telsasoft.com
>> https://www.postgresql.org/message-id/20191004060300.GA11241@telsasoft.com
>> https://www.postgresql.org/message-id/20200413144254.GS2228@telsasoft.com
>> https://www.postgresql.org/message-id/20220329182453.GA28503@telsasoft.com
>>
>> On Thu, Jul 21, 2022 at 04:01:10PM -0400, bruno da silva wrote:
>> > The issue started a month ago.
>>
>> Ok .. but how long has the DB been running under this environment ?
>>
>> --
>> Justin
>>
>
>
> --
> Bruno da Silva
>


-- 
Bruno da Silva

Commits

  1. Be more wary about 32-bit integer overflow in pg_stat_statements.