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 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.
