From: Ross J. Reedstrom <reedstrm@rice.edu>
To: pgsql-performance <pgsql-performance@postgresql.org>
Subject: Re: TCP network cost
Date: Tue, 17 Feb 2009 14:04:17 -0600
Message-ID: <20090217200416.GA23707@cooker> (raw)
In-Reply-To: <1ca1c1410902171013q478f2620n13fcd68cb8b3d911@mail.gmail.com> <alpine.DEB.1.10.0902170032440.25606@asgard.lang.hm> <3FAF940B-9B0B-4DBA-8728-6096022129DF@infogears.com>
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>
On Tue, Feb 17, 2009 at 12:20:02AM -0700, Rusty Conover wrote:
>
>
> Try running tests with ttcp to eliminate any PostgreSQL overhead and
> find out the real bandwidth between the two machines. If its results
> are also slow, you know the problem is TCP related and not PostgreSQL
> related.
I did in fact run a simple netcat client/server pair and verified that I
can transfer that file on 0.12 sec localhost (or hostname), 0.35 over the
net, so TCP stack and network are not to blame. This is purely inside
the postgresql code issue, I believe.
On Tue, Feb 17, 2009 at 10:13:40AM -0800, Aaron Turner wrote:
>
> TCP has additional overhead as well as going through the IP stack
> which for non-tuned Linux kernels is pretty limiting.
Right. Already tuned those so long ago, I failed to mention it. Note the
'bare' transfer times added above. Nothing to write home about
(~3Mb/sec) but another order of magnitude faster than the postgresql
transfer.
> long story short, there are things in /proc you can use to increase
> buffers and window sizes which will help with large TCP streams (like
> a 40MB file for example). There's a lot of documentation on the net
> for how to tune the Linux IP stack so I won't repeat it here.
>
> Now, having your DB box 5 hops away is going to add a lot of latency
> and any packet loss is going to kill TCP throughput- especially if you
> increase window sizes. I'd recommend something like "mtr" to map the
> network traffic (make sure you run it both ways in case you have an
> asymmetric routing situation) for a long period of time to look for
> hiccups.
The 5-hops in on campus, gigabit all the way, w/ reasonable routing -
and not the issue: I see the same times from another machine attaached
to the same switch (which is the real use-case, actually.)
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: <20090217200416.GA23707@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