On Thu, Jul 21, 2011 at 9:18 AM, Stephen Pope wrote:
> For a side project I’m working on I want to store the entire set of
> possible Reversi boards. There are an estimated 10^28 possible boards. Each
> board (from the best way I could think of to implement it) is made up of 2,
> 64-bit numbers (
On Mon, Nov 21, 2011 at 10:34 AM, Edward Capriolo wrote:
>
>
> On Mon, Nov 21, 2011 at 10:07 AM, Dan Hendry wrote:
>
>> Pretty sure your argument about indirect blocks making large files
>> inefficient only pertains to ext2/3 and not ext4. It seems ext4 replaces
>> the
>> 'indirect block' approach
There is no global setting in linux to turn off nagle.
Sridhar
2012/1/26 Jeffrey Kesselman :
> You know... here aught to be a command line command to set it. There is in
> Solaris and Windows. But Im having trouble finding it for Linux.
>
>
> 2012/1/26 ruslan usifov
>>
>> Sorry but you misun
kets doesn't
> allow set sock options - ie no such API
>
>>
>> Cheers
>>
>>
>> -
>> Aaron Morton
>> Freelance Developer
>> @aaronmorton
>> http://www.thelastpickle.com
>>
>> On 27/01/2012, at 6:54 AM, sridhar bas
On Thu, Jan 27, 2011 at 12:23 PM, Chris Burroughs 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 -c
What about your permgen usage? Do you track that? Use something like "jstat
-gc -t 5s 100" 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 wrote:
> On 01/28/2011 11:29 AM, Jake Luciani wrote:
>
The data provided is also a average value since boot time. Run the -x as
suggested below but run it via a interval of around 5 seconds. You very well
could be having i/o issue, it is hard to tell from the overall average value
you provided. Collect "iostat -x 5" during the times when you see slow r
For the number of file the OP has why not just use a traditional filesystem
and solr to index the pdf data. You get to search inside of the files for
relevant information?
Sri
On Fri, Feb 4, 2011 at 12:47 PM, buddhasystem wrote:
>
> Even when storage is in NFS, Cassandra can still be quite us
On Fri, Feb 4, 2011 at 2:44 PM, David Dabbs wrote:
>
> Our data is on sdb, commit logs on sdc.
> So do I read this correctly that we're 'await'ing 6+millis on average for
> data drive (sdb)
> requests to be serviced?
>
>
That is right. Those numbers look pretty good for rotational media. What
sor
Looks like you don't have a big enough working set from your GC logs, there
doesn't seem to be a lot being reclaimed in the GC process. The process is
reclaiming a few hundred MB and is running every few seconds. How big are
your caches? The probable reason that it works the first couple times when
Sounds like GC from your description of fast->slow->fast. Collect GC times
from both the client and server side and plot against your application
timing.
If you uncomment the verbose GC entries in the cassandra-env.sh file you
should get timing for the server side, pass in the same arguments for
Force a GC to remove the unused sstables. Use something like jconsole or cmd
line "jmap -histo:live ". You would run the jmap command as the
cassandra user or root. The jmap will give you a bunch of output on live
objects in the heap if you choose to look at it.
Sridhar
On Tue, Mar 22, 2011 at 8
If you can reach your jmx ip/port, you can use any jmx client to start a
compaction. Use jconsole to connect to your jmx ip/port and then navigate to
mbeans->org.apache.cassandra.db->columnfamilies-> ->operations
Underneath there you can invoke a bunch of methods including compaction.
Sridha
Have you already looked at some research out of IBM about this usecase?
Paper is at
http://ewh.ieee.org/r6/scv/computer/nfic/2009/IBM-Jun-Rao.pdf
Sridhar
Yes, on linux atleast, lsof would show you that. lsof -d mem -p . You
can also look at /proc//maps, again linux centric.
Sridhar
On Thu, Oct 14, 2010 at 3:44 PM, B. Todd Burruss wrote:
> thx, it does say that in the log, but that is probably just a reflection
> of whatever is read from cassan
15 matches
Mail list logo