On 05/03/2016 12:23 PM, Sage Weil wrote:
On Tue, 3 May 2016, Gregory Farnum wrote:
In those leveldb tests we only saw writes and write trims hit by those
periodic 10-60 second high-latency spikes, but if I recall the mon has (or at
least had?) a global lock where write stalls would basically make the whole
monitor stall. I think Joao might have improved that after we did this
testing but I don't remember the details at this point.
I don't think any of this locking has changed...
The paxos state machine is no longer blocked for reads while an
unrelated write is happening. Nor are older-version reads on the
writing subsystem. That fix is post-firefly, right?
Oh yeah, it was new in hammer, I think. I forgot those tests were that
old!
Time goes by fast when you are having fun? Indeed those tests are
nearly 2 years old at this point.
I guess my question is given the state machine improvements do we expect
those leveldb write/wtrim latency spikes to still cause major mon
stalls? On the other hand, is the osdmap read cache enough to help
offset the lower read performance in (this configuration of) rocksdb?
I'm still worried about those big leveldb write latency spikes, but
maybe it's less of an issue now and the average read performance is a
bigger issue.
sage
--
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
