Hey guys,
Do to loooong URL lookups, the DNLC was pushed to variable
sized entries. The hit rate was dropping because of
"name to long" misses. This was done long ago while I
was at Sun under a bug reported by me..
I don't know your usage, but you should attempt to
estimate the amount of mem used with the default size.
Yes, this is after you start tracking your DNLC hit rate
and make sure it doesn't significantly drop if the ncsize
is decreased. You also may wish to increase the size and
again check the hit rate.. Yes, it is posible that your
access is random enough that no changes will effect the
hit rte.
2nd item.. Bonwick's mem allcators I think still have the
ability to limit the size of each slab. The issue is that
some parts of the code expect non mem failures with
SLEEPs. This can result in extended SLEEPs, but can be
done.
If your company generates changes to your local source
and then you rebuild, it is possible to pre-allocate a
fixed number of objects per cache and then use NOLSLEEPs
with returning values that indicate to retry or failure.
3rd.. And could be the most important, the mem cache
allocators are lazy in freeing memory when it is not
needed by anyone else. Thus, unfreed memory is effectively
used as a cache to remove latencies of on-demand
memory allocations. This artificially keeps memory
usage high, but should have minimal latencies to realloc
when necessary.
Also, it is possible to make mods to increase the level
of mem garbage collection after some watermark code
is added to minimize repeated allocs and frees.
Mitchell Erblich
----------------
"Jason J. W. Williams" wrote:
>
> Hi Robert,
>
> We've got the default ncsize. I didn't see any advantage to increasing
> it outside of NFS serving...which this server is not. For speed the
> X4500 is showing to be a killer MySQL platform. Between the blazing
> fast procs and the sheer number of spindles, its perfromance is
> tremendous. If MySQL cluster had full disk-based support, scale-out
> with X4500s a-la Greenplum would be terrific solution.
>
> At this point, the ZFS memory gobbling is the main roadblock to being
> a good database platform.
>
> Regarding the paging activity, we too saw tremendous paging of up to
> 24% of the X4500s CPU being used for that with the default arc_max.
> After changing it to 4GB, we haven't seen anything much over 5-10%.
>
> Best Regards,
> Jason
>
> On 1/10/07, Robert Milkowski <[EMAIL PROTECTED]> wrote:
> > Hello Jason,
> >
> > Thursday, January 11, 2007, 12:36:46 AM, you wrote:
> >
> > JJWW> Hi Robert,
> >
> > JJWW> Thank you! Holy mackerel! That's a lot of memory. With that type of a
> > JJWW> calculation my 4GB arc_max setting is still in the danger zone on a
> > JJWW> Thumper. I wonder if any of the ZFS developers could shed some light
> > JJWW> on the calculation?
> >
> > JJWW> That kind of memory loss makes ZFS almost unusable for a database
> > system.
> >
> >
> > If you leave ncsize with default value then I belive it won't consume
> > that much memory.
> >
> >
> > JJWW> I agree that a page cache similar to UFS would be much better. Linux
> > JJWW> works similarly to free pages, and it has been effective enough in the
> > JJWW> past. Though I'm equally unhappy about Linux's tendency to grab every
> > JJWW> bit of free RAM available for filesystem caching, and then cause
> > JJWW> massive memory thrashing as it frees it for applications.
> >
> > Page cache won't be better - just better memory control for ZFS caches
> > is strongly desired. Unfortunately from time to time ZFS makes servers
> > to page enormously :(
> >
> >
> > --
> > Best regards,
> > Robert mailto:[EMAIL PROTECTED]
> > http://milek.blogspot.com
> >
> >
> _______________________________________________
> 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
