> -----Original Message----- > From: ceph-users [mailto:ceph-users-bounces@xxxxxxxxxxxxxx] On Behalf Of > Gregory Farnum > Sent: 04 June 2015 21:22 > To: Nick Fisk > Cc: ceph-users@xxxxxxxxxxxxxx > Subject: Re: Old vs New pool on same OSDs - Performance > Difference > > On Thu, Jun 4, 2015 at 6:31 AM, Nick Fisk <nick@xxxxxxxxxx> wrote: > > > > Hi All, > > > > I have 2 pools both on the same set of OSD’s, 1st is the default rbd pool > created at installation 3 months ago, the other has just recently been > created, to verify performance problems. > > > > As mentioned both pools are on the same set of OSD’s, same crush ruleset > and RBD’s on both are identical in size, version and order. The only real > difference that I can think of is that the existing pool as around 5 million > objects on it. > > > > Testing using RBD enabled fio, I see the newly created pool get an > expected random read IO performance of around 60 iop’s. The existing pool > only gets around half of this. New pool latency = ~15ms Old pool latency = > ~35ms for random reads. > > > > There is no other IO going on in the cluster at the point of running these > tests. > > > > XFS fragmentation is low, somewhere around 1-2% on most of the disks. > Only difference I can think of is that the existing pool has data on it where > the new one is empty apart from testing RBD, should this make a difference? > > > > Any ideas? > > > > Any hints on what I can check to see why latency is so high for the existing > pool? > > > > Nick > > Apart from what Somnath said, depending on your PG counts and > configuration setup you might also have put enough objects into the cluster > that you have a multi-level PG folder hierarchy in the old pool. I wouldn't > expect that to make a difference because those folders should be cached in > RAM, but if somehow they're not that would require more disk accesses. > > But more likely it's as Somnath suggests and since most of the objects don't > exist for images in the new pool it's able to put back ENOENT on accesses > much more quickly. > -Greg Thanks for the replies guys. I had previously completely written to both test RBD's until full. Strangely, I have just written to them both again and then dropped caches on all OSD nodes. Now both seem to perform the same but at the speed of the faster pool. I have then pointed fio at another existing RBD on the old pool and the results are awful, averaging under 10 iops for 64k random read QD=1. Unfortunately this RBD has live data on it, so can't overwrite it. But something seems up with RBD's (or the underlying objects) that have had data written to them a while back. If I make sure the data is in the pagecache, then I get really great performance, so it must be something to do with reading data off the disk, but I'm lost as to what it might be. Iostat doesn't really show anything interesting, but I'm guessing a single thread read over 40 disks wouldn't anyway. Are there any counters I could look at that might help to break down the steps the OSD goes through to do the read to determine where the slow down comes from? > _______________________________________________ > ceph-users mailing list > ceph-users@xxxxxxxxxxxxxx > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |