Hi Dale, We're testing out the enhanced arc_max enforcement (track DNLC entries) using Build 72 right now. Hopefully, it will fix the memory creep, which is the only real downside to ZFS for DB work it seems to me. Frankly, of our DB loads have improved performance with ZFS. I suspect its because we are write-heavy.
-J On 10/3/07, Dale Ghent <[EMAIL PROTECTED]> wrote: > On Oct 3, 2007, at 10:31 AM, Roch - PAE wrote: > > > If the DB cache is made large enough to consume most of memory, > > the ZFS copy will quickly be evicted to stage other I/Os on > > their way to the DB cache. > > > > What problem does that pose ? > > Personally, I'm still not completely sold on the performance > (performance as in ability, not speed) of ARC eviction. Often times, > especially during a resilver, a server with ~2GB of RAM free under > normal circumstances will dive down to the minfree floor, causing > processes to be swapped out. We've had to take to manually > constraining ARC max size so this situation is avoided. This is on > s10u2/3. I haven't tried anything heavy duty with Nevada simply > because I don't put Nevada in production situations. > > Anyhow, in the case of DBs, ARC indeed becomes a vestigial organ. I'm > surprised that this is being met with skepticism considering that > Oracle highly recommends direct IO be used, and, IIRC, Oracle > performance was the main motivation to adding DIO to UFS back in > Solaris 2.6. This isn't a problem with ZFS or any specific fs per se, > it's the buffer caching they all employ. So I'm a big fan of seeing > 6429855 come to fruition. > > /dale > _______________________________________________ > 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
