Re: I'm new to Prevayler: Best Java settings and practices for Prevayler?
Ralph Johnson <[email protected]>
| Newsgroups | gmane.comp.java.prevayler |
|---|---|
| Message-ID | <CAB_aMcsAaebgHi6euwe+-GBM=yA4sSF45HS4RFTa9BS-tP14CQ@mail.gmail.com> |
In general, you should not induce garbage collection, but let it do its job. The exception is if there are periods where you know that the system is going to be idle for a few seconds, and then you want to be able to run full-out. But since it sounds like you are planning a web app, you should just let the garbage collector do its job. How big will the heap be? If it is going to be larger than a few GB, the collection time is probably going to cause some pauses that are longer than you wish. If it is only half a GB then modern garbage collectors will be very fast. Pauses get longer as the heap gets larger. So, if you are going to have a lot of memory, you need to get a vm with a pauseless g.c. I just heard a talk from an engineer from Azul (http://www.azulsystems.com/) describe their VM. I haven't tried it, and have no idea which other VMs are good enough, but I know that not all VMs will handle a lot of memory without sometimes having long pauses. You need to have someone on your team who understands the performance of garbage collectors. That person should know the details of your vm. Is it using a copying collector? Generational? There are probably different algorithms for different generations. How much space should be allocated to each? How many of each class do you have, and how much bytes of each? I have been using Java VisualVM to find out memory use, and it is a good tool. it doesn't matter whether you use instance variables or local variables from the point of view of memory performance. Techniques that are useful in C++ to manage memory are often bad ideas in Java. How big do you expect your database to be? That is a key question. -Ralph Johnson On Wed, Oct 12, 2011 at 1:48 PM, Naveen Chawla <[email protected]> wrote: > I'm (maybe unjustifiably) scared of potentially big crippling garbage > collections/allocation failures etc., but haven't really experienced them or > how to minimize them. > > Should I use a fixed or variable sized heap? If fixed, should it just be as > big as I can make it? (What % of your total memory have you made it?) If > variable, what settings should I best use (Xms, Xmx, Xminf, Xmaxf, Xmine, > Xmaxe)? Should I be conscious of potentally large crippling garbage > collections? If so, should I prefer instance variables over local variables, > or does it matter? Should I induce garbage collection regularly, or just let > it do it itself? > > Just wondering if there are any special known best Java settings and > practices for Prevayler because of its potentially big memory size etc. > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct > _______________________________________________ > To unsubscribe go to the end of this page: > http://lists.sourceforge.net/lists/listinfo/prevayler-discussion > _______________________________________________ > "Databases in Memoriam" -- http://www.prevayler.org > > ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion _______________________________________________ "Databases in Memoriam" -- http://www.prevayler.org