Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Setting SDU and tcp.nodelay
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_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] 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_at_hotmail.com> 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
:-)
-- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Thu Sep 28 2006 - 08:10:13 CDT
![]() |
![]() |