Yikes .. no matter how much memory you allocate, it'll eventually consume it?
I ran into this problem a few times and I reviewed the application code looking for the cause through testing. A memory profiler can work, but I've found them to be somewhat unwieldy and difficult. Dumps can also give a good clue to what is happening .. one of the biggest offenders that I found was in a loop was being created large strings that were stored in a static collection or an instance level variable. I would recommend testing your application and noting which services seem to result in increased memory. Then, code review those services, first and fix memory leaks. Then re-test, repeat. If all services seem to result in rampant memory consumption you might check code common to all services like database connection management or some commonly used library. This would be great since you can fix the code on one place and it would apply to all services. I've fixed this type of issue a lot .. being able to read the code and find memory leaks without a profiler is .. a good skill to acquire. Have a super day and best of luck! John On 12/22/18, Dhaval Jaiswal <dhaval.jais...@via.com> wrote: > Application built in such a way that it consum memory and hence, it's > exhaust all memory and results in crashing Java. Probably GC is not running > when it reaches to its threshold. Is there a way I can call GC explicitly > without affecting running application. I believe need to identify the > memory consumption as well. > > > > > > > > On Sun 23 Dec, 2018, 2:23 AM Olaf Kock <tom...@olafkock.de wrote: > >> >> On 22.12.18 20:17, Dhaval Jaiswal wrote: >> > System has allocated all mentioned RAM. >> > >> > I assume 13 would be fine. >> >> Adding to John's question, what I forgot earlier: Another rule of thumb >> is to identify the *minimum* amount of memory that the application can >> run with, then add a bit of headroom. Typically there's no need to go >> with a humongous heap if garbage collection has a chance to free it all >> up quickly. Memory in webappliations typically tends to be largely >> short-lived, and (especially) the young generation GC is typically >> extremely quick. You want it to rather run often (e.g. through an >> imposed memory limit) than rarely (due to a too large heapspace). >> >> Olaf >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > -- "Innovation is hard to schedule." -- Dan Fylstra *This email and any attachments to it may be confidential and are intended solely for the use of the individual(s) to whom it is addressed. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error.* --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
