Base path: ~/riak/deps/eleveldb/c_src/leveldb Intentional stall: db/db_impl.cc function DBImpl::MakeRoomForWrite() … see two "else if" clauses that contain Log() calls with "waiting / waiting 2". These are the two conditions in which the Google code intentionally stalls the caller via Wait().
Write throttle: in the first few lines of the same function, you will see the variable "throttle" used. This is the write throttle I implemented. Its implementation includes logic in db/version_set.h, which depends upon inputs sent to SetWriteRate() (version_set.h) and from GetBackgroundBacklog() (util/env_posix.cc). This is my second generation throttle. 1.2.0 contained a throttle that was added in a rush and was not responsive to the users' environment. 1.2.1 is more refined and utilizes direct measurements from actual write throughput. The write throttle was tested via 12 scenarios with data values ranging in size from 800 bytes to 130k and 2 to 64 vnodes. The most harsh was 130k with 64 vnodes, the next was 130k with 2 vnodes (this latter case simulates a vnode handoff which was failing with the 1.2.0 throttle). The goal: equivalent overall throughput, no stalls. What else? Matthew On Nov 2, 2012, at 3:13 PM, Dietrich Featherston wrote: > Hi Matthew, > > Thanks again for your help with this upgrade. You mentioned yesterday that we > might be seeing iowait times higher due to amortizing stalls over all writes > vice the stop-the-world scenario seen in previous versions. Would you mind > pointing me to the codepath where these stalls are forecasted and implemented? > > Thanks, > D > _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
