error on /var/log/messages --> oom problem?

[billt-lxSQFCZeNF4 at public.gmane.org]

On Fri, May 06, 2005 at 09:50:46AM -0400, David Thornton wrote:
> I highly recommend setting up monitoring tools to examine the memory 
> usage over time.
> 
> http://www.quadratic.net/~david/gnuplot/#Sar_Analysis
> 
> As far as I can tell linux caches disk reads until all memeory is used 
> (at least iwth this version). Which leaves precious little headroom for 
> new allocations.
> I have yet to understand all of this, despite reading up a bit:
This is done to maximize performance. Prefetching pages that might be used in the future (example the next few pages of that document that open office has open) speeds up performance.

There are well documented (and I believed well coded) algorithms to do this.

Your suggestion of monitoring the problem is right on.

Also David's short term answer of adding swap space to figure out how much memory is needed is an important part of the solution. It is my personal belief, but a slow computer still doing its job is a better indicator of the problem than a catastrophic failure.

> 
> http://www.csn.ul.ie/~mel/projects/vm/guide/pdf/understand.pdf
> 
> I'm a big ITIL freek, so a reboot crosses me as "incident management" 
> and really fixing the cause is "problem management".
> Reboot is a good short term fix (incident resolution) , but we should be 
> working toward the long term fix (problem resolution).
I agree but when you start seeing out of memory in the logs you're already screwed anyway.
> 
> In our case we had 5 web servers running tomcat. We moved to resin and 
> the problem went away.
> 
> Java apps are notorius ( in my experiance) with being poorly created. My 
> experience has been that app delveopers think that because of all the 
> fancy memory management that java does , they can build apps that use 
> memeory like it's an unlimited resource. I'm not an software dev guy so 
> I'm relegated to pooring through code I don't "get" and suggesting that 
> maybe an sql lookup would be better than a java collection.
> 
This is a different rant, so I will only say I agree.

--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml