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.
