On 3/9/2010 1:55 PM, Matt Cowger wrote: > That's a very good point - in this particular case, there is no option to > change the blocksize for the application. > > I have no way of guessing the effects it would have, but is there a reason that the filesystem blocks can't be a multiple of the application block size? I mean 4 4kb app blocks to 1 16kb fs block sounds like it might be a decent comprimise to me. Decent enough to make it worth testing anyway.
-Kyle > On 3/9/10 10:42 AM, "Roch Bourbonnais" <roch.bourbonn...@sun.com> wrote: > > >> I think This is highlighting that there is extra CPU requirement to >> manage small blocks in ZFS. >> The table would probably turn over if you go to 16K zfs records and >> 16K reads/writes form the application. >> >> Next step for you is to figure how much reads/writes IOPS do you >> expect to take in the real workloads and whether or not the filesystem >> portion >> will represent a significant drain of CPU resource. >> >> -r >> >> >> Le 8 mars 10 à 17:57, Matt Cowger a écrit : >> >> >>> Hi Everyone, >>> >>> It looks like I¹ve got something weird going with zfs performance on >>> a ramdiskS.ZFS is performing not even a 3rd of what UFS is doing. >>> >>> Short version: >>> >>> Create 80+ GB ramdisk (ramdiskadm), system has 96GB, so we aren¹t >>> swapping >>> Create zpool on it (zpool create ramS.) >>> Change zfs options to turn off checksumming (don¹t want it or need >>> it), atime, compression, 4K block size (this is the applications >>> native blocksize) etc. >>> Run a simple iozone benchmark (seq. write, seq. read, rndm write, >>> rndm read). >>> >>> Same deal for UFS, replacing the ZFS stuff with newfs stuff and >>> mounting the UFS forcedirectio (no point in using a buffer cache >>> memory for something that¹s already in memory) >>> >>> Measure IOPs performance using iozone: >>> >>> iozone -e -i 0 -i 1 -i 2 -n 5120 -O -q 4k -r 4k -s 5g >>> >>> With the ZFS filesystem I get around: >>> ZFS >>> >>> (seq >>> write) 42360 (seq read)31010 (random >>> read)20953 (random write)32525 >>> Not SOO bad, but here¹s UFS: >>> UFS >>> (seq >>> write )42853 (seq read) 100761 (random read) >>> 100471 (random write) 101141 >>> >>> For all tests besides the seq write, UFS utterly destroys ZFS. >>> >>> I¹m curious if anyone has any clever ideas on why this huge >>> disparity in performance exists. At the end of the day, my >>> application will run on either filesystem, it just surprises me how >>> much worse ZFS performs in this (admittedly edge case) scenario. >>> >>> --M >>> _______________________________________________ >>> 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 > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
