You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Chris Burroughs <ch...@gmail.com> on 2011/01/27 18:23:07 UTC
reduced cached mem; resident set size growth
We have a 6 node Cassandra 0.6.8 cluster running on boxes with 4 GB of
RAM. Over the course of several weeks cached memory slowly decreases
until Cassandra is restarted or something bad happens (ie oom killer).
Performance obviously suffers as cached memory is no longer available.
Here is a graph of memory over a two week period, the big jump is a
Cassandra restart:
http://img194.imageshack.us/img194/383/2weekmem.png
There is also tomcat and and your standard linux services running on the
box as well. I saved the output of /proc/$CASSANDRA_PID/status ever 10
seconds from yesterday afternoon to this morning and graphed resident
set size. While the jvm and the linux virtual memory system do all
sorts of clever things, over a period of 12+ hours I believe RSS must go
in a direction other than up or there is a problem.
http://img24.imageshack.us/img24/1754/cassandrarss.png
swapiness is currently set to zero and a graph of swap use over a two
week period does not show any corresponding growth to the lost cached space.
We are using <DiskAccessMode>standard</DiskAccessMode> and no JNA
interfaces. I think this makes Cassandra a totally normal java program
living in heap, so I am confused how this growth could be happening.
Similar experiences or explanations would be most welcome. I can
provide further information if necessary.
##### Info dump
uname: 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT 2010 x86_64
x86_64 x86_64 GNU/Linux
java -version
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
cmd line arg (paths edited):
/usr/java/jdk1.6.0_20/bin/java -Xms1500M -cXmx1500M -ea -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled
-XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1
-XX:+HeapDumpOnOutOfMemoryError -XX:+UseThreadPriorities
-XX:ThreadPriorityPolicy=42 -Dcassandra.compaction.priority=1
-Dcom.sun.management.jmxremote.port=10101
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Dstorage-config=~/conf -Dcassandra-pidfile=~/cassandra.pid -cp
~/conf::~/lib/antlr-3.1.3.jar:~/lib/apache-cassandra-0.6.8.jar:~/lib/clhm-production.jar:~/lib/commons-cli-1.1.jar:~/lib/commons-codec-1.2.jar:~/lib/commons-collections-3.2.1.jar:~/lib/commons-lang-2.4.jar:~/lib/google-collections-1.0.jar:~/lib/hadoop-core-0.20.1.jar:~/lib/high-scale-lib.jar:~/lib/ivy-2.1.0.jar:~/lib/jackson-core-asl-1.4.0.jar:~/lib/jackson-mapper-asl-1.4.0.jar:~/lib/jline-0.9.94.jar:~/lib/json-simple-1.1.jar:~/lib/libthrift-r917130.jar:~/lib/log4j-1.2.14.jar:~/lib/slf4j-api-1.5.8.jar:~/lib/slf4j-log4j12-1.5.8.jar:~/lib/zapcass-1.0.0.jar:~/lib/zapcat-1.3-beta.jar
com.clearspring.cassandra.ZapCassDaemon
ZapCassDaemon is just getting cassandra and zabbix to talk. I do not
believe we are unique in doing this:
public class ZapCassDaemon {
public EmbeddedCassandraService cassandra;
public ZabbixAgent agent;
public ZapCassDaemon() throws Exception {
agent = new ZabbixAgent();
cassandra = new EmbeddedCassandraService();
cassandra.init();
cassandra.run();
}
static public ZapCassDaemon instance;
static public void main(String[] args) throws Exception {
instance = new ZapCassDaemon();
}
}
Re: reduced cached mem; resident set size growth
Posted by Ryan King <ry...@twitter.com>.
The test was inconclusive because we decomissioned that cluster before
it'd be running long enough to exhibit the problem.
-ryan
On Wed, Mar 16, 2011 at 7:27 PM, Zhu Han <sc...@gmail.com> wrote:
>
>
> On Thu, Feb 3, 2011 at 1:49 AM, Ryan King <ry...@twitter.com> wrote:
>>
>> On Wed, Feb 2, 2011 at 6:22 AM, Chris Burroughs
>> <ch...@gmail.com> wrote:
>> > On 01/28/2011 09:19 PM, Chris Burroughs wrote:
>> >> Thanks Oleg and Zhu. I swear that wasn't a new hotspot version when I
>> >> checked, but that's obviously not the case. I'll update one node to
>> >> the
>> >> latest as soon as I can and report back.
>> >
>> >
>> > RSS over 48 hours with java 6 update 23:
>> >
>> > http://img716.imageshack.us/img716/5202/u2348hours.png
>> >
>> > I'll continue monitoring but RSS still appears to grow without bounds.
>> > Zhu reported a similar problem with Ubuntu 10.04. While possible, it
>> > would seem seam extraordinary unlikely that there is a glibc or kernel
>> > bug affecting us both.
>>
>> We're seeing a similar problem with one of our clusters (but over a
>> longer time scale). Its possible that its not a leak, but just
>> fragmentation. Unless you've told it otherwise, the jvm uses glibc's
>> malloc implementation for off-heap allocations. We're currently
>> running a test with jemalloc on one node to see if the problem goes
>> away.
>
> Ryan, does jemalloc solve the RSS growth problem in your test?
>
>> -ryan
>
>
Re: reduced cached mem; resident set size growth
Posted by Zhu Han <sc...@gmail.com>.
On Thu, Mar 17, 2011 at 10:27 AM, Zhu Han <sc...@gmail.com> wrote:
>
>
> On Thu, Feb 3, 2011 at 1:49 AM, Ryan King <ry...@twitter.com> wrote:
>
>> On Wed, Feb 2, 2011 at 6:22 AM, Chris Burroughs
>> <ch...@gmail.com> wrote:
>> > On 01/28/2011 09:19 PM, Chris Burroughs wrote:
>> >> Thanks Oleg and Zhu. I swear that wasn't a new hotspot version when I
>> >> checked, but that's obviously not the case. I'll update one node to
>> the
>> >> latest as soon as I can and report back.
>> >
>> >
>> > RSS over 48 hours with java 6 update 23:
>> >
>> > http://img716.imageshack.us/img716/5202/u2348hours.png
>> >
>> > I'll continue monitoring but RSS still appears to grow without bounds.
>> > Zhu reported a similar problem with Ubuntu 10.04. While possible, it
>> > would seem seam extraordinary unlikely that there is a glibc or kernel
>> > bug affecting us both.
>>
>> We're seeing a similar problem with one of our clusters (but over a
>> longer time scale).
>
>
Does it mean not all your clusters running cassandra observed the same RSS
growth problem?
> Its possible that its not a leak, but just
>> fragmentation. Unless you've told it otherwise, the jvm uses glibc's
>> malloc implementation for off-heap allocations. We're currently
>> running a test with jemalloc on one node to see if the problem goes
>> away.
>>
>
> Ryan, does jemalloc solve the RSS growth problem in your test?
>
> -ryan
>>
>
>
Re: reduced cached mem; resident set size growth
Posted by Zhu Han <sc...@gmail.com>.
On Thu, Feb 3, 2011 at 1:49 AM, Ryan King <ry...@twitter.com> wrote:
> On Wed, Feb 2, 2011 at 6:22 AM, Chris Burroughs
> <ch...@gmail.com> wrote:
> > On 01/28/2011 09:19 PM, Chris Burroughs wrote:
> >> Thanks Oleg and Zhu. I swear that wasn't a new hotspot version when I
> >> checked, but that's obviously not the case. I'll update one node to the
> >> latest as soon as I can and report back.
> >
> >
> > RSS over 48 hours with java 6 update 23:
> >
> > http://img716.imageshack.us/img716/5202/u2348hours.png
> >
> > I'll continue monitoring but RSS still appears to grow without bounds.
> > Zhu reported a similar problem with Ubuntu 10.04. While possible, it
> > would seem seam extraordinary unlikely that there is a glibc or kernel
> > bug affecting us both.
>
> We're seeing a similar problem with one of our clusters (but over a
> longer time scale). Its possible that its not a leak, but just
> fragmentation. Unless you've told it otherwise, the jvm uses glibc's
> malloc implementation for off-heap allocations. We're currently
> running a test with jemalloc on one node to see if the problem goes
> away.
>
Ryan, does jemalloc solve the RSS growth problem in your test?
-ryan
>
Re: reduced cached mem; resident set size growth
Posted by Ryan King <ry...@twitter.com>.
On Wed, Feb 2, 2011 at 10:29 AM, Chris Burroughs
<ch...@gmail.com> wrote:
> On 02/02/2011 12:49 PM, Ryan King wrote:
>> We're seeing a similar problem with one of our clusters (but over a
>> longer time scale). Its possible that its not a leak, but just
>> fragmentation. Unless you've told it otherwise, the jvm uses glibc's
>> malloc implementation for off-heap allocations. We're currently
>> running a test with jemalloc on one node to see if the problem goes
>> away.
>>
>
> Thanks Ryan.
>
> Is it over a longer time scale because of some action taken to mitigate
> the problem, or has it always been that long for you?
My guess is that its a longer timeframe because the cluster is really
low traffic (around 100qps across 10 nodes).
-ryan
Re: reduced cached mem; resident set size growth
Posted by Chris Burroughs <ch...@gmail.com>.
On 02/02/2011 12:49 PM, Ryan King wrote:
> We're seeing a similar problem with one of our clusters (but over a
> longer time scale). Its possible that its not a leak, but just
> fragmentation. Unless you've told it otherwise, the jvm uses glibc's
> malloc implementation for off-heap allocations. We're currently
> running a test with jemalloc on one node to see if the problem goes
> away.
>
Thanks Ryan.
Is it over a longer time scale because of some action taken to mitigate
the problem, or has it always been that long for you?
Re: reduced cached mem; resident set size growth
Posted by Ryan King <ry...@twitter.com>.
On Wed, Feb 2, 2011 at 6:22 AM, Chris Burroughs
<ch...@gmail.com> wrote:
> On 01/28/2011 09:19 PM, Chris Burroughs wrote:
>> Thanks Oleg and Zhu. I swear that wasn't a new hotspot version when I
>> checked, but that's obviously not the case. I'll update one node to the
>> latest as soon as I can and report back.
>
>
> RSS over 48 hours with java 6 update 23:
>
> http://img716.imageshack.us/img716/5202/u2348hours.png
>
> I'll continue monitoring but RSS still appears to grow without bounds.
> Zhu reported a similar problem with Ubuntu 10.04. While possible, it
> would seem seam extraordinary unlikely that there is a glibc or kernel
> bug affecting us both.
We're seeing a similar problem with one of our clusters (but over a
longer time scale). Its possible that its not a leak, but just
fragmentation. Unless you've told it otherwise, the jvm uses glibc's
malloc implementation for off-heap allocations. We're currently
running a test with jemalloc on one node to see if the problem goes
away.
-ryan
Re: reduced cached mem; resident set size growth
Posted by Chris Burroughs <ch...@gmail.com>.
On 01/28/2011 09:19 PM, Chris Burroughs wrote:
> Thanks Oleg and Zhu. I swear that wasn't a new hotspot version when I
> checked, but that's obviously not the case. I'll update one node to the
> latest as soon as I can and report back.
RSS over 48 hours with java 6 update 23:
http://img716.imageshack.us/img716/5202/u2348hours.png
I'll continue monitoring but RSS still appears to grow without bounds.
Zhu reported a similar problem with Ubuntu 10.04. While possible, it
would seem seam extraordinary unlikely that there is a glibc or kernel
bug affecting us both.
Re: reduced cached mem; resident set size growth
Posted by Chris Burroughs <ch...@gmail.com>.
On 01/28/2011 04:12 AM, Zhu Han wrote:
> Chris,
>
> Somebody else and I have the same problem as you, and reported it here:
> http://www.apacheserver.net/Very-high-memory-utilization-not-caused-by-mmap-on-sstables-at1082970.htm
>
> [NB: It is not solved although the titles said so. Some response from me in
> the thread is not accurate.]
>
> IMHO, you should try to upgrade JVM as the first step. If it is solved,
> please let us know.
>
Thanks Oleg and Zhu. I swear that wasn't a new hotspot version when I
checked, but that's obviously not the case. I'll update one node to the
latest as soon as I can and report back.
Re: reduced cached mem; resident set size growth
Posted by Zhu Han <sc...@gmail.com>.
Chris,
Somebody else and I have the same problem as you, and reported it here:
http://www.apacheserver.net/Very-high-memory-utilization-not-caused-by-mmap-on-sstables-at1082970.htm
[NB: It is not solved although the titles said so. Some response from me in
the thread is not accurate.]
IMHO, you should try to upgrade JVM as the first step. If it is solved,
please let us know.
If upgrade of JVM does not work, considering the leak happens on C stack of
JVM, I suspect it is caused by kernel or glibc, although other java process
on the same box are OK. But i haven't tries it as I do not have control of
the kernel version in the VPS environment.
best regards,
hanzhu
On Fri, Jan 28, 2011 at 1:23 AM, Chris Burroughs
<ch...@gmail.com>wrote:
> We have a 6 node Cassandra 0.6.8 cluster running on boxes with 4 GB of
> RAM. Over the course of several weeks cached memory slowly decreases
> until Cassandra is restarted or something bad happens (ie oom killer).
> Performance obviously suffers as cached memory is no longer available.
> Here is a graph of memory over a two week period, the big jump is a
> Cassandra restart:
>
> http://img194.imageshack.us/img194/383/2weekmem.png
>
> There is also tomcat and and your standard linux services running on the
> box as well. I saved the output of /proc/$CASSANDRA_PID/status ever 10
> seconds from yesterday afternoon to this morning and graphed resident
> set size. While the jvm and the linux virtual memory system do all
> sorts of clever things, over a period of 12+ hours I believe RSS must go
> in a direction other than up or there is a problem.
>
> http://img24.imageshack.us/img24/1754/cassandrarss.png
>
> swapiness is currently set to zero and a graph of swap use over a two
> week period does not show any corresponding growth to the lost cached
> space.
>
> We are using <DiskAccessMode>standard</DiskAccessMode> and no JNA
> interfaces. I think this makes Cassandra a totally normal java program
> living in heap, so I am confused how this growth could be happening.
> Similar experiences or explanations would be most welcome. I can
> provide further information if necessary.
>
>
> ##### Info dump
> uname: 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT 2010 x86_64
> x86_64 x86_64 GNU/Linux
>
> java -version
> java version "1.6.0_20"
> Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
> Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
>
> cmd line arg (paths edited):
> /usr/java/jdk1.6.0_20/bin/java -Xms1500M -cXmx1500M -ea -XX:+UseParNewGC
> -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled
> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1
> -XX:+HeapDumpOnOutOfMemoryError -XX:+UseThreadPriorities
> -XX:ThreadPriorityPolicy=42 -Dcassandra.compaction.priority=1
> -Dcom.sun.management.jmxremote.port=10101
> -Dcom.sun.management.jmxremote.ssl=false
> -Dcom.sun.management.jmxremote.authenticate=false
> -Dstorage-config=~/conf -Dcassandra-pidfile=~/cassandra.pid -cp
>
> ~/conf::~/lib/antlr-3.1.3.jar:~/lib/apache-cassandra-0.6.8.jar:~/lib/clhm-production.jar:~/lib/commons-cli-1.1.jar:~/lib/commons-codec-1.2.jar:~/lib/commons-collections-3.2.1.jar:~/lib/commons-lang-2.4.jar:~/lib/google-collections-1.0.jar:~/lib/hadoop-core-0.20.1.jar:~/lib/high-scale-lib.jar:~/lib/ivy-2.1.0.jar:~/lib/jackson-core-asl-1.4.0.jar:~/lib/jackson-mapper-asl-1.4.0.jar:~/lib/jline-0.9.94.jar:~/lib/json-simple-1.1.jar:~/lib/libthrift-r917130.jar:~/lib/log4j-1.2.14.jar:~/lib/slf4j-api-1.5.8.jar:~/lib/slf4j-log4j12-1.5.8.jar:~/lib/zapcass-1.0.0.jar:~/lib/zapcat-1.3-beta.jar
> com.clearspring.cassandra.ZapCassDaemon
>
> ZapCassDaemon is just getting cassandra and zabbix to talk. I do not
> believe we are unique in doing this:
> public class ZapCassDaemon {
> public EmbeddedCassandraService cassandra;
> public ZabbixAgent agent;
> public ZapCassDaemon() throws Exception {
> agent = new ZabbixAgent();
>
> cassandra = new EmbeddedCassandraService();
> cassandra.init();
> cassandra.run();
> }
> static public ZapCassDaemon instance;
> static public void main(String[] args) throws Exception {
> instance = new ZapCassDaemon();
> }
> }
>
Re: reduced cached mem; resident set size growth
Posted by Zhu Han <sc...@gmail.com>.
On Fri, Jan 28, 2011 at 4:15 PM, Oleg Anastasyev <ol...@gmail.com> wrote:
> >
> > http://img24.imageshack.us/img24/1754/cassandrarss.png
> >
> This looks like cassandra leaking memory inside java heap.
> I remember, there was some leaking issues with java versions <1.6.u21,
> correct
> me if I wrong. Try to upgrade to more recent JVM on some node.
>
Do you have more information os this issue?
I meets the same problem even on the latest release of OpenJD, ubuntu
10.04.
Re: reduced cached mem; resident set size growth
Posted by Oleg Anastasyev <ol...@gmail.com>.
>
> http://img24.imageshack.us/img24/1754/cassandrarss.png
>
This looks like cassandra leaking memory inside java heap.
I remember, there was some leaking issues with java versions <1.6.u21, correct
me if I wrong. Try to upgrade to more recent JVM on some node.
Re: reduced cached mem; resident set size growth
Posted by Chris Burroughs <ch...@gmail.com>.
On 01/28/2011 10:51 AM, sridhar basam wrote:
> On Thu, Jan 27, 2011 at 12:23 PM, Chris Burroughs <chris.burroughs@gmail.com
>> wrote:
>
>> java -version
>> java version "1.6.0_20"
>> Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
>> Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
>>
>> cmd line arg (paths edited):
>> /usr/java/jdk1.6.0_20/bin/java -Xms1500M -cXmx1500M -ea -XX:+UseParNewGC
>>
>
> Is the above optiont for setting the max heap size a typo "-cXmx1500M"?
>
> sridhar
>
Typo in my email. But the command is correct on the server.
/usr/java/jdk1.6.0_20/bin/java -Xms1500M -Xmx1500M -ea -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled
-XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1
-XX:+HeapDumpOnOutOfMemoryError -XX:+UseThreadPriorities
-XX:ThreadPriorityPolicy=42 -Dcassandra.compaction.priority=1
Re: reduced cached mem; resident set size growth
Posted by sridhar basam <sr...@basam.org>.
On Thu, Jan 27, 2011 at 12:23 PM, Chris Burroughs <chris.burroughs@gmail.com
> wrote:
> java -version
> java version "1.6.0_20"
> Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
> Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
>
> cmd line arg (paths edited):
> /usr/java/jdk1.6.0_20/bin/java -Xms1500M -cXmx1500M -ea -XX:+UseParNewGC
>
Is the above optiont for setting the max heap size a typo "-cXmx1500M"?
sridhar
Re: reduced cached mem; resident set size growth
Posted by Chris Burroughs <ch...@gmail.com>.
On 01/28/2011 12:42 PM, sridhar basam wrote:
> What about your permgen usage? Do you track that? Use something like "jstat
> -gc -t <pid> 5s 1000000" to track it. Or turn up verbose GC on your command
> line options to what is happening.
>
http://img59.imageshack.us/img59/1056/permgen.png
This is over about 5 hours using the saved outcome of the command you
sugested. It appears to be collected properly to me.
Re: reduced cached mem; resident set size growth
Posted by sridhar basam <sr...@basam.org>.
What about your permgen usage? Do you track that? Use something like "jstat
-gc -t <pid> 5s 1000000" to track it. Or turn up verbose GC on your command
line options to what is happening.
Sridhar
On Fri, Jan 28, 2011 at 11:38 AM, Chris Burroughs <chris.burroughs@gmail.com
> wrote:
> On 01/28/2011 11:29 AM, Jake Luciani wrote:
> > Are you using a row cache? if so what is it set too? in general it should
> > not be a percentage.
> >
>
>
> <ColumnFamily CompareWith="UTF8Type" Name="mycolumnfamily"
> KeysCached="0" KeyCacheSavePeriodInSeconds="0"
> RowsCached="400000" RowCacheSavePeriodInSeconds="1800"
> />
>
> row_cache_size == row_cache_capacity before the start of RSS data
> collection. According to jconsole heap size is not growing larger than
> the maximum set at the command line.
>
Re: reduced cached mem; resident set size growth
Posted by Chris Burroughs <ch...@gmail.com>.
On 01/28/2011 11:29 AM, Jake Luciani wrote:
> Are you using a row cache? if so what is it set too? in general it should
> not be a percentage.
>
<ColumnFamily CompareWith="UTF8Type" Name="mycolumnfamily"
KeysCached="0" KeyCacheSavePeriodInSeconds="0"
RowsCached="400000" RowCacheSavePeriodInSeconds="1800"
/>
row_cache_size == row_cache_capacity before the start of RSS data
collection. According to jconsole heap size is not growing larger than
the maximum set at the command line.
Re: reduced cached mem; resident set size growth
Posted by Jake Luciani <ja...@gmail.com>.
Are you using a row cache? if so what is it set too? in general it should
not be a percentage.
On Thu, Jan 27, 2011 at 12:23 PM, Chris Burroughs <chris.burroughs@gmail.com
> wrote:
> We have a 6 node Cassandra 0.6.8 cluster running on boxes with 4 GB of
> RAM. Over the course of several weeks cached memory slowly decreases
> until Cassandra is restarted or something bad happens (ie oom killer).
> Performance obviously suffers as cached memory is no longer available.
> Here is a graph of memory over a two week period, the big jump is a
> Cassandra restart:
>
> http://img194.imageshack.us/img194/383/2weekmem.png
>
> There is also tomcat and and your standard linux services running on the
> box as well. I saved the output of /proc/$CASSANDRA_PID/status ever 10
> seconds from yesterday afternoon to this morning and graphed resident
> set size. While the jvm and the linux virtual memory system do all
> sorts of clever things, over a period of 12+ hours I believe RSS must go
> in a direction other than up or there is a problem.
>
> http://img24.imageshack.us/img24/1754/cassandrarss.png
>
> swapiness is currently set to zero and a graph of swap use over a two
> week period does not show any corresponding growth to the lost cached
> space.
>
> We are using <DiskAccessMode>standard</DiskAccessMode> and no JNA
> interfaces. I think this makes Cassandra a totally normal java program
> living in heap, so I am confused how this growth could be happening.
> Similar experiences or explanations would be most welcome. I can
> provide further information if necessary.
>
>
> ##### Info dump
> uname: 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT 2010 x86_64
> x86_64 x86_64 GNU/Linux
>
> java -version
> java version "1.6.0_20"
> Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
> Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
>
> cmd line arg (paths edited):
> /usr/java/jdk1.6.0_20/bin/java -Xms1500M -cXmx1500M -ea -XX:+UseParNewGC
> -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled
> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1
> -XX:+HeapDumpOnOutOfMemoryError -XX:+UseThreadPriorities
> -XX:ThreadPriorityPolicy=42 -Dcassandra.compaction.priority=1
> -Dcom.sun.management.jmxremote.port=10101
> -Dcom.sun.management.jmxremote.ssl=false
> -Dcom.sun.management.jmxremote.authenticate=false
> -Dstorage-config=~/conf -Dcassandra-pidfile=~/cassandra.pid -cp
>
> ~/conf::~/lib/antlr-3.1.3.jar:~/lib/apache-cassandra-0.6.8.jar:~/lib/clhm-production.jar:~/lib/commons-cli-1.1.jar:~/lib/commons-codec-1.2.jar:~/lib/commons-collections-3.2.1.jar:~/lib/commons-lang-2.4.jar:~/lib/google-collections-1.0.jar:~/lib/hadoop-core-0.20.1.jar:~/lib/high-scale-lib.jar:~/lib/ivy-2.1.0.jar:~/lib/jackson-core-asl-1.4.0.jar:~/lib/jackson-mapper-asl-1.4.0.jar:~/lib/jline-0.9.94.jar:~/lib/json-simple-1.1.jar:~/lib/libthrift-r917130.jar:~/lib/log4j-1.2.14.jar:~/lib/slf4j-api-1.5.8.jar:~/lib/slf4j-log4j12-1.5.8.jar:~/lib/zapcass-1.0.0.jar:~/lib/zapcat-1.3-beta.jar
> com.clearspring.cassandra.ZapCassDaemon
>
> ZapCassDaemon is just getting cassandra and zabbix to talk. I do not
> believe we are unique in doing this:
> public class ZapCassDaemon {
> public EmbeddedCassandraService cassandra;
> public ZabbixAgent agent;
> public ZapCassDaemon() throws Exception {
> agent = new ZabbixAgent();
>
> cassandra = new EmbeddedCassandraService();
> cassandra.init();
> cassandra.run();
> }
> static public ZapCassDaemon instance;
> static public void main(String[] args) throws Exception {
> instance = new ZapCassDaemon();
> }
> }
>