On Sun, 22 Jun 2008, Brian Hechinger wrote: > On Sun, Jun 22, 2008 at 10:37:34AM -0500, Bob Friesenhahn wrote: >> >> Perhaps the solution is to install more RAM in the system so that the >> stripe is fully cached and ZFS does not need to go back to disk prior >> to writing an update. The need to read prior to write is clearly what >> kills ZFS update performance. That is why using 8K blocks helps >> database performance. > > How much do slogs/cache disks help in this case? I'm thinking fast SSD or > fast iRAM style devices (I really wish Gigabyte would update the iRAM to > SATA 3.0 and more ram, but I keep saying that, and it keeps not happening).
To clarify, there are really two issues. One is with updating small parts of a disk block without synchronous commit, while the other is updating parts of a disk block with synchronous commit. Databases always want to sync their data. When synchronous write is requested, the zfs in-memory recollection of that write can not be used for other purposes until the write is reported as completed since otherwise results could be incoherent. More memory helps quite a lot in the cases where files are updated without requesting synchronization but is much less useful for the cases where the data needs to be committed to disk before proceeding. Applications which want to update ZFS blocks and go fast at the same time will take care to make sure that the I/O is aligned to the start of the ZFS block, and that the I/O size is in multiples of the ZFS block size. Testing shows that performance falls off a cliff for random I/O when the available ARC cache size is too small and the write is not properly aligned or the write is smaller than the ZFS block size. If everything is perfectly aligned then ZFS still goes quite fast since it has no need to read the underlying data first. What this means for applications is that if they "own" the file, it may be worthwhile to read/write full ZFS blocks and do the final block update within the application rather than force ZFS to do it. However, if a small part of the the file is read and then immediately updated (i.e. record update), ZFS does a good job of caching in that case. Bob ====================================== Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
