Re: Metadata Server (MDS) Hardware Suggestions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thank you both, cleared up a lot. 

Is there a performance metric in perf dump on the MDS' that I can see the active number of inodes/dentries? I'm guessing the mds_mem ino and dn metrics are the relevant ones?
http://paste.fedoraproject.org/303932/77466614/

Cheers,

Simon

> -----Original Message-----
> From: Gregory Farnum [mailto:gfarnum@xxxxxxxxxx]
> Sent: 17 December 2015 23:54
> To: John Spray
> Cc: Simon Hallam; ceph-users@xxxxxxxxxxxxxx
> Subject: Re:  Metadata Server (MDS) Hardware Suggestions
> 
> On Thu, Dec 17, 2015 at 2:06 PM, John Spray <jspray@xxxxxxxxxx> wrote:
> > On Thu, Dec 17, 2015 at 2:31 PM, Simon  Hallam <sha@xxxxxxxxx> wrote:
> >> Hi all,
> >>
> >>
> >>
> >> I’m looking at sizing up some new MDS nodes, but I’m not sure if my
> thought
> >> process is correct or not:
> >>
> >>
> >>
> >> CPU: Limited to a maximum 2 cores. The higher the GHz, the more IOPS
> >> available. So something like a single E5-2637v3 should fulfil this.
> >
> > No idea where you're getting the 2 core part.  But a mid range CPU
> > like the one you're looking at is probably perfectly appropriate.  As
> > you have probably gathered, the MDS will not make good use of large
> > core counts (though there are plenty of threads and various
> > serialisation/deserialisation parts can happen in parallel).
> 
> There's just not much that happens outside of the big MDS lock right
> now, besides journaling and some message handling. So basically two
> cores is all we'll be able to use until that happens. ;)
> 
> >
> >> Memory: The more the better, as the metadata can be cached in RAM
> (how much
> >> RAM required is dependent on number of files?).
> >
> > Correct, the more RAM you have, the higher you can set mds_cache_size,
> > and the larger your working set will be.
> 
> Note that "working set" there; it's only the active metadata you need
> to worry about when sizing things. I think at last count Zheng was
> seeing ~3KB of memory for each inode/dentry combo.
> -Greg


Please visit our new website at www.pml.ac.uk and follow us on Twitter  @PlymouthMarine

Winner of the Environment & Conservation category, the Charity Awards 2014.

Plymouth Marine Laboratory (PML) is a company limited by guarantee registered in England & Wales, company number 4178503. Registered Charity No. 1091222. Registered Office: Prospect Place, The Hoe, Plymouth  PL1 3DH, UK. 

This message is private and confidential. If you have received this message in error, please notify the sender and remove it from your system. You are reminded that e-mail communications are not secure and may contain viruses; PML accepts no liability for any loss or damage which may be caused by viruses.

_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com




[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux