Thomas is asking the right questions. Especially, the system specs. You'll need at least a 1Gb RAM for each 1Tb of disk. If you are running a lean system that doesn't have enough RAM, then ZFS won't be able to pre-fetch data. Caching is pretty important on systems with a large amount of data. If you are using dedup, you'll need at least 5Gb of RAM for each 1Tb of disk. I would assume that you have enough RAM because you can still mount your pool(s). >From the lag issues that you've described it kind of sounds like it could be a RAM issue. ZFS like ECC RAM, but that's really only important for checksumming and parity computations. ZFS uses RAM in all sorts of interesting ways, but it sounds like you might not have enough RAM for your read-cache to be working correctly(or at all). How are your write speeds? I you are having write speed issues as well as reads, then I would say that points to RAM issues as well. All the writes that come into the zpools get queue up to the write-cache before the are added to the Intent Log and flushed to disk. I'm not sure about any alignment issue, but like Thomas alluded to if your pool is nearing capacity you could see some performance degradation as well. I have a buddy that uses 3ware 6gbps RAID controllers, but he's running BSD. I'm not certain that would matter, but ZFS and BSD tend to play nice. Can you give us your system specs? -> Jake On Sat, Feb 8, 2014 at 1:09 PM, T L <tlunde at gmail.com> wrote: > Re: performance issues? > > How full is the pool? > How much RAM does the system have? > Are the ZFS options for de-duplication or compression turned on? > Are you using a L2ARC cache? > If you have any 4k drives, are the filesystem partitions aligned optimally > (ashift=12 maybe)? > > Thomas > On Feb 8, 2014 11:09 AM, <tclug at freakzilla.com> wrote: > >> Hello people, >> >> Alright, my RAID/ZFS drama continues. The thing was working perfectly for >> a few months, and now performance has turned abysmal. It's a 16TB array >> running as a media server. If there's one client streaming data, no >> problem. Even two. But add a bunch of little things accessing the pool and >> it crawls. You hit Play on a video and there's a 5 second delay before >> starting. Skip a music track, again, 5 second delay. Kinda risiculous, >> right? >> >> No errors anywhere, zpool srub found nothing wrong, etc. The server's >> load average, though, is always super high (like >4, sometimes up to 6), a >> lot of waiting for IO. >> >> The only idea I have is that using the system's built-in SATA to run >> eight 3tb harddrives is not able to keep up with demands. So I'm thinking >> of getting a nice SATA expeansion card to off-load some of the processing >> off the CPU, hopefully that'll help. >> >> So, a couple questions: >> >> 1. Can anyone think of any other reason the filesystem is suddenly acting >> like this? It was fine when there was less data on it. >> >> 2. I feel it should be seemless to move the ZFS pool/drive array from one >> SATA connection to another. I this correct? The array uses two separate >> SATA connections, but I figure worst case I plug them in in the wrong >> order, it fails, I reverse them and restart and no problem. Is this >> true? I don't want to nuke my ZFS pool... >> >> 3. Can anyone recommend a good SATA card with e-SATA ports? I have one >> that came with the drive enclosure but it is not Linux compatible. >> >> >> Thanks! >> _______________________________________________ >> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota >> tclug-list at mn-linux.org >> http://mailman.mn-linux.org/mailman/listinfo/tclug-list >> > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20140208/628ca8a0/attachment.html>