On Fri, Jan 30, 2015 at 11:41 PM, Chris Pacejo <cpacejo@xxxxxxxxxxxxxxxx> wrote: > 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! It's really a surprise that you impl a MySQL backend. Could I know the purpose? Because it may not fit with keyvaluestore I think. You can simply calculate the sum of submit_transaction_sync consuming time, it would be the multiple of the op thread number. -- Best Regards, Wheat -- 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
