On Sat, January 12, 2008 6:50 pm, Tom Lane wrote:
> "henry" <henry@zen.co.za> writes:
>> I have tried setting tcp_keepalives_idle = 120 (eg), then restarting PG,
>> but SHOW ALL; shows tcp_keepalives_idle=0 (ignoring my setting).
>
> Just FYI, this is the expected behavior on platforms where the kernel
> doesn't allow adjustment of the TCP keepalive parameters from
> userspace. You didn't say what you are running the server on, but
> the reference to /proc/sys makes me think it's Linux ... which seems
> odd, because modern Linuxen do allow these things to be adjusted.
Yes, this is on Linux - adjusting the param under /proc/sys works as
expected, but doesn't seem to have an effect on my prob.
> [ thinks... ] Maybe you were inspecting the value in a Unix-socket
> connection instead of a TCP connection?
See below (not sure I understand when you ask 'inspecting').
> This is all irrelevant to your real problem, to judge by the rest of
> the thread, but I'm curious.
I did in fact find a leak in long-lived procs (some of which can run for
days) - but squashing that did not make my problem go away. In fact,
these procs are connecting to port TCP 5432 - not a socket
(/tmp/.s.PGSQL.5432), TCP connections to 5432 come and go nicely in sync
with the number of active procs.
The number of /tmp/.s.PGSQL.5432 connections just keep growing... I have
no idea what's causing it.
lsof doesn't tell me what's talking to PG through /tmp/.s.PGSQL.5432
either. Maybe I'm not understanding exactly how /tmp/.s.PGSQL.5432 is
used - what would connect to PG via a domain socket? procs which don't
explicitly use -p5432, or some other mechanism which I'm ignorant of?
If I could just figure out what the hell's using /tmp/.s.PGSQL.5432 then I
could get a handle on the problem.
Increasing max_connections to cope without understanding what's happening
is an irritation (although that could be what's required in the final
analysis anyway). It's currently set to 2048, which gets masticated in
several hours (a result which doesn't make sense considering the number of
active procs) - and I haven't really started using the cluster/s to the
full potential yet.
Any suggestions/pointers are greatly appreciated.
Regards
Henry