Brandon, Thanks for the response. I have also noticed that stress.py's progress interval gets thrown off in low memory situations.
What did you mean by "contrib/stress on 0.7 instead". I don't see that dir in the src version of 0.7. - Sameer On Thu, Feb 3, 2011 at 5:22 PM, Brandon Williams <[email protected]> wrote: > On Thu, Feb 3, 2011 at 7:02 PM, Sameer Farooqui > <[email protected]>wrote: > >> Hi guys, >> >> I was playing around with the stress.py test this week and noticed a few >> things. >> >> 1) Progress-interval does not always work correctly. I set it to 5 in the >> example below, but am instead getting varying intervals: >> > > Generally indicates that the client machine is being overloaded in my > experience. > > 2) The key_rate and op_rate doesn't seem to be calculated correctly. Also, >> what is the difference between the interval_key_rate and the >> interval_op_rate? For example in the example above, the first row shows 6662 >> keys inserted in 5 seconds and 6662 / 5 = 1332, which matches the >> interval_op_rate. >> > > There should be no difference unless you're doing range slices, but IPC > timing makes them vary somewhat. > > 3) If I write x KB to Cassandra with py_stress, the used disk space doesn't >> grow by x after the test. In the example below I tried to write 500,000 keys >> * 32 bytes * 5 columns = 78,125 kilobytes of data to the database. When I >> checked the amount of disk space used after the test it actually grew by >> 2,684,920 - 2,515,864 = 169,056 kilobytes. Is this because perhaps the >> commit log got duplicate copies of the data as the SSTables? >> > > Commitlogs could be part of it, you're not factoring in the column names, > and then there's index and bloom filter overhead. > > Use contrib/stress on 0.7 instead. > > -Brandon >
