Networker

Re: [Networker] /nsr location and performance.

2009-07-22 06:50:34
Subject: Re: [Networker] /nsr location and performance.
From: "Joe N. Wallace" <joe.n.wallace AT GMAIL DOT COM>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Wed, 22 Jul 2009 20:43:30 +1000
huh, I always like it when someone here comes with some facts about what EMC
can do better on their documentation.

I just hope EMC is watching here and takes the point.

Support material would be so much better from EMC if they just would let
some tech people proof read before publishing.

2009/7/22 Yaron Zabary <yaron AT aristo.tau.ac DOT il>

> Hello all,
>
>   Recently I made a change to my setup which solved me a couple of problems
> and I thought some of you might find this information useful.
>
>   My Networker server is a Sun T1000 with an internal 160Gb SATA disk. The
> server is connected to an EMC AX150 which is used for AFTD. Obviously, the
> AX150 does heavy I/O during backups and staging (over 50Mb/s). In the
> previous setup, /nsr was a ZFS filesystem on the AX150 (actually a link). In
> the new setup /nsr was moved to the internal SATA disk. Due to disk space
> limit on the internal disk, the indexes (/nsr/index) are still on the AX150.
> This change solved several problems we had, such as RPC timeouts during
> backups, non-responsive nsrd (nsrwatch not updating for minutes), slow
> mminfo and very slow bootstrap backup.
>
>  It seems that although one might be tempted to place /nsr on a large RAID
> array, it is important that it will have good performance which your typical
> AFTD array will probably be unable to deliver while busy.
>
>  On a side note, while writing this, I went to the useless Performance
> Tuning Guide to see if the best location for /nsr was mentioned (and just to
> see if things have improved since I last went over it), but couldn't find
> any discussion about it. I did find some improvements, such as the
> statement: "For example, there is no system which can fully sustain 8 by
> LTO3 (considered normal practice in many environments)."). It is still a bad
> guide which still considers FDDI as a network upgrade (on page 32). This
> looks even worse, because on page 31 they discuss contemporary hardware such
> as "a mid-size system with 4 by 1-Gbit, NICs". As always, it seems that
> nobody didn't bother to read it end to end. I am quite sure that if any EMC
> engineer will spend just two hours to proof read it, many of its problems
> can be eliminated. In its current state, this guide simply demonstrates
> EMC's disrespect to their loyal paying customers.
>
> --
>
> -- Yaron.
>
> To sign off this list, send email to listserv AT listserv.temple DOT edu and 
> type
> "signoff networker" in the body of the email. Please write to
> networker-request AT listserv.temple DOT edu if you have any problems with 
> this
> list. You can access the archives at
> http://listserv.temple.edu/archives/networker.html or
> via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
>

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

<Prev in Thread] Current Thread [Next in Thread>