On Tue, Nov 28, 2017 at 1:51 AM, Xuehan Xu <xxhdx1985126@xxxxxxxxx> wrote: > Hi, everone. > > Recently, we did some stress tests on mds. We found that, when doing > file creation test, the mdlog trim operations are very slow. After > doing some debugging, we found that this could be due to execution of > the OSD's filestore theads being forced to be nearly sequential. This > can be found out in our result of gdbprof probing, which is attached > with this email. In the gdbprof result, we can see that the most time > consuming work of the filestore threads is the sizing of > DBObjectMap::caches, and the reason of sequential execution of > filestore threads is the locking of DBObjectMap::header_lock. > > After reading the corresponding source code, we found that > MapHeaderLock is already doing the mutual exclusion of access of the > omap object header. It seems that the locking of > DBObjectMap::header_lock is not very necessary, or at least, it's not > needed when adding the header to DBObjectMap::caches, which would lead > to the sizing of the cache. > > Is this right? I'm a bit confused; can you explain exactly what you're testing and exactly what you're measuring that leads you to think the mutexes are overly expensive? Note that there's both a header_lock and a cache_lock; in a quick skim they don't seem to be in gratuitous use (unless there are some disk accesses hiding underneath the header_lock?) and the idea of them being a performance bottleneck has not come up before. -Greg -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
