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?
Attachment:
gdb.create.rocksdb.xfs.log
Description: Binary data
