Hi.
After having firefox killed by the OOM-killer due to a totem running wild (and watching the killer churn the disks for 5 minutes to do so, what the heck is it doing?), I ventured to try a hard overcommit limit (which setting vm.overcommit_memory=2 does, to the best of my knowledge). The system in question has 640MB RAM, no swap.
The result is that almost nothing works, even with plenty of memory free. It's even impossible to get a simple man page to display:
[sun@nausicaa ~/src/gmemusage-0.2 :) 23]$ free total used free shared buffers cached Mem: 645152 366636 278516 0 16900 106340 -/+ buffers/cache: 243396 401756 Swap: 0 0 0 [sun@nausicaa ~/src/gmemusage-0.2 :) 24]$ man sysctl sh: fork: Cannot allocate memory sh: fork: Cannot allocate memory Error executing formatting or display command. System command (cd /usr/share/man && (echo ".ll 11.8i"; echo ".pl 1100i"; /usr/bin/gunzip -c '/usr/share/man/man8/sysctl.8.gz'; echo ".\""; echo ".pl \n(nlu+10") | /usr/bin/gtbl | nroff --legacy ISO-8859-1 -man -rLL=129n -rLT=129n 2>/dev/null | /usr/bin/less -iRs) exited with status 32768. No manual entry for sysctl
The system has nearly 400MB of free memory. What does it take to display some lines of text these days?
--- Ralf Ertzinger fedora-devel@camperquake.de wrote:
Hi.
After having firefox killed by the OOM-killer due to a totem running wild (and watching the killer churn the disks for 5 minutes to do so, what the heck is it doing?), I ventured to try a hard overcommit limit (which setting vm.overcommit_memory=2 does, to the best of my knowledge). The system in question has 640MB RAM, no swap.
The result is that almost nothing works, even with plenty of memory free. It's even impossible to get a simple man page to display:
a bug report with other important information like the exact ernel version number would be useful
===== Regards Rahul Sundaram
__________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250
Hi.
Rahul Sundaram rahulsundaram@yahoo.co.in wrote:
a bug report with other important information like the exact ernel version number would be useful
A bug report against what? I do not think this is the kernels fault. The kernel I tried on was 2.6.10-1.1143_FC4
Ralf Ertzinger wrote: <SNIP>
A bug report against what? I do not think this is the kernels fault. The kernel I tried on was 2.6.10-1.1143_FC4
I wouldn't make the assumption that its not the kernel, seems like its the kernel for sure? For instance:
sh: fork: Cannot allocate memory sh: fork: Cannot allocate memory
This is not a good sign when you have free memory, but on the surface this does indeed to be a kernel problem... who you think decides there is no memory? :)
-sb
On Thu, Feb 17, 2005 at 10:56:59AM -0500, Stan Bubrouski wrote:
sh: fork: Cannot allocate memory sh: fork: Cannot allocate memory
This is not a good sign when you have free memory, but on the surface this does indeed to be a kernel problem... who you think decides there is no memory? :)
Of course it is the kernel that ultimately decides if a memory request can be served. But after all it is the application that requests the memory (in most cases, that is), and various programs allocate large chunks of memory but never use it. This does not matter much when you have overcommit on, but fails without it. In this special case however a strace shows that the clone() system call fails with -ENOMEM, which is a bit strange, at least for me.
So it seems I will file a kernel bug for this after all.
On Thu, 17 Feb 2005, Ralf Ertzinger wrote:
But after all it is the application that requests the memory (in most cases, that is), and various programs allocate large chunks of memory but never use it.
So it seems I will file a kernel bug for this after all.
NOTABUG
You configured the kernel to not overcommit memory, so it won't. It makes sure that all the memory that was requested is available for programs to use, regardless of whether programs actually use it.
Hi.
Rik van Riel riel@redhat.com wrote:
NOTABUG
You configured the kernel to not overcommit memory, so it won't. It makes sure that all the memory that was requested is available for programs to use, regardless of whether programs actually use it.
How much memory does it take to clone() a bash?
Ralf Ertzinger wrote:
Hi.
Rik van Riel riel@redhat.com wrote:
NOTABUG
You configured the kernel to not overcommit memory, so it won't. It makes sure that all the memory that was requested is available for programs to use, regardless of whether programs actually use it.
How much memory does it take to clone() a bash?
*chuckle*
-sb = a continuous waste of bandwith :)
On Fri, Feb 18, 2005 at 04:25:09PM +0100, Ralf Ertzinger wrote:
Hi.
Rik van Riel riel@redhat.com wrote:
NOTABUG
You configured the kernel to not overcommit memory, so it won't. It makes sure that all the memory that was requested is available for programs to use, regardless of whether programs actually use it.
How much memory does it take to clone() a bash?
$ ps -o size,vsz,rss,args SZ VSZ RSS COMMAND 1428 6244 2212 -bash
About 1428MB, I guess. Not that it would be consumed, but that the kernel must guarantee to be available.
Regards, Luciano Rocha
Luciano Miguel Ferreira Rocha wrote:
How much memory does it take to clone() a bash?
$ ps -o size,vsz,rss,args SZ VSZ RSS COMMAND 1428 6244 2212 -bash
About 1428MB, I guess. Not that it would be consumed, but that the kernel must guarantee to be available.
Regards, Luciano Rocha
Erm.. Perhaps I'm a bit behind on things, but I though the SZ field shows the number of pages that a process is using, not the number of Megs guaranteed. That'd make your estimate just a few orders of magnitude high.
The VSZ will give your answer in bytes rather than pages. That's the total process size in virtual memory, displayed in KB. The RSS is the amount of that's actually IN memory. The discrepency between these numbers would then indicate, at least in a crude way, the difference between what the app thinks it's using versus what the OS actually has tied up in the process.
So, you're looking at something more along the lines of 6MB, rather than 1.4GB; with 2M actually used.
Someone care to check my math?
On Fri, Feb 18, 2005 at 11:50:39PM -0700, Tyler Larson wrote:
Luciano Miguel Ferreira Rocha wrote:
How much memory does it take to clone() a bash?
$ ps -o size,vsz,rss,args SZ VSZ RSS COMMAND 1428 6244 2212 -bash
About 1428MB, I guess. Not that it would be consumed, but that the kernel must guarantee to be available.
Regards, Luciano Rocha
Erm.. Perhaps I'm a bit behind on things, but I though the SZ field shows the number of pages that a process is using, not the number of Megs guaranteed. That'd make your estimate just a few orders of magnitude high.
The VSZ will give your answer in bytes rather than pages. That's the total process size in virtual memory, displayed in KB. The RSS is the amount of that's actually IN memory. The discrepency between these numbers would then indicate, at least in a crude way, the difference between what the app thinks it's using versus what the OS actually has tied up in the process.
They're both in KB, my mistake.
So, you're looking at something more along the lines of 6MB, rather than 1.4GB; with 2M actually used.
Actually, from the manual page: size SZ approximate amount of swap space that would be required if the process were to dirty all writable pages and then be swapped out. This number is very rough!
So, if it is correct, about 1.4MB.
Regards, Luciano Rocha
Hi.
Rik van Riel riel@redhat.com wrote:
You configured the kernel to not overcommit memory, so it won't. It makes sure that all the memory that was requested is available for programs to use, regardless of whether programs actually use it.
Is the amount of memory that 'free' reports as 'free' (or /proc/meminfo states as 'MemFree:') the amount of unrequested memory, or does it include requested but not actually used memory?
If the latter, where can one see the amount of unrequested memory?
Ralf Ertzinger wrote:
Hi.
Rik van Riel riel@redhat.com wrote:
You configured the kernel to not overcommit memory, so it won't. It makes sure that all the memory that was requested is available for programs to use, regardless of whether programs actually use it.
Is the amount of memory that 'free' reports as 'free' (or /proc/meminfo states as 'MemFree:') the amount of unrequested memory, or does it include requested but not actually used memory?
used memory includes file-backed (cached) memory, and kernel memory, so 'free' does not fit any of your descriptions.
If the latter, where can one see the amount of unrequested memory?
total requested memory is in /proc/meminfo:Committed_AS, which is limited by swap + half ram. subtract the former from the latter to see how far you can go.
On Fri, Feb 18, 2005 at 07:13:55PM +0100, Ralf Ertzinger wrote:
Is the amount of memory that 'free' reports as 'free' (or /proc/meminfo states as 'MemFree:') the amount of unrequested memory, or does it include requested but not actually used memory?
The latter. (MemFree is physical memory, not virtual memory, by the way.)
If the latter, where can one see the amount of unrequested memory?
It's CommitLimit - Committed_AS. At one point there was a CommitAvail but it looks like it was removed in 2.6.10 because it's redundant: http://lkml.org/lkml/2004/10/24/118
BTW, with overcommit_memory=2, CommitLimit = (MemTotal * (overcommit_ratio / 100)) + SwapFree
With the default of overcommit_ratio = 50, this simplifies to: CommitLimit = (MemTotal / 2) + SwapFree
Unless you're setting overcommit_ratio to 100, this means that with 640MB of RAM and no swap, user programs are allowed to request 320MB of memory at most.
I hope this helps...
-Barry K. Nathan barryn@pobox.com
Hi.
Rex Dieter rdieter@math.unl.edu wrote:
I wouldn't even think about running a system with *0* swap these days.
Throwing (virtual) memory at the problem is certainly going to make it go away, I am sure. It just is not right. 640MB is not exactly a small amount of memory (be it real or virtual).
On Thu, 2005-02-17 at 15:32, Ralf Ertzinger wrote:
Hi.
Rex Dieter rdieter@math.unl.edu wrote:
I wouldn't even think about running a system with *0* swap these days.
Throwing (virtual) memory at the problem is certainly going to make it go away, I am sure. It just is not right. 640MB is not exactly a small amount of memory (be it real or virtual).
But the kernel has been known to behave strangely when it does not have ANY swap space at all. Even 10MB could solve the problem.
I don't know what the technical problem is but I have had customers with just this problem where it could be solved perfectly with just a little 10MB swapfile.
-HK
Hans Kristian Rosbach wrote:
But the kernel has been known to behave strangely when it does not have ANY swap space at all. Even 10MB could solve the problem.
That would, then, point to a kernel bug that needs to be fixed. Swap space is a luxury that not all systems have. Most embedded environments don't even have disks.
Adding swap isn't a solution--it's a workaround. If, indeed, it *does* fix your problem, you should include that detail in your bug report.
But the kernel has been known to behave strangely when it does not have ANY swap space at all. Even 10MB could solve the problem.
That would, then, point to a kernel bug that needs to be fixed. Swap space is a luxury that not all systems have. Most embedded environments don't even have disks. Adding swap isn't a solution--it's a workaround. If, indeed, it *does* fix your problem, you should include that detail in your bug report.
Anything new on this? I'm seeing the same problem - and I'm running embedded, hence no swap possible...
BR, Martin Egholm
Ralf Ertzinger wrote:
Rex Dieter rdieter@math.unl.edu wrote:
I wouldn't even think about running a system with *0* swap these days.
Throwing (virtual) memory at the problem is certainly going to make it go away, I am sure. It just is not right. 640MB is not exactly a small amount of memory (be it real or virtual).
This may be a useful read:
http://sourcefrog.net/weblog/software/linux-kernel/swap.html
After having firefox killed by the OOM-killer due to a totem running wild (and watching the killer churn the disks for 5 minutes to do so, what the heck is it doing?), I ventured to try a hard overcommit limit (which setting vm.overcommit_memory=2 does, to the best of my knowledge). The system in question has 640MB RAM, no swap.
Running completely without swap is know to be dangerous..
-HK