From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Adler <adler(at)pobox(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: vacuum slowed by syslogd |
Date: | 2004-01-14 04:36:19 |
Message-ID: | 29721.1074054979@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Michael Adler <adler(at)pobox(dot)com> writes:
> On many occasions, I've noticed that some PostgreSQL activity takes
> far longer than it previously did and that disabling syslogd addresses
> the symptoms.
> ...
> This evidence normally indicates a name resolution issue, but I'm not
> sure how to test for that beyond using "hostname -v -i".
I looked in Red Hat's bugzilla for similar issues, and found a mention
that syslogd tries to reverse-lookup the address it gets each message
from. A delay there could act as you describe. At least in recent RH
releases, you can start syslogd with the "-x" switch to disable this
lookup --- does that exist in Debian, and if so does it help?
I would expect any comparable resolution delays on the client side to
occur only once when a backend is started, not once per message, since
we only openlog() once per backend. So a delay on the syslogd side
seems a likely theory.
Something else you could do to investigate is to test whether syslogd
can log messages from other clients during these 10-second delays.
If it's hung trying to resolve a name, presumably messages from other
clients would get delayed too.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Enrico Ortmann | 2004-01-14 08:02:11 | Re: Are there programs to graph database schema? |
Previous Message | Michael Adler | 2004-01-14 03:10:31 | vacuum slowed by syslogd |