From: Ross J. Reedstrom <reedstrm@rice.edu>
To: pgsql-performance@postgresql.org
Subject: Re: TCP network cost
Date: Tue, 17 Feb 2009 16:30:02 -0600
Message-ID: <20090217223002.GC23707@cooker> (raw)
In-Reply-To: <20090217211454.GB23707@cooker>
References: <20090217070403.GB2486@cooker>
<1ca1c1410902171013q478f2620n13fcd68cb8b3d911@mail.gmail.com>
<20090217070403.GB2486@cooker>
<3FAF940B-9B0B-4DBA-8728-6096022129DF@infogears.com>
<alpine.DEB.1.10.0902170032440.25606@asgard.lang.hm>
<20090217070403.GB2486@cooker>
<3FAF940B-9B0B-4DBA-8728-6096022129DF@infogears.com>
<20090217200416.GA23707@cooker>
<B7A2E4DA-A137-46F5-8643-2EF3772F4D2C@infogears.com>
<20090217211454.GB23707@cooker>
On Tue, Feb 17, 2009 at 03:14:55PM -0600, Ross J. Reedstrom wrote:
> On Tue, Feb 17, 2009 at 01:59:55PM -0700, Rusty Conover wrote:
> >
> > What is the client software you're using? libpq?
> >
>
> python w/ psycopg (or psycopg2), which wraps libpq. Same results w/
> either version.
>
It's not python networking per se's fault: sending the file via a
SimpleHTTPServer, adn fetching w/ wget takes on the order of 0.5 sec.
as well.
> I think I'll try network sniffing to see if I can find where the
> delays are happening.
I'm no TCP/IP expert, but some packet capturing, and wireshark analysis
makes me suspicious about flow control. the 'netcat' transfer shows lots
of packets from server -> client, w/ deltaTs of 8 - 200 usec (that's
micro-sec), mostly in the 10-20 range. The client -> server 'ack's seem
bursty, happening only every 50-100 packets, then a few back-to-back,
all taking 10-20 usec.
I also see occasional lost packets, retransmits, and TCP Window Updates
in this stream. FIN packet is after 8553 packets.
For the libpq driven transfer, I see lots of packets flowing both ways.
Seems about every other packet from server to client is 'ack'ed. Each of
these 'ack's takes 10 uS to send, but seem to cause the transfer to
'reset', since the next packet from the server doesn't arrive for 2-2.5
ms (that's milli-sec!) FIN happens at 63155 packets.
No lost packets, no renegotiation, etc.
Capturing a localhost transfer shows the same pattern, although now
almost every single packet from server -> client takes ~ 3 ms
So, TCP experts out there, what's the scoop? Is libpq/psycopg being very
conservative, or am I barking up the wrong tree? Are there network
socket properities I need to be tweaking?
Does framing up for TCP just take that long when the bits are coming
from the DB? I assume the unix-domain socket case still uses the full
postgresql messaging protocol, but wouldn't need to worry about
network-byte-order, etc.
All the postgres tunable knobs I can see seem to talk about disk IO,
rather than net IO. Can someone point me at some doco about net IO?
Ross
--
Ross Reedstrom, Ph.D. reedstrm@rice.edu
Systems Engineer & Admin, Research Scientist phone: 713-348-6166
The Connexions Project http://cnx.org fax: 713-348-3665
Rice University MS-375, Houston, TX 77005
GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: reedstrm@rice.edu
Subject: Re: TCP network cost
In-Reply-To: <20090217223002.GC23707@cooker>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox