Jill Manfield wrote:
My customer is running java on a ZFS file system. His platform is Soalris 10
x86 SF X4200. When he enabled ZFS his memory of 18 gigs drops to 2 gigs rather
quickly. I had him do a # ps -e -o pid,vsz,comm | sort -n +1 and it came back:
The culprit application you see is java:
507 89464 /usr/bin/postmaster
515 89944 /usr/bin/postmaster
517 91136 /usr/bin/postmaster
508 96444 /usr/bin/postmaster
516 98088 /usr/bin/postmaster
503 3449580 /usr/jre1.5.0_07/bin/amd64/java
512 3732468 /usr/jre1.5.0_07/bin/amd64/java
Here is what the customer responded:
Well, Java's is a memory hog, but it's not the leak -- it's the
application. Even after it fails due to lack of memory, the memory is
not reclaimed and we can no longer restart it.
Is there a bug on zfs? I did not find one in sunsolve but then again I might
have been searching the wrong thing.
We have done some slueth work and are starting to think our problem
might be ZFS -- the new file system Sun supports. The documentation for
ZFS states that it tries to cache as much as it can, and it uses kernel
memory for the cache. That would explain memory gradually disappearing.
ZFS can give memory back, but it does not do so quickly.
Yup, this is likely your problem. ZFS takes a little time to "give
back" memory, and the app may fail with ENOMEM before this happens.
So, is there any way to check that? If turns out to be the problem...
1) Is there a way to limit the size of ZFS's caches?
Well... sort of. You can set the size of arc.c_max and this will
put an upper bound on the cache. But this is a bit of a hack.
If not, then
2) Is there a way to clear ZFS's cache?
Try unmounting/mounting the file system, if that does not work,
try export/import of the pool.
-Mark
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss