[XML-SIG] 20 second socket.addrinfo() delay in SimpleXMLRPCServer

Martin v. L÷wis martin@v.loewis.de
03 Jan 2003 09:26:22 +0100

Mark Bucciarelli <mark@easymailings.com> writes:

> How can I debug what's happening in the _socket.getaddrinfo() method?

You probably need to debug it on the C level. Most likely, you'll find
that getaddrinfo jumps into the DNS resolver code of libc, at which
point you can only debug it through recording the IP packets send by
your machine.

If you try to resolve the same host names interactively (e.g. by
passing them to traceroute), does that work better?

> Is this a known problem with Python 2.2.1?  GCC 3.2?  RedHat 8.0?  Linux 
> Kernel 2.4.18-14?  Dell Inspirons?

Likely none of these, although 20s does ring a bell: On Linux, name
lookups are cached through nscd, which is configured through
nscd.conf, which usually has a line

	negative-time-to-live	hosts		20

This says that negative lookups (host not found) stay 20s in the cache
until they are revalidated. I'm at a loss as to why this would cause
getaddrinfo to block for this timeout, though.

> The other strange behavor occurs in the python interpreter.  On
> occasion, when I type in a command like server =
> xmlrpclib.Server("http://localhost:8000") or server.echo('test'),
> the memory usage for the interpreter spikes (up to 75%, per "top")
> stays there for around three minutes, at which point the interpreter
> decides it's had enough and appends the string "Killed" and exits
> back to the command prompt.

The "killed" likely occurs through OOM, the Linux out-of-memory
killer. Linux, when it runs out of memory, choses an arbitrary victim
process to kill.

Now, the question would be why Python suddenly starts to consume so
much memory. Without investigating your application, it is impossible
to tell.