The tests I performed were from an aggregate of 46 10k drives to another identical aggregate on the other controller.  We used a 500g tar.gz file.  Should be comparable to a lun, ya think?

1.5Gb was the steady transfer rate.  1500 mtu, of course. 

----
Scott Eno
s.eno@me.com

On Feb 20, 2013, at 12:13 PM, Darren Sykes <Darren.Sykes@csr.com> wrote:

If someone could get >5Gb/s (say) backing up a large iSCSI LUN on a dedicated volume then it’d be fairly easy to determine there isn’t an inherent limit in using NDMP.

 

 

 

From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of tmac
Sent: 20 February 2013 16:31
To: Jeff Mohler
Cc: toasters@teaparty.net
Subject: Re: NDMP speed question

 

Adding to my list:

 

Collecting and disseminating File History

(which takes significantly longer the more files there are in the file system).

 

As a point of reference, I *cannot* do any NDMP backups on nearly all of my filesystems.

 

I have so many files that it takes over 8 hours to do the file history phase and the NDMP

backup simply aborts.


--tmac

 

Tim McCarthy

Principal Consultant

 

<~WRD000.jpg>     <~WRD000.jpg>     <~WRD000.jpg>

 

Clustered ONTAP                                                        Clustered ONTAP

 NCDA ID: XK7R3GEKC1QQ2LVD        RHCE5 805007643429572      NCSIE ID: C14QPHE21FR4YWD4

 Expires: 08 November 2014                 Expires w/release of RHEL7      Expires: 08 November 2014

 

On Wed, Feb 20, 2013 at 11:21 AM, Jeff Mohler <speedtoys.racing@gmail.com> wrote:

NDMP has phases, and other work to do.   I think with the info here, its far too early to declare NDMP at fault.




On Wed, Feb 20, 2013 at 7:27 AM, Christopher S Eno <s.eno@me.com> wrote:

Thanks Tim!

 

The thought here was that NDMP was “built for speed” and should be taking all it can get from the 10GbE pipe.  I was wondering if I was missing some hidden setting that was capping or throttling or “nice”-ing the NDMP process.

 

 

From: tmac [mailto:tmacmd@gmail.com]
Sent: Wednesday, February 20, 2013 9:31 AM
To: Christopher S Eno
Cc: toasters@teaparty.net
Subject: Re: NDMP speed question

 

DUMPing data is historically a slow process. There is much more involved than simply

FTP'ing data to the NetApp.

 

The filesystem is walked inode by inode and archive bits are set among other things.

 

--> A highly fragmented data set will also slow down any potential dumps.

--> Wide directories (large file counts in a single directory) significantly slow down dumps

--> Small files slow down dumps.

 

*--> qtree dumps seem to be a little better for dump speed


--tmac

 

Tim McCarthy

Principal Consultant

 


Error! Filename not specified.     Error! Filename not specified.     Error! Filename not specified.

 

Clustered ONTAP                                                        Clustered ONTAP

 NCDA ID: XK7R3GEKC1QQ2LVD        RHCE5 805007643429572      NCSIE ID: C14QPHE21FR4YWD4

 Expires: 08 November 2014                 Expires w/release of RHEL7      Expires: 08 November 2014

 

On Wed, Feb 20, 2013 at 9:03 AM, Christopher S Eno <s.eno@me.com> wrote:

Hi,

In testing NDMP dumps over 10GbE, I am seeing it max out at 1.5Gb/s.  Some
here are thinking that NDMP should be using more of that pipe.  Anyone know
about, or have numbers of NDMP transfer rates over 10GbE?  Any caps or
thresholds in OnTap that keep NDMP from gobbling up resources on the
controller?  I have run tests over the 10GbE connection from controller to
controller, 10k drives to 10k drives, sata drives to sata drives, and always
1.5Gb/s is the ceiling.  FTP'ing data from server to server across the same
10GbE network shows rates of 2.5Gb/s or higher.

My NDMP options:

ndmpd.access                 all
ndmpd.authtype               challenge
ndmpd.connectlog.enabled     off
ndmpd.data_port_range        all
ndmpd.enable                 on
ndmpd.fh_node_retry_interval 250
ndmpd.ignore_ctime.enabled   off
ndmpd.maxversion             4
ndmpd.offset_map.enable      on
ndmpd.password_length        16
ndmpd.preferred_interface    e1a        (value might be overwritten in
takeover)
ndmpd.tcpnodelay.enable      on
ndmpd.tcpwinsize             65534



IF e1a configuration:

e1a: flags=0x5f4e867<UP,BROADCAST,RUNNING,MULTICAST,TCPCKSUM,NOWINS> mtu
1500
        inet x.x.x.x netmask 0xffffff00 broadcast x.x.x.x
        partner e1a (not in use)
        ether 00:07:43:08:98:ae (auto-10g_sr-fd-up) flowcontrol none


_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

 


_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters



--
---
Gustatus Similis Pullus

 

 

To report this email as spam click here.



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters