Yeah I was a little suspicious of my mkfile in tmpfs test so I went ahead and wrote a program not so different than this one.

The results were the same. I could only allocate about 512M before things went bad.

 --joe

Nathan Kroenert wrote:

Something I often do when I'm a little suspicious of this sort of
activity is to run something that steals vast quantities of memory...

eg: something like this:

#include <stdio.h>
#include <stdlib.h>

int main() {

       int memsize=0;
       char *input_string;
       char *memory;
       long i=0;
input_string=malloc(256 * sizeof(char));

       printf("How much memory? :");
       input_string=fgets(input_string, 255, stdin);
       memsize=atoi(input_string);

       printf("mem_size=%d\n", memsize);
memory=calloc(memsize*1024*1024, 1);

       printf("Pausing: hit enter to exit\n");

       input_string=fgets(input_string, 255, stdin);
exit(0);

}


which allows me to request, say, 500mb of memory. Watching vmstat whilst
doing this is interesting.
It then runs and uses lots of memory, and causes some pressure.
If, at the end when it exits, you have lots of memory free, and nothing
swapped out, it's all good. :)

quick, dirty, possibly even smelly, with no error checking at all...
:)

Nathan.



On Fri, 2006-07-21 at 09:28, Eric Schrock wrote:
There two things to note here:

1. The vast majority of the memory is being used by the ZFS cache, but
  appears under 'kernel heap'.  If you actually need the memory, it
  _should_ be released.   Under UFS, this cache appears as the 'page
  cache', and users understand that it can be released when needed.
  The same is true of ZFS, but it's just not accounted for as separate
  memory.  Now, the VM hooks needed to do this are somewhat add hoc at
  the moment, but the ZFS cache should keep itself from consuming 100%
  of the available memory.

2. There is a difference between VA (virtual addressing) and physical
  memory.  See the following thread for a more complete discussion:

  http://www.opensolaris.org/jive/thread.jspa?threadID=10774&tstart=45&start=15

So the (apparent) high kernel memory consumption is expected, and does
not indicate any type of problem.  Applications actually receiving
ENOMEM should not happen, and may indicate that there are some
circumstances where the VM interfaces are currently inadequate.  Someone
else on the ZFS team may be able to get some more specifics from you to
figure out what's really going on.

- Eric

On Thu, Jul 20, 2006 at 04:03:50PM -0700, Joseph Mocker wrote:
So what's going on! Please help. I want my memory back!
This is essentially by design, due to the way that ZFS uses kernel
memory for caching and other stuff.

You can alleviate this somewhat by running a 64bit processor, which
has a significantly larger address space to play with.
Uhh. If I don't have any more physical memory, how does a 64bit processor help?

FWIW, this is on a SunBlade 2000 running in 64bit mode:

[EMAIL PROTECTED]: uname -a
SunOS watt 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Blade-1000
[EMAIL PROTECTED]: isainfo
sparcv9 sparc

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
--
Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to