Hello, On Wed, 18 May 2016 08:14:51 -0500 Brian Felton wrote: > At my current gig, we are running five (soon to be six) pure object > storage clusters in production with the following specs: > > - 9 nodes > - 32 cores, 256 GB RAM per node > - 72 6 TB SAS spinners per node (648 total per cluster) > - 7,2 erasure coded pool for RGW buckets > - ZFS as the filesystem on the OSDs with collocated journals > - Hammer release with rgw patches > > We are currently storing a few hundred TB of data across several hundred > MObjects. > > We have hit the following issues: > > - Filestore merge splits occur at ~40 MObjects with default settings. > This is a really, really bad couple of days while things settle. Could you elaborate on that? As in which settings affect this and what happens exactly as "merge splits" sounds like an oxymoron, so I suppose it's more of a split than a merge to be so painful? > - Realizing that, with erasure coding, scrubs have the same impact as > deep scrubs > - Scrubs causing a slew of blocked/slow requests and stale pgs > > - A handful of RGW issues > > As utilization has grown, the performance impact of scrubbing has become > much more noticeable, to the point that we've had to hand-roll software > to manage the scrubs and keep them at a very reduced rate. Scrubbing can be more often than not your enemy, especially as it currently only tells you that something is wrong after the fact, your data is most likely already corrupt (unless you run ZFS or BTRFS) and good luck finding out which PG has the good data. That said, if your cluster has issues with normal scrubs (never mind deep ones) even after tuning things down (like osd_scrub_sleep = 0.1) it's a clear sign to improve things as normal client operations are likely to cause a similar impact. Regards, Christian > SSD journals > are your friends, folks. Don't skimp. We are in the process of > retrofitting these clusters with SSD journals to help speed things up. > We are also evaluating BlueStore in Jewel to see how it compares to > LevelDB as well as different node configurations (less dense and with > SSD journals). > > Brian > > On Wed, May 18, 2016 at 12:54 AM, Blair Bethwaite > <blair.bethwaite@xxxxxxxxx > > wrote: > > > Hi all, > > > > What are the densest node configs out there, and what are your > > experiences with them and tuning required to make them work? If we can > > gather enough info here then I'll volunteer to propose some upstream > > docs covering this. > > > > At Monash we currently have some 32-OSD nodes (running RHEL7), though > > 8 of those OSDs are not storing or doing much yet (in a quiet EC'd RGW > > pool), the other 24 OSDs are serving RBD and at perhaps 65% full on > > average - these are 4TB drives. > > > > Aside from the already documented pid_max increases that are typically > > necessary just to start all OSDs, we've also had to up > > nf_conntrack_max. We've hit issues (twice now) that seem (have not > > figured out exactly how to confirm this yet) to be related to kernel > > dentry slab cache exhaustion - symptoms were a major slow down in > > performance and slow requests all over the place on writes, watching > > OSD iostat would show a single drive hitting 90+% util for ~15s with a > > bunch of small reads and no writes. These issues were worked around by > > tuning up filestore split and merge thresholds, though if we'd known > > about this earlier we'd probably have just bumped up the default > > object size so that we simply had fewer objects (and/or rounded up the > > PG count to the next power of 2). We also set vfs_cache_pressure to 1, > > though this didn't really seem to do much at the time. I've also seen > > recommendations about setting min_free_kbytes to something higher > > (currently 90112 on our hardware) but have not verified this. > > > > -- > > Cheers, > > ~Blairo > > _______________________________________________ > > ceph-users mailing list > > ceph-users@xxxxxxxxxxxxxx > > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > > -- Christian Balzer Network/Systems Engineer chibi@xxxxxxx Global OnLine Japan/Rakuten Communications http://www.gol.com/ _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |