Ah ok, I wont be using dedup anyway just wanted to try. Ill be adding more ram though, I guess you can't have too much. Thanks
Erik Trimble <erik.trim...@oracle.com> wrote: >You can't really do that. > >Adding an SSD for L2ARC will help a bit, but L2ARC storage also consumes >RAM to maintain a cache table of what's in the L2ARC. Using 2GB of RAM >with an SSD-based L2ARC (even without Dedup) likely won't help you too >much vs not having the SSD. > >If you're going to turn on Dedup, you need at least 8GB of RAM to go >with the SSD. > >-Erik > > >On Tue, 2011-01-18 at 18:35 +0000, Michael Armstrong wrote: >> Thanks everyone, I think overtime I'm gonna update the system to include an >> ssd for sure. Memory may come later though. Thanks for everyone's responses >> >> Erik Trimble <erik.trim...@oracle.com> wrote: >> >> >On Tue, 2011-01-18 at 15:11 +0000, Michael Armstrong wrote: >> >> I've since turned off dedup, added another 3 drives and results have >> >> improved to around 148388K/sec on average, would turning on compression >> >> make things more CPU bound and improve performance further? >> >> >> >> On 18 Jan 2011, at 15:07, Richard Elling wrote: >> >> >> >> > On Jan 15, 2011, at 4:21 PM, Michael Armstrong wrote: >> >> > >> >> >> Hi guys, sorry in advance if this is somewhat a lowly question, I've >> >> >> recently built a zfs test box based on nexentastor with 4x samsung 2tb >> >> >> drives connected via SATA-II in a raidz1 configuration with dedup >> >> >> enabled compression off and pool version 23. From running bonnie++ I >> >> >> get the following results: >> >> >> >> >> >> Version 1.03b ------Sequential Output------ --Sequential Input- >> >> >> --Random- >> >> >> -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- >> >> >> --Seeks-- >> >> >> Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP >> >> >> /sec %CP >> >> >> nexentastor 4G 60582 54 20502 4 12385 3 53901 57 105290 10 >> >> >> 429.8 1 >> >> >> ------Sequential Create------ --------Random >> >> >> Create-------- >> >> >> -Create-- --Read--- -Delete-- -Create-- --Read--- >> >> >> -Delete-- >> >> >> files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP >> >> >> /sec %CP >> >> >> 16 7181 29 +++++ +++ +++++ +++ 21477 97 +++++ +++ >> >> >> +++++ +++ >> >> >> nexentastor,4G,60582,54,20502,4,12385,3,53901,57,105290,10,429.8,1,16,7181,29,+++++,+++,+++++,+++,21477,97,+++++,+++,+++++,+++ >> >> >> >> >> >> >> >> >> I'd expect more than 105290K/s on a sequential read as a peak for a >> >> >> single drive, let alone a striped set. The system has a relatively >> >> >> decent CPU, however only 2GB memory, do you think increasing this to >> >> >> 4GB would noticeably affect performance of my zpool? The memory is >> >> >> only DDR1. >> >> > >> >> > 2GB or 4GB of RAM + dedup is a recipe for pain. Do yourself a favor, >> >> > turn off dedup >> >> > and enable compression. >> >> > -- richard >> >> > >> >> >> >> _______________________________________________ >> >> zfs-discuss mailing list >> >> zfs-discuss@opensolaris.org >> >> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >> > >> > >> >Compression will help speed things up (I/O, that is), presuming that >> >you're not already CPU-bound, which it doesn't seem you are. >> > >> >If you want Dedup, you pretty much are required to buy an SSD for L2ARC, >> >*and* get more RAM. >> > >> > >> >These days, I really don't recommend running ZFS as a fileserver without >> >a bare minimum of 4GB of RAM (8GB for anything other than light use), >> >even with Dedup turned off. >> > >> > >> >-- >> >Erik Trimble >> >Java System Support >> >Mailstop: usca22-317 >> >Phone: x67195 >> >Santa Clara, CA >> >Timezone: US/Pacific (GMT-0800) >> > >-- >Erik Trimble >Java System Support >Mailstop: usca22-317 >Phone: x67195 >Santa Clara, CA >Timezone: US/Pacific (GMT-0800) > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
