RE: Setting SDU and tcp.nodelay
- From: "Cary Millsap" <cary.millsap@xxxxxxxxxx>
- To: <gxallen@xxxxxxxxx>, "ORACLE-L" <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 28 Sep 2006 08:10:13 -0500
Exactly.
Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
Nullius in verba
Hotsos Symposium 2007 / March 4-8 / Dallas
Visit www.hotsos.com for curriculum and schedule details...
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Grant Allen
Sent: Wednesday, September 27, 2006 7:05 PM
To: ORACLE-L
Subject: Re: Setting SDU and tcp.nodelay
On 9/28/06, J. Dex <cemail_219@xxxxxxxxxxx> wrote:
> I want to try setting SDU for a 9207 database to see if it helps
performance
> issues that we are having since moving a database to another location
over a
> longer WAN (we have already eliminated other possible solutions). I
have
> read a couple of documents on Metalink but I am still not sure how to
know
> what to set SDU too? One doc said to set the SDU size as a multiple
of the
> MSS but I am not sure how to tell what the Maximum Segment Size is.
Another
> doc indicated that if the default is 2K, to double that and set it to
4096
> bytes. Has anyone else had to do this? Any suggestions?
>
> Also, are there any negative ramifications of having both tcp.nodelay
and
> SDU set?
Usually utterly pointless doing both. Tweaking SDU/TDU attempts to
have the highest possible payload per transport frame on the network
(e.g. as close as possible to 1514 bytes for an ethernet frame,
assuming jumbo frames aren't in use, allowing for overhead, etc.).
Setting tcp.nodelay disables the Nagle algorithm in the tcp stack that
tries to efficiently balance the data load of a packet with the delay
in dispatching it. Effectively, you're saying "to hell with
optimising the data payload ... send those babies now!". The complete
antithesis of what the SDU/TDU settings are trying to do for you.
You'll end up with a larger number of smaller packets on your WAN, and
if it's latency that's your problem, this will make matters worse, not
better.
My advice would be to go back to the workload the application is
generating, and ask some difficult questions about why it's doing what
it does ... e.g. can the queries, etc., be performed in fewer, more
tailored statements, requiring less traffic.
Just my 2c
Ciao
Fuzzy
:-)
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
