Re: jumbo frames with non rac

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_at_gmail.com
> <mailto:tim.evdbt_at_gmail.com>> 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_at_comcast.net <mailto:Dimensional.dba_at_comcast.net>*
>>
>> *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_at_freelists.org
>> <mailto:oracle-l-bounce_at_freelists.org>
>> [mailto:oracle-l-bounce_at_freelists.org
>> <mailto:oracle-l-bounce_at_freelists.org>] *On Behalf Of *Alfredo Abate
>> *Sent:* Friday, November 11, 2016 11:55 AM
>> *To:* Jeff Chirco
>> *Cc:* kathy duret; oracle-l_at_freelists.org
>> <mailto:oracle-l_at_freelists.org>
>> *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_at_gmail.com <mailto:backseatdba_at_gmail.com>> 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_at_yahoo.com <mailto:katpopins21_at_yahoo.com>> 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_at_gmail.com
>> <mailto:backseatdba_at_gmail.com>>
>> *To:* "oracle-l_at_freelists.org <mailto:oracle-l_at_freelists.org>"
>> <oracle-l_at_freelists.org <mailto:oracle-l_at_freelists.org>>
>> *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
>>
>
>

--
http://www.freelists.org/webpage/oracle-l