Mailing List Archive: Netapp: toasters

V-series / WAFL performance / 20% free

Index | Next | Previous | View Threaded

skendric at fhcrc

Mar 15, 2012, 11:46 AM

Post #1 of 3 (593 views)
Permalink

V-series / WAFL performance / 20% free

Hi folks,

I'm familiar with the NetApp recommendation to keep ~20% free on all
volumes ... this allows WAFL to maximize its performance (convert random
IO to streaming IO ... i.e. the 'Write Anywhere ...' part of WAFL).

But I'm skeptical that this recommendation applies to V-Series
installations, i.e. situations in which the backend array was built by
someone other than NetApp.

Seems to me that with V-Series, WAFL may find what it thinks are 128K of
contiguous blocks on storage and perform the WRITE ... but ... since the
backend array has virtualized the blocks in some fashion, opaque to
ONTAP, there is no knowing what really happens. In other words, the
blocks which ONTAP specifies do /not/ map to physical blocks ... once
the WRITE arrives at the array, the backend will do whatever it thinks
best with them, perhaps perform a streaming write to contiguous blocks,
perhaps not. Implementation-specific.

-In fact, with a V-Series, I would imagine (I have a rich imagination)
that ONTAP doesn't bother to even try to convert random IO into
streaming IO -- I would imagine that it just hands the blocks to the
backend in a jumble and says "Do whatever".

So, I would like to claim that with V-Series, I can fill up my volumes
without impacting write performance ... or, more precisely, that impact
is dependent on the characteristics of the backend ... perhaps the
backend needs free space in order to optimize its write performance,
perhaps it does not. [.In our particular case, we're using 3Par, and
'fullness' would not impact performance.]

Would anyone see holes in my thinking?

--sk

Stuart Kendrick
FHCRC

_______________________________________________
Toasters mailing list
Toasters [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

michael.bergman at ericsson

Mar 15, 2012, 5:08 PM

Post #2 of 3 (573 views)
Permalink

Re: V-series / WAFL performance / 20% free [In reply to]

Stuart Kendrick wrote:
> But I'm skeptical that this recommendation applies to V-Series
> installations, i.e. situations in which the backend array was built by
> someone other than NetApp.

This is a very good general point -- one that I thought about a few years
back when theoretically looking at V-series + HP EVA 8400...

> Seems to me that with V-Series, WAFL may find what it thinks are 128K of
> contiguous blocks on storage and perform the WRITE ... but ... since the
> backend array has virtualized the blocks in some fashion, opaque to
> ONTAP, there is no knowing what really happens.

Exactly. Who knows what really happens. ONTAP will always create a RADI0
column on the "foreign" LUN(s) from the external storage. How it will treat
that differently (perhaps) when writing to it compared to a NetApp native
back-end, I have no idea.

> In other words, the blocks which ONTAP specifies do /not/ map to physical
> blocks ... once the WRITE arrives at the array, the backend will do
> whatever it thinks best with them, perhaps perform a streaming write to
> contiguous blocks, perhaps not. Implementation-specific.
>
> -In fact, with a V-Series, I would imagine (I have a rich imagination)
> that ONTAP doesn't bother to even try to convert random IO into
> streaming IO -- I would imagine that it just hands the blocks to the
> backend in a jumble and says "Do whatever".

Maybe. Who knows? Someone inside NetApp prod dev does of course -- I kinda
lost interest after a while and stopped thinking about it. Personally I
doubt that ONTAP treats the "foreign" back-ends very much differently
(except the simplification of just using RAID0), a lot of work/effort for
the NetApp Engineers, for what...?

> So, I would like to claim that with V-Series, I can fill up my volumes
> without impacting write performance ... or, more precisely, that impact
> is dependent on the characteristics of the backend ... perhaps the
> backend needs free space in order to optimize its write performance,
> perhaps it does not. [.In our particular case, we're using 3Par, and
> 'fullness' would not impact performance.]

Empirical knowledge is the path for you I think. Try it in your real
environment under your real workload and see what happens ;-)

You're running NetApp V-series + 3PAR from HP in a production setup? Wow. I
Wish you luck, hope you don't have a really difficult workload that will
pressure all this hard, as there's no way for you to predict how it's going
to behave in the end.

> Would anyone see holes in my thinking?

Not really, but I think you need wishes for luck all the same and I hope
your (NFS) workload is light. If it's anything like this... I'd be scared

CPU NFS CIFS Total Net kB/s Disk kB/s Cache Cache CP CP Disk
in out read write age hit time ty util
99% 50154 715 50881 93241 39351 252212 160002 6s 86% 81% F 20%
99% 48552 761 49321 93244 44761 300515 145389 0s 83% 74% 26 19
99% 46779 1010 47798 83425 35630 361639 202821 4 80% 97% 31 23
99% 40288 1023 41324 67574 53174 351792 180049 6 79% 92% 30 24
99% 43701 1070 44828 77962 89316 359056 171009 9 78% 94% 28 24
99% 41142 1301 42484 46582 78844 373385 147728 11 77% 94% 26 24
99% 40974 983 42045 47253 61140 357968 141166 12 76% 92% 26 26
99% 49657 652 50324 47562 44669 264335 92603 7 83% 85% 19 19
99% 52610 637 53255 77844 54978 253477 128584 6s 86% 80% 23 22
99% 47490 803 48305 61724 55596 274441 111016 6s 82% 74% 20 24
99% 50432 638 51078 48117 38057 263544 97620 0s 81% 83% 19 23

Regards,
M
--
Michael Bergman michael.bergman [at] ericsson
Sr Systems Analyst / Storage Architect
Ericsson AB Torshamnsg 33, 16480 Sthlm, Sweden
IT & Test Env, Engineering EMEA North Phone: +46 10 7152945
EAB/DCI/DAA, Engineering Hub Stockholm SMS/MMS: +46 70 5480835
--
"Utinam tam facile vera invenire possem quam falsa convincere!" - Cicero
_______________________________________________
Toasters mailing list
Toasters [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

skendric at fhcrc

Apr 4, 2012, 3:25 PM

Post #3 of 3 (501 views)
Permalink

Re: V-series / WAFL performance / 20% free [In reply to]

I'm realizing that I spoke inaccurately below ... here's my effort to
clean up my errors (without,
I'm hoping, introducing new ones):

-Keeping ~20% free on a heavily used aggregate makes sense
/operationally/ ... the applications
are likely to want space, and running out of space is generally
detrimental to application behavior.
But there is no particular /WAFL/ requirement for this.

-WAFL's de-dupe process wants a few percent free (~4%), in order to give
itself working space

-WAFL's write performance can benefit from contiguous free blocks ...
but WAFL reserves
~10% of an aggregate's space on creation for various functions,
including this one. So filling up
the user-accessible portion of the volume doesn't necessarily impact the
contiguous free block
situation.

-And yes, with V-Series, ONTAP no longer has visibility into physical
block layout, so this
discussion becomes moot.

hth,

--sk

On 3/15/2012 11:46 AM, Stuart Kendrick wrote:
> Hi folks,
>
> I'm familiar with the NetApp recommendation to keep ~20% free on all
> volumes ... this allows WAFL to maximize its performance (convert random
> IO to streaming IO ... i.e. the 'Write Anywhere ...' part of WAFL).
>
> But I'm skeptical that this recommendation applies to V-Series
> installations, i.e. situations in which the backend array was built by
> someone other than NetApp.
>
> Seems to me that with V-Series, WAFL may find what it thinks are 128K of
> contiguous blocks on storage and perform the WRITE ... but ... since the
> backend array has virtualized the blocks in some fashion, opaque to
> ONTAP, there is no knowing what really happens. In other words, the
> blocks which ONTAP specifies do /not/ map to physical blocks ... once
> the WRITE arrives at the array, the backend will do whatever it thinks
> best with them, perhaps perform a streaming write to contiguous blocks,
> perhaps not. Implementation-specific.
>
> -In fact, with a V-Series, I would imagine (I have a rich imagination)
> that ONTAP doesn't bother to even try to convert random IO into
> streaming IO -- I would imagine that it just hands the blocks to the
> backend in a jumble and says "Do whatever".
>
> So, I would like to claim that with V-Series, I can fill up my volumes
> without impacting write performance ... or, more precisely, that impact
> is dependent on the characteristics of the backend ... perhaps the
> backend needs free space in order to optimize its write performance,
> perhaps it does not. [.In our particular case, we're using 3Par, and
> 'fullness' would not impact performance.]
>
> Would anyone see holes in my thinking?
>
> --sk
>
> Stuart Kendrick
> FHCRC
>
_______________________________________________
Toasters mailing list
Toasters [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads