r
>>>>>>>> in
>>>>>>>> getting rid of it.
>>>>>>>>
>>>>>>>> I've made a couple of attempts to get rid of this so far. I'm about
>>>>>>>> to try again.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Tim
>>>>>>>>
>>>>>>>> --
>>>>>>>> GPG me!!
>>>>>>>>
>>>>>>>> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> GPG me!!
>>>>>>
>>>>>> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Founder/CEO Spinn3r.com
>>>>> Location: *San Francisco, CA*
>>>>> Skype: *burtonator*
>>>>> blog: http://burtonator.wordpress.com
>>>>> … or check out my Google+ profile
>>>>> <https://plus.google.com/102718274791889610666/posts>
>>>>> <http://spinn3r.com>
>>>>> War is peace. Freedom is slavery. Ignorance is strength. Corporations
>>>>> are people.
>>>>>
>>>>>
>>>
>>>
>>> --
>>> GPG me!!
>>>
>>> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
>>>
>>>
>>
>>
>> --
>> *Paulo Motta*
>>
>> Chaordic | *Platform*
>> *www.chaordic.com.br <http://www.chaordic.com.br/>*
>> +55 48 3232.3200
>>
>
>
>
> --
> GPG me!!
>
> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
>
>
--
David Daeschler
Figured this one out..
In the new setup /tmp was mounted as noexec. So it looks like JNA was
putting the native library here and then it was unable to execute it.
I hope this can help someone else.
On Mon, May 26, 2014 at 11:33 PM, David Daeschler wrote:
> Good evening list,
>
> I
4/jna4691935553862497129.tmp.
Thank you ahead of time for any help you may be able to offer.
--
David Daeschler
pretty confident Datastax is a significant net positive for contribution to
> and promotion of Apache Cassandra.
>
> =Rob
>
--
David Daeschler
xed in 0.6, this describes my problem exactly.
>
>
>
> I’m running Cassandra 1.1.5 from Datastax on Centos 6.0:
>
> http://rpm.datastax.com/community/noarch/apache-cassandra11-1.1.5-1.noarch.rpm
>
>
>
> Is anyone else seeing this behavior? What can I do to provide more
> information?
>
>
>
> Steve
>
>
--
David Daeschler
Hello.
In the process of trying to streamline and provide better reporting
for various data storage systems, I've realized that although we're
verifying that nodetool repair runs, we're not verifying that it is
successful.
I found a bug relating to the exit code for nodetool repair, where, in
som
ts working again.
I hope this helps. Please spread the word if you see others having
issues with unresponsive kernels/high CPU.
--
David Daeschler
On Sun, Jul 1, 2012 at 1:05 PM, ruslan usifov wrote:
> Hello
>
> We was under ddos attack, and as result we got high ksoftirqd activity
&g
pm eastern time"
If you are seeing high CPU usage and a stall after restarting
cassandra still, and you are on Linux, try:
date; date `date +"%m%d%H%M%C%y.%S"`; date;
In a terminal and see if everything starts working again.
I hope this helps.
--
David Daeschler
On Sun, Jul 1, 201
More information for others that were affected.
Our installation of java:
[root@inv4 conf]# java -version
java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)
[root@inv4 conf]# uname -a
Linux inv4 2.6.32-220.4
t;
> date; date `date +"%m%d%H%M%C%y.%S"`; date;
>
> CPU drop was instantaneous - there was no need to restart the server, ntpd,
> or any of the affected JVMs.
>
>
>
--
David Daeschler
Thank you for all the replies. It has been enlightening to read. I think I
now have a better idea of repair, ranges, replicas and how the data is
distributed. It also seems that using -pr would be the best way to go in my
scenario with 1.x+
Thank you for all the feedback. Glad to see such an acti
Hello,
Currently I have a 4 node cassandra cluster on CentOS64. I have been
running nodetool repair (no -pr option) on a weekly schedule like:
Host1: Tue, Host2: Wed, Host3: Thu, Host4: Fri
In this scenario, if I were to add the -pr option, would this still be
sufficient to prevent forgotten del
12 matches
Mail list logo
