Return-Path: X-Original-To: oracle-l@orafaq.com Delivered-To: oracle-l@orafaq.com Received: from puck1183.startdedicated.com (localhost [127.0.0.1]) by puck1183.startdedicated.com (Postfix) with ESMTP id 5B00919610C2 for ; Fri, 11 Nov 2016 20:56:22 +0100 (CET) Received: from turing.freelists.org (turing.freelists.org [206.53.239.180]) by puck1183.startdedicated.com (Postfix) with ESMTPS for ; Fri, 11 Nov 2016 20:56:22 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 5EFB062010; Fri, 11 Nov 2016 14:56:21 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at turing.freelists.org Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2OL_rrLwS0l; Fri, 11 Nov 2016 14:56:21 -0500 (EST) Received: from turing.freelists.org (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 8469362008; Fri, 11 Nov 2016 14:56:08 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Fri, 11 Nov 2016 14:54:46 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 80D2561F88 for ; Fri, 11 Nov 2016 14:54:46 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voe-DWuVB6EY for ; Fri, 11 Nov 2016 14:54:46 -0500 (EST) Received: from mail-it0-f54.google.com (mail-it0-f54.google.com [209.85.214.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 5AE9D61ED1 for ; Fri, 11 Nov 2016 14:54:46 -0500 (EST) Received: by mail-it0-f54.google.com with SMTP id e187so345129033itc.0 for ; Fri, 11 Nov 2016 11:54:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OMky5cLkio+KtLNj4wF0AQamVEkulLTb5mh28oc0lTE=; b=Wi3RhfEsz8WjN63T87cEvCpEe4SPumXjdcrMyK8yu1ecDdmeJuRhgKTScLGQsXtI/s QzlTrByppKLn5/HvweqSbcFinDrlOl61VzrJN/RH4cwnQMGYRs7v5Wqk3tI03Eu77dUg L/+VR7CTmotZP+3Sawu1DzWa5RoP1ltmTUTv0GPzuTrmJfrw0d9W46oacfr6m9bHTbRu 1io2IqoAxMbvIvDK18I1Gt2ZfiLNfakyJR0QooO5kY++/5nISouXaxAOhxsV0MPsexOZ Z3M9dWaAf8+3h3NMaDx2tTQrl1zIcbSoo4/j+lX0NKznk+n+NCT3yVXi6AMwSrUfsObh I7FQ== X-Gm-Message-State: ABUngvccdwWZN8P54XVkJnu/4FcY+gxo7915q93C1t5VAOxPMpzH97SfX4xWa6Q9YnHFo5Us8Cn3kbZwbQRejw== X-Received: by 10.202.237.7 with SMTP id l7mr2017788oih.152.1478894076489; Fri, 11 Nov 2016 11:54:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.199.131 with HTTP; Fri, 11 Nov 2016 11:54:35 -0800 (PST) In-Reply-To: References: <441952295.2260945.1478884537701@mail.yahoo.com> From: Alfredo Abate Date: Fri, 11 Nov 2016 13:54:35 -0600 Message-ID: Subject: Re: jumbo frames with non rac To: Jeff Chirco Cc: kathy duret , "oracle-l@freelists.org" Content-Type: multipart/alternative; boundary=001a113d2d1a16f3c605410bdccb X-archive-position: 66820 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: alfredo.abate@gmail.com Precedence: normal Reply-To: alfredo.abate@gmail.com List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-subscribe: List-owner: List-post: List-archive: X-list: oracle-l --001a113d2d1a16f3c605410bdccb Content-Type: text/plain; charset=UTF-8 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 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 > 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 >> *To:* "oracle-l@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 >> >> >> > --001a113d2d1a16f3c605410bdccb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jeff,

My understanding of using jumbo f= rames with Oracle RAC is to be able to increase the packet size of the <= b>private interconnect (heartbeat) of the cluster for better perfor= mance.=C2=A0 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 t= he 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 s= ize (1500).=C2=A0 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 <= span dir=3D"ltr"><backseatdba@gmail.com> wrote:
Sorry yes Oracle Linux 7 here and with hugepages.= =C2=A0 11g database currently but plans to 12c.

On Fri, Nov 11, 2016 at 9:15 AM, ka= thy duret <katpopins21@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.=C2=A0

=
There are many papers on how to do set = this up.=C2=A0 I would look on MOS first and then go fro there.
<= /div>
=C2=A0
Kathy Duret
=C2=A0

=
From: Jeff Chirco <backseatdba@gmail.com&g= t;
To: "oracle-l@freelists.org= " <orac= le-l@freelists.org>
Sent: Friday, November 11, 2016 10:30 AM
Subject: jumbo frames with non rac
<= div>

We are in the middle of setting up replacing new databas= e servers and been wondering about jumbo frames.=C2=A0 We have 10gb network= and we don't run RAC and not sure if we ever will but wondering if the= re still is a big benefit for jumbo frames? We also are running a new NetAp= p 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 kno= wledgeable on the network side of things.

Thanks,
Jeff


<= /div>


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