Thanks all for your responses. We've downgraded from 2.0.3 to 2.0.0 and
everything became normal.
2013/12/8 Nate McCall
> If you are really set on using Cassandra as a cache, I would recommend
> disabling durable writes for the keyspace(s)[0]. This will bypass the
> commitlog (the flushing/rota
If you are really set on using Cassandra as a cache, I would recommend
disabling durable writes for the keyspace(s)[0]. This will bypass the
commitlog (the flushing/rotation of which my be a good-sized portion of
your performance problems given the number of tables).
[0]
http://www.datastax.com/do
On Thu, Dec 5, 2013 at 6:33 AM, Alexander Shutyaev wrote:
> We've plugged it into our production environment as a cache in front of
> postgres. Everything worked fine, we even stressed it by explicitly
> propagating about 30G (10G/node) data from postgres to cassandra.
>
If you just want a cachin
Thanks for your answers,
Jonathan, yes it was load avg and iowait was lower than 2% all that time -
the only load was the user one.
Robert, we had -Xmx4012m which was automatically calculated by the default
cassandra-env.sh (1/4 of total memory - 16G) - we didn't change that.
2013/12/5 Robert C
On Thu, Dec 5, 2013 at 4:33 AM, Alexander Shutyaev wrote:
> Cassandra version is 2.0.3. ... We've plugged it into our production
> environment as a cache in front of postgres.
>
https://engineering.eventbrite.com/what-version-of-cassandra-should-i-run/
> What can be the reason? Can it be high n
Do you mean high CPU usage or high load avg? (20 indicates load avg to
me). High load avg means the CPU is waiting on something.
Check "iostat -dmx 1 100" to check your disk stats, you'll see the columns
that indicate mb/s read & write as well as % utilization.
Once you understand the bottlenec
