When I looked for references on ARC freeing algo, I did find some lines
of codes talking about freeing ARC when memory is under pressure.
Nice...but what could be memory under pressure in the kernel syntax ?
Jumping from C lines to blogs to docsI went back
On 06/06/10 18:58, Brad Diggs wrote:
> Apps that attempt to acquire a large amount of data on startup can fail
> to start properly if ZFS does not free
> up the memory fast enough. I have observed this with Directory Server.
"Fast enough?" The model I was expecting here was a bit more
synchronou
Thanks to all you guys to give me more insight on the ZFS cache .. we had
rebooted the system over the weekend and the zfs arc cache now sits at 5.7G
only and fusion guys were able to start their application after the reboot.
Thanks again to all.
--
This message posted from opensolaris.org
Apps that attempt to acquire a large amount of data on startup can fail to start properly if ZFS does not freeup the memory fast enough. I have observed this with Directory Server. The best approach that I have found is to understand how you want RAM used on the system and then configure the ZFS
Ketan wrote:
> Let me know what command you want me to run on it for kstat /truss
>
> as per kstat zfs:0:zrcstats:size the size is approximately 40G
Since there are a bunch of ways that the problem that Jason King was
describing could manifest, I think the only way to do this would be to
get
Let me know what command you want me to run on it for kstat /truss
as per kstat zfs:0:zrcstats:size the size is approximately 40G
--
This message posted from opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Are you sure fusion isn't checking the amount of available memory
itself and just deciding to abort?
It wouldn't be unprecendeted -- if you run Oracle RDBMS on NFS mounts,
it refuses to start unless it sees explicit mount options provided for
the database filesystems (even when they are merely aff
> Sure ... but that refers specifically to DR-related issues,
DR-related issues with kernel cage unable to return memory.
In case you are on a DR-capable system you have troubles with
DR itself. On other HW kernel won't just return memory to OS.
> and that's
> not what the original poster compla
Petr Benes wrote:
>> That leaves unanswered the underlying question: why do you need to do
>> this at all? Isn't the ZFS ARC supposed to release memory when the
>> system is under pressure? Is that mechanism not working well in some
>> cases ... ?
>
> http://bugs.opensolaris.org/bugdatabase/view
> That leaves unanswered the underlying question: why do you need to do
> this at all? Isn't the ZFS ARC supposed to release memory when the
> system is under pressure? Is that mechanism not working well in some
> cases ... ?
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6522017
"
Petr Benes wrote:
> add to /etc/system something like (value depends on your needs)
>
> * limit greedy ZFS to 4 GiB
> set zfs:zfs_arc_max = 4294967296
>
> And yes, this has nothing to do with zones :-).
That leaves unanswered the underlying question: why do you need to do
this at all? Isn't the
add to /etc/system something like (value depends on your needs)
* limit greedy ZFS to 4 GiB
set zfs:zfs_arc_max = 4294967296
And yes, this has nothing to do with zones :-).
Regards,
Petr
On 03/06/2010, Ketan wrote:
> We are having a server running zfs root with 64G RAM and the system has 3
> z
Try zfs-discuss.
Ketan wrote:
We are having a server running zfs root with 64G RAM and the system has 3 zones running oracle fusion app and zfs cache is using 40G memory as per
kstat zfs:0:arcstats:size. and system shows only 5G of memory is free rest is taken by kernel and 2 remaining zones
We are having a server running zfs root with 64G RAM and the system has 3 zones
running oracle fusion app and zfs cache is using 40G memory as per
kstat zfs:0:arcstats:size. and system shows only 5G of memory is free rest is
taken by kernel and 2 remaining zones.
Now my problem is that fusi
14 matches
Mail list logo