PROBLEM: Memory

PROBLEM: Memory

[Michael May]

Hi folks,


I think there is a little Problem with Kernel 2.4.17-pre4 - pre7

When the machine in up for longer than 2 days and is under higher load, the processes will killed, with some syslog-messages: 

kernel: Out of memory: Killed process <pid>

I don't know what the Problem is, and all machines where it is, are SMP-Machines on i386.

Two times, I traced the problem and the system reported full memory.
But, the processes and the Utilities are the same like before updating the kernel,
except the gcc (is now 3.0.3)


Can you solve this?

-----------------------------------
Michael May - UNIX-Administration
+49/2241/497-2742
-----------------------------------

Re: PROBLEM: Memory

[Alan Cox]

> I think there is a little Problem with Kernel 2.4.17-pre4 - pre7
> 
> When the machine in up for longer than 2 days and is under higher load, the processes will killed, with some syslog-messages: 
> 
> kernel: Out of memory: Killed process <pid>
> 
> I don't know what the Problem is, and all machines where it is, are SMP-Machines on i386.

If you use the rmap patches this one seems to go away. The 2.4.17 vm is still
not quite perfect for all cases. 

Re: PROBLEM: Memory

[mukesh agrawal]

> Hi folks,
>
>
> I think there is a little Problem with Kernel 2.4.17-pre4 - pre7
>
> When the machine in up for longer than 2 days and is under higher load, the processes will killed, with some syslog-messages:
>
> kernel: Out of memory: Killed process <pid>
>
> I don't know what the Problem is, and all machines where it is, are SMP-Machines on i386.
>
> Two times, I traced the problem and the system reported full memory.
> But, the processes and the Utilities are the same like before updating the kernel,
> except the gcc (is now 3.0.3)

If this is the same problem that I'm seeing, what's happening is that the
buffer and cache memory (as reported in top) is not being freed early
enough.

In my situation, what happens is that (over time), buffers+cache grows to
80MB or more (out of 320MB total available; no swap). Factoring in the
memory used by running processes, the uncommitted memory falls to <10MB.
Then, when Mozilla or StarOffice tries to allocate some more memory, the
OOM killer picks one of them instead of shrinking the cache.

I'd check the amount of memory allocated to buffers and cache after one
your OOM events and see if that explains why you're now seeing low memory
conditions with the same workload.