On many occasions, I've noticed that some PostgreSQL activity takes far longer than it previously did and that
disablingsyslogd addresses the symptoms.
Most recently, it took 20-60 seconds to VACUUM a small, heavily updated table, while it used to take a fraction of a
second.I found syslog entries like these:
13:19:53 --Relation sometable--
13:20:03 Removed 2 tuples in 1 pages.
13:20:23 ^ICPU 0.00s/0.00u sec elapsed 0.00 sec.
13:20:54 Pages 1: Changed 1, Empty 0; Tup 4: Vac 2, Keep 0, UnUsed 13.
13:20:54 ^ITotal CPU 0.00s/0.00u sec elapsed 60.12 sec.
It took almost-exactly 60 seconds, but virtually no CPU time was used (and no disk IO). Many similar examples have
"real"times that are near perfect multiples of 10 seconds (e.g. 50.09, 40.07). This is not every single VACUUM, but it
isfrequent.
The problem disappears when syslogd is stopped or when PostgreSQL disables syslog usage. This is very consistent and I
canreproduce the problem in some installations by toggling these factors on and off.
The other way to toggle the problem on/off is to disable syslogd's udp socket (though this is a feature we'd still like
touse).
This evidence normally indicates a name resolution issue, but I'm not sure how to test for that beyond using "hostname
-v-i".
This has happened at several installations. We use both 7.2.1 (Debian stable) and 7.3.2 (Debian testing).
I would guess that this is not the result of a PostgreSQL deficiency, but it is most sharply affected by it. Perhaps
someonecan offer insight?
Thanks,
Mike Adler
