Re: LDAP with TLS is taking more time in Postgresql 11.5

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: LDAP with TLS is taking more time in Postgresql 11.5
Дата
Msg-id CA+hUKG+L31qbQXYCkXfvf-Mz0r+1HEt9JvOzT-QK_CJogNGarQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: LDAP with TLS is taking more time in Postgresql 11.5  (Adrian Klaver <adrian.klaver@aklaver.com>)
Список pgsql-general
On Wed, Feb 26, 2020 at 7:37 AM Adrian Klaver <adrian.klaver@aklaver.com> wrote:
> On 2/25/20 10:23 AM, Mani Sankar wrote:
> > Hi Adrian,
> >
> > Both the machines are in same network and both are pointing towards the
> > same LDAP server
>
> I don't see any errors in the Postgres logs.
>
> You probably should take a look at the LDAP server logs to see if there
> is anything there.
>
> You could also turn up the logging detail in Postgres to see if it
> reveals anything.

A couple more ideas:

If you take PostgreSQL out of the picture and run the equivalent LDAP
queries with the ldapsearch command line tool, do you see the same
difference in response time?  If so, I'd trace that with strace etc
with timings to see where the time is spent -- for example, is it
simply waiting for a response from the LDAP (AD?) server?   If not,
I'd try tracing the PostgreSQL process and looking at the system calls
(strace -tt -T for high res times and elapsed times), perhaps using
PostgreSQL's pre_auth_delay setting to get time to attach strace.

A wild stab in the dark: if it's slow from one computer and not from
another, perhaps the problem has something to do with a variation in
reverse DNS lookup speed on the LDAP server side when it's verifying
the certificate.  Or something like that.



В списке pgsql-general по дате отправления:

Предыдущее
От: Ian Barwick
Дата:
Сообщение: Re: Highly academic: local etcd & Patroni Cluster for testing on asingle host
Следующее
От: Eric Gillum
Дата:
Сообщение: information_schema performance in Postgres 12