[gpfsug-discuss] mmdf and maybe other commands long running // influence of n and B on number of regions

José Filipe Higino jose.filipe.higino at gmail.com
Sat Feb 8 11:59:54 GMT 2020


How many back end nodes for that cluster? and how many filesystems for that
same access... and how many pools for the same data access type (12 ndisks
sounds very LOW to me, for that size of a cluster, probably no other
filesystem can do more than that). On GPFS there are so many different ways
to access the data, that is sometimes hard to start a conversation. And you
did a very great job of introducing it. =)

We (I am a customer too) do not have that many nodes, but from experience,
I know some clusters (and also multicluster configs) depend mostly on how
much metadata you can service in the network and how fast (latency wise)
you can do it, to accommodate such amount of nodes. There is never design
by the book that can safely tell something will work 100% times. But the
beauty of it is that GPFS allows lots of aspects to be resized at your
convenience to facilitate what you need most the system to do.

Let us know more...

On Sun, 9 Feb 2020 at 00:40, Walter Sklenka <Walter.Sklenka at edv-design.at>
wrote:

> Hello!
>
> We are designing two fs  where we cannot anticipate if there will be 3000,
> or maybe 5000 or more nodes totally accessing these filesystems
>
> What we saw, was that execution time of mmdf can last 5-7min
>
> We openend a case and they said, that during such commands like mmdf or
> also mmfsck, mmdefragfs,mmresripefs all regions must be scanned at this is
> the reason why it takes so long
>
> The technichian also said, that it is “rule of thumb” that there should be
>
> (-n)*32 regions , this would then be enough ( N=5000 à 160000 regions per
> pool ?)
>
> (also Block size has influence on regions ?)
>
>
>
> #mmfsadm saferdump stripe
>
> Gives the regions number
>
>  storage pools: max 8
>
>
>
>      alloc map type 'scatter'
>
>
>
>       0: name 'system' Valid nDisks 12 nInUse 12 id 0 poolFlags 0
> thinProvision reserved inode -1, reserved nBlocks 0
>
>
>
>           *regns 170413* segs 1 size 4096 FBlks 0 MBlks 3145728 subblock
> size 8192
>
>
>
>
>
>
>
>
>
>
>
> We  also saw when creating the filesystem with a speciicic (-n)  very high
> (5000)  (where mmdf execution time was some minutes) and then changing (-n)
> to a lower value this does not influence the behavior any more
>
>
>
> My question is: Is the rule (Number of Nodes)x5000 for number of regios in
> a pool an good estimation ,
>
> Is it better to overestimate the number of Nodes (lnger running commands)
> or is it unrealistic to get into problems when not reaching the regions
> number calculated ?
>
>
>
> Does  anybody have experience with high number of nodes (>>3000)  and how
> to design the filesystems for such large clusters ?
>
>
>
> Thank you very much in advance !
>
>
>
>
>
>
>
> Mit freundlichen Grüßen
> *Walter Sklenka*
> *Technical Consultant*
>
>
>
> EDV-Design Informationstechnologie GmbH
> Giefinggasse 6/1/2, A-1210 Wien
> Tel: +43 1 29 22 165-31
> Fax: +43 1 29 22 165-90
> E-Mail: sklenka at edv-design.at
> Internet: www.edv-design.at
>
>
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20200209/9ca5418b/attachment-0002.htm>


More information about the gpfsug-discuss mailing list