Joost,
Part of Jonathans explanation for flushing every approx 5 minutes was
to reduce the size of the commit log, and reduce the replay time.
Even with the patch flushing memtables is necessary at some point to
truncate the log. If this is an issue consider disabling
I'm afraid not. It's too much change for an oldstable release series,
and the bulk of the change is to AtomicSortedColumns which doesn't
exist in 1.0, so even if we wanted to take a maybe it's okay if we
release it first in 1.1.3 and then backport approach it wouldn't
improve our safety margin
On Thu, Jun 28, 2012 at 1:39 PM, Joost van de Wijgerd
jwijg...@gmail.com wrote:
the currentThoughput is increased even before the data is merged into the
memtable so it is actually measuring the throughput afaik.
You're right. I've attached a patch to
Hi Jonathan,
Looks good, any chance of porting this fix to the 1.0 branch?
Kind regards
Joost
Sent from my iPhone
On 1 jul. 2012, at 09:25, Jonathan Ellis jbel...@gmail.com wrote:
On Thu, Jun 28, 2012 at 1:39 PM, Joost van de Wijgerd
jwijg...@gmail.com wrote:
the currentThoughput is
[moving to user list]
1.0 doesn't care about throughput or op count anymore, only whether
the total memory used by the *currrent* data in the memtables has
reached the global limit. So, it automatically doesn't count
historical data that's been overwritten in the current memtable.
So, you may
I was wondering if we could find cases where the new one global limit would
not be good for some.
As Jonathan said setting you memtable memory high will help. Although if
you are constantly overwtiting the exact almost same data it should never
flush if you have enough dedicated memory.
On
Hi Jonathan,
The problem is not that I haven't allocated enough memory to the memtables,
the problem is that the memtable for this particular CF flushes too early
because the liveRation stays at 1.0. When looking at the code it seems to
me the the liveRatio is calculated based on
the throughput
