Hi Haomai, On Thu, Jan 29, 2015 at 9:46 PM, Haomai Wang <haomaiwang@xxxxxxxxx> wrote: > For metadata overhead, we need to resolve it at upper level, > keyvaluestore won't add extra metadata in normal io except rarely > header save which only update when header changed. Unfortunately, our write workload is dominated by object creates. > As for active write, why do you think it there only one active write > in keyvaluestore threads? I just check runtime perf data again, it > looks fine that multi write can do concurrently submit transaction. We've implemented a MySQL backend for KeyValueDB in the hopes of getting better performance than LevelDB (what we're currently seeing is on par). Internally, it uses a LIFO connection pool, from which connections are leased for the duration of a transaction commit or snapshot walk (to permit concurrent transactions). Watching the connection activity in MySQL using "SHOW PROCESSLIST", during most runs, it's clear that, for the duration of the write benchmark, all but two of the connections remain idle. (During cleanup, I do see more connections used, and I have on occasion seen more used during writes.) So while it's possible the transactions are being built concurrently, they aren't (or are with a very low probability) being submitted (via submit_transaction_sync()) concurrently. (It's entirely possible that a bug in our code, or misdocumented behavior in the MySQL client, excludes concurrent threads from using open MySQL connections, but I *have* seen concurrent transaction commits, only rarely.) You mention "runtime perf data", is there a simple way to query the OSD's idea of how many concurrent transaction submits it is issuing? In the meantime I'll instrument our backend to track this value itself. Thanks! -- 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
