Jim Mauro writes:
>
> > Where does the win come from with "directI/O"? Is it 1), 2), or some
> > combination? If its a combination, what's the percentage of each
> > towards the win?
> >
> That will vary based on workload (I know, you already knew that ... :^).
> Decomposing the performance win between what is gained as a result of
> single writer
> lock breakup and no caching is something we can only guess at, because,
> at least
> for UFS, you can't do just one - it's all or nothing.
> > We need to tease 1) and 2) apart to have a full understanding.
>
> We can't. We can only guess (for UFS).
>
> My opinion - it's a must-have for ZFS if we're going to get serious
> attention
> in the database space. I'll bet dollars-to-donuts that, over the next
> several years,
> we'll burn many tens-of-millions of dollars on customer support
> escalations that
> come down to memory utilization issues and contention between database
> specific buffering and the ARC. This is entirely my opinion (not that of
> Sun),
...memory utilisation... OK so we should implement the 'lost cause' rfe.
In all cases, ZFS must not steal pages from other memory consumers :
6488341 ZFS should avoiding growing the ARC into trouble
So the DB memory pages should not be _contented_ for.
-r
> and I've been wrong before.
>
> Thanks,
> /jim
>
>
>
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
