Can you describe your use-case (queries) and usage patterns (concurrency) a bit? Then it might become more obvious why the caches get filled that quickly and which other cache config could help.
And you can always get enterprise and try out the hpc cache. Michael Am 18.02.2014 um 22:09 schrieb George Vincent <[email protected]>: > Thanks Mark. Do you have any suggestion for the CMS collector configuration > to start with, given that in community edition, Neo4j tries to evict the > cache using GC as it gets full ? > > > > On Tue, Feb 18, 2014 at 9:32 AM, Mark Needham <[email protected]> wrote: > D'oh sorry I didn't answer that bit. Yeh CMS is what most people go with. I > think I've seen one user go with G1 but CMS should work fine. > > > On 18 February 2014 13:44, George Vincent <[email protected]> wrote: > Thanks a lot, Mark! > > >> Assuming that you're not on windows the memory mapping stuff is done off > >> heap so no GC to worry about. > Correct. This will be running on Linux. > > >> I haven't measured the exact numbers but I'd suggest memory mapping as > >> much of the store files as you can and then use what you have left over > >> for the cache. (i.e. heap size). > Sounds good. > > >> So, is it recommended to go with CMS collector with the available heap ? > Any thoughts on the GC setting to go with for the application (with the > webapp + embedded server set up)? > > > On Tuesday, 18 February 2014 03:34:53 UTC-5, Mark Needham wrote: > Hi George, > > > I presume setting the memory mapped configuration will not affect GC > > Assuming that you're not on windows the memory mapping stuff is done off heap > so no GC to worry about. > > > Is that far more important than allocating java heap to cache > > nodes/relationships? > > I haven't measured the exact numbers but I'd suggest memory mapping as much > of the store files as you can and then use what you have left over for the > cache. (i.e. heap size). > > > The reason to pick embedded server is that we can wrap a webapp around it, > > and have all the application logic including cyper queries > > live in this application > > You could still do a similar thing using Neo4j server. That way you won't mix > up the GC cycles of your application and Neo4j which can be annoying at > times. > > Cheers > Mark > > > On 18 February 2014 04:31, George Vincent <[email protected]> wrote: > Thanks Mark. I'm evaluating a situation where I may have 8GB RAM or 16GB RAM. > But it's not guaranteed that RAM will always be larger than the data size. > The server may have 2 dual/quad core CPUs. > > If I understand correctly, the link is suggesting to allocate memory based on > the size consumed by node store and relationship store on the disk. Is that > far more important than allocating java heap to cache nodes/relationships? > > I presume setting the memory mapped configuration will not affect GC. So, is > it recommended to go with CMS collector with the available heap (after > setting the memory mapping) ? > > The reason to pick embedded server is that we can wrap a webapp around it, > and have all the application logic including cyper queries live in this > application. We can have as many clients talking to this app. > > Thanks again. > > On Saturday, 15 February 2014 05:50:23 UTC-5, Mark Needham wrote: > Hi George, > > It depends how much RAM you have on the machine. Generally we suggest memory > mapping as much of the store as possible > (http://docs.neo4j.org/chunked/stable/configuration-io-examples.html) and > then use the memory you have left over for your JVM heap. > > The actual numbers depend on the spec of the machine so you'd have to give > more information on that. > > Any reason you want to use it embedded rather than use server? > > Cheers > Mark > > > > On 14 February 2014 15:55, George Vincent <[email protected]> wrote: > Hi there, > > I'm thinking of using Embedded graph in a web application. I'm anticipating > that the graph size would be ~10 GB. What would be a good GC configuration to > start with? > > This will run inside a tomcat app. > > Any help will be highly appreciated. > > thanks, > George > > -- > You received this message because you are subscribed to the Google Groups > "Neo4j" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > You received this message because you are subscribed to the Google Groups > "Neo4j" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > You received this message because you are subscribed to the Google Groups > "Neo4j" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > You received this message because you are subscribed to a topic in the Google > Groups "Neo4j" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/neo4j/rkt5ZiKaqkU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > Thanks, > George > > Ph: +1 617 771 8517 (US) > > > -- > You received this message because you are subscribed to the Google Groups > "Neo4j" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
