You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Asit KAUSHIK <as...@gmail.com> on 2015/01/31 02:49:21 UTC
Cassandra 2.0.11 with stargate-core read writes are slow
Hi all,
We are testing our logging application on 3 node cluster each system is
virtual machine with 4 cores and 8GB RAM with RedHat enterprise. Now my
question is in 3 parts
1) Am I using the right hardware as of now I am testing say 100000 record
reads.
2) I am using Stargate-core for full text search is there any slowness
observed because of that as ???
2) How can I simulate the write load I created an application which creates
say 20 threads and each tread I insert 1000 records and on each thread I
open cluster connection session connection execute 1000 records and close
the connection. This takes a lot of time please suggest if I missing
something
Re: Cassandra 2.0.11 with stargate-core read writes are slow
Posted by Jan <cn...@yahoo.com>.
HI Asit;
Question 1) Am I using the right hardware as of now I am testing say 100000 record reads.
Answer: Recommend looking at either the 'sar' output logs & watching nodetool cfstats & watching your system.log files to track hardware usage & JVM presssure. As a rule of thumb, its recommeneded to have 8 GB for the C* JVM itself on production systems.
Question 3) Is unclear, pl. rephrase the question.
hope this helpsJan
C* Architect
On Saturday, January 31, 2015 5:33 AM, Carlos Rolo <ro...@pythian.com> wrote:
HI Asit,
The only help I'm going to give is on point 3), as I have little experience with 2) and 1) depends on a lot of factors.
For testing the workload use this: http://www.datastax.com/documentation/cassandra/2.1/cassandra/tools/toolsCStress_t.html It probably covers all your testing needs.
Regards,
Carlos Juzarte RoloCassandra Consultant Pythian - Love your data
rolo@pythian | Twitter: cjrolo | Linkedin: linkedin.com/in/carlosjuzarteroloTel: 1649www.pythian.com
On Sat, Jan 31, 2015 at 2:49 AM, Asit KAUSHIK <as...@gmail.com> wrote:
Hi all,
We are testing our logging application on 3 node cluster each system is virtual machine with 4 cores and 8GB RAM with RedHat enterprise. Now my question is in 3 parts
1) Am I using the right hardware as of now I am testing say 100000 record reads.
2) I am using Stargate-core for full text search is there any slowness observed because of that as ???
2) How can I simulate the write load I created an application which creates say 20 threads and each tread I insert 1000 records and on each thread I open cluster connection session connection execute 1000 records and close the connection. This takes a lot of time please suggest if I missing something
--
Re: Cassandra 2.0.11 with stargate-core read writes are slow
Posted by Carlos Rolo <ro...@pythian.com>.
HI Asit,
The only help I'm going to give is on point 3), as I have little experience
with 2) and 1) depends on a lot of factors.
For testing the workload use this:
http://www.datastax.com/documentation/cassandra/2.1/cassandra/tools/toolsCStress_t.html
It probably covers all your testing needs.
Regards,
Carlos Juzarte Rolo
Cassandra Consultant
Pythian - Love your data
rolo@pythian | Twitter: cjrolo | Linkedin: *linkedin.com/in/carlosjuzarterolo
<http://linkedin.com/in/carlosjuzarterolo>*
Tel: 1649
www.pythian.com
On Sat, Jan 31, 2015 at 2:49 AM, Asit KAUSHIK <as...@gmail.com>
wrote:
> Hi all,
> We are testing our logging application on 3 node cluster each system is
> virtual machine with 4 cores and 8GB RAM with RedHat enterprise. Now my
> question is in 3 parts
> 1) Am I using the right hardware as of now I am testing say 100000 record
> reads.
> 2) I am using Stargate-core for full text search is there any slowness
> observed because of that as ???
> 2) How can I simulate the write load I created an application which
> creates say 20 threads and each tread I insert 1000 records and on each
> thread I open cluster connection session connection execute 1000 records
> and close the connection. This takes a lot of time please suggest if I
> missing something
>
--
--