Jeff,
Hopefully, specific subnets have been configured for network-attach
storage (NAS) and/or backup traffic only, segregated from
general-purpose public networks. This will make reconfiguring
intermediate devices (i.e. switches, routers, etc) to jumbo frames a
less-intrusive project.
Good luck,
-Tim
On 11/11/16 13:50, Jeff Chirco wrote:
Thanks Tim well point. I think at this point for us it is more of a proactive preventive measure. We are in the process of moving our database servers from Windows to Linux so I say why not just go with jumbo frames now if it is not too much cost and trouble especially with all the testing we will be doing for the OS conversion. Better than trying to do it later.
Jeff
On Fri, Nov 11, 2016 at 12:44 PM, Tim Gorman <tim.evdbt@xxxxxxxxx <mailto:tim.evdbt@xxxxxxxxx>> wrote:
To augment what both Matthew and Alfredo have said...
TCP "jumbo frames" are used mainly with network-attached storage
(i.e. NFS, iSCSI, etc) and for special use-cases like the Oracle
RAC interconnect. The standard 1500-byte packets are sized to
optimally accommodate network traffic ranging from acknowledgement
messages of a few bytes to database storage traffic of 8192 bytes
and larger.
Larger packet sizes doesn't make the packets move any faster over
the wire or through switches and routers, but simply results in
fewer packets because an 8192-byte database block fits within one
9000-byte packet, instead of requiring six 1500-byte packets. This results in fewer un-marshalling operations on the source
server and fewer marshalling operations on the destination server,
so the ultimate increase in network throughput actually comes from
less CPU consumption by the servers on either end of the network
connection. The CPU savings on each server, as well as the
network throughput, can be significant, but when there is a
consistently high volume of such large-packet traffic. In
low-volume situations, it is difficult to measure any benefit.
CPU-saturated servers using network-attached storage without jumbo
frames can result in poor I/O performance without network
saturation being detectable. DBAs will report the poor I/O
latency and throughput over NFS storage, but the network
administrator will correctly respond that there is no network
throughput or latency issues. Meanwhile, server administrators
will surely detect the CPU saturation, but not associate it with
the poor I/O performance over NAS, likely because they won't be
involved in the I/O performance discussion, and neither the DBA
nor the network admin will make the connection.
So, deploying jumbo frames can be a reactive measure when CPU
saturation is detected and associated to NAS I/O issues, or it can
be a proactive measure to prevent that situation.
On 11/11/16 13:10, Dimensional DBA wrote:
As Alfredo mentions you normally don’t use jumbo frames on the
public facing networks as none of the clients normally have jumbo
frames setup. This could be different if you were using say
citrix desktops and ewveryone used those to access their
applications then what you want may work.
I have also used jumbo frames on storage networks to netapps or
other network storage.
*Matthew Parker*
*Chief Technologist*
*Dimensional DBA*
*425-891-7934 <tel:425-891-7934> (cell)*
*D&B *047931344**
*CAGE *7J5S7**
*Dimensional.dba@xxxxxxxxxxx <mailto:Dimensional.dba@xxxxxxxxxxx>*
*View Matthew Parker's profile on LinkedIn*
<http://www.linkedin.com/pub/matthew-parker/6/51b/944/>
www.dimensionaldba.com <http://www.dimensionaldba.com/>
*From:*oracle-l-bounce@xxxxxxxxxxxxx
<mailto:oracle-l-bounce@xxxxxxxxxxxxx>
[mailto:oracle-l-bounce@xxxxxxxxxxxxx
<mailto:oracle-l-bounce@xxxxxxxxxxxxx>] *On Behalf Of *Alfredo Abate
*Sent:* Friday, November 11, 2016 11:55 AM
*To:* Jeff Chirco
*Cc:* kathy duret; oracle-l@xxxxxxxxxxxxx
<mailto:oracle-l@xxxxxxxxxxxxx>
*Subject:* Re: jumbo frames with non rac
Jeff,
My understanding of using jumbo frames with Oracle RAC is to be
able to increase the packet size of the */private interconnect/*
(heartbeat) of the cluster for better performance. This is
normally done on segregated switches (or switch ports), NICs, etc
so that they are all configured for the larger MTU size (9000).
If you are considering enabling jumbo frames on the *public
network* of a single instance (or even RAC) database server that
your application servers or end users will directly be connecting
to it can cause issues since most networks are configured for the
normal MTU size (1500). This mismatch will potentially cause
network issues such as packet drops when the two devices are
communicating with each other.
Alfredo
On Fri, Nov 11, 2016 at 12:38 PM, Jeff Chirco
<backseatdba@xxxxxxxxx <mailto:backseatdba@xxxxxxxxx>> wrote:
Sorry yes Oracle Linux 7 here and with hugepages. 11g database
currently but plans to 12c.
On Fri, Nov 11, 2016 at 9:15 AM, kathy duret
<katpopins21@xxxxxxxxx <mailto:katpopins21@xxxxxxxxx>> wrote:
I am assuming Linux here ...
You will also need to set up hugepages and there are some other
settings to consider like semaphores.
There are many papers on how to do set this up. I would look on
MOS first and then go fro there.
*Kathy Duret*
**
------------------------------------------------------------------------
*From:*Jeff Chirco <backseatdba@xxxxxxxxx
<mailto:backseatdba@xxxxxxxxx>>
*To:* "oracle-l@xxxxxxxxxxxxx <mailto:oracle-l@xxxxxxxxxxxxx>"
<oracle-l@xxxxxxxxxxxxx <mailto:oracle-l@xxxxxxxxxxxxx>>
*Sent:* Friday, November 11, 2016 10:30 AM
*Subject:* jumbo frames with non rac
We are in the middle of setting up replacing new database servers
and been wondering about jumbo frames. We have 10gb network and
we don't run RAC and not sure if we ever will but wondering if
there still is a big benefit for jumbo frames? We also are
running a new NetApp all flash storage.
From what I have read so far is yes there is a benefit but just
wondering if anyone has any opinions? I am not very knowledgeable
on the network side of things.
Thanks,
Jeff
