Re: I'm new to Prevayler: Best Java settings and practices for Prevayler?
Naveen Chawla <[email protected]>
| Newsgroups | gmane.comp.java.prevayler |
|---|---|
| Message-ID | <CAGs7EcVhjEbZG1O7r9ARkt2C1r=-B-7JmGcfnyBgpRY8VRzymQ@mail.gmail.com> |
Small question, why is it not a good idea for me to induce garbage collection regularly? Given your next statement that "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." I may be missing something, but won't inducing garbage collection regularly, actually prevent larger pauses in the future, for high memory scenarios? That Zing JVM from Azul sounds fantastic, but it's outside my price range. Reading Gil Tene on the "pauseless" GC http://www.artima.com/lejava/articles/azul_pauseless_gc.html, it says "We figured that to have a smooth, wide operating range and high scalability we pretty much have to solve the hardest problem all the time" "Our collector is different. The only way it ever collects is to compact the heap. It's the only thing we ever do." Isn't this the rough equivalent of calling an ordinary garbage collector each time, (albeit with maybe some efficiency improvements done by them)? i.e. if I induce garbage collection myself, won't it be anything like basically a "poor man's" Zing JVM? Excuse me if these are stupid questions. On 12 October 2011 22:11, Ralph Johnson <[email protected]> wrote: > 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 > ------------------------------------------------------------------------------ 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