The dynamic snitch only reduces the chance that a node used in a read operation, it depends on the RF, the CL for the operation, the partitioner and possibly the network topology. Dropping read messages is ok, so long as your operation completes at the requested CL.
Are you using either a key_cache or a row_cache ? If so have you enabled the background save for those as part of the column definition? If this is about getting the OS caches warmed up you should see the pending count on the READ stage backup up and the io stats start to show longer queues. In that case Peters suggestion below is prob the best option. Another hacky way to warm things would be to use get_count() on rows the app thiks it may need to use. This will cause all the columns to be read from disk, but not sent over the network. Aaron On 20 Apr 2011, at 00:41, Héctor Izquierdo Seliva wrote: > Shouldn't the dynamic snitch take into account response times and ask a > slow node for less requests? It seems that at node startup, only a > handfull of requests arrive to the node and it keeps up well, but > there's moment where there's more than it can handle with a cold cache > and starts droping messages like crazy. > > Could it be the transition from slow node to ok node is to steep? > > > El vie, 15-04-2011 a las 16:19 +0200, Peter Schuller escribió: >>> Hi everyone, is there any recommended procedure to warm up a node before >>> bringing it up? >> >> Currently the only out-of-the-box support for warming up caches is >> that implied by the key cache and row cache, which will pre-heat on >> start-up. Indexes will be indirectly preheated by index sampling, to >> the extent that they operating system retains them in page cache. >> >> If you're wanting to pre-heat sstables there's currently no way to do >> that (but it's a useful feature to have). Pragmatically, you can >> script something that e.g. does "cat path/to/keyspace/* > /dev/null" >> or similar. But that only works if the total database size fits >> reasonably well in page cache. >> >> Pre-heating sstables on a per-cf basis on start-up would be a nice >> feature to have. >> > >
