On Thu, May 20, 2010 at 2:07 PM, Asif Iqbal <vad...@gmail.com> wrote: > On Thu, May 20, 2010 at 1:51 PM, Asif Iqbal <vad...@gmail.com> wrote: >> I have a T2000 with a dual port 4gb hba (QLE2462) and a 3510FC with >> one controller 2gb/s attached to it. >> I am running sol 10 u3 . >> >> every time I change the recordsize of the zfs fs the disk IO improves >> (doubles) and stay like that for >> about 5 to 6 hrs. Then it dies down. I increase the recordsize again >> and performace jumps back to >> double again. The main app is oracle database with 8K blocksize >> >> I changed the zfs recordsize to from 8K to 16K and then 32K every 8 >> hrs, which improved the disk IO >> >> I wonder if there is any other zfs parameter that I can change to keep >> the performance good, since I >> am running older sol 10. >> >> I have single disk luns on the 3510 with mpxio enabled on T2000. each >> disk has two paths (primary,primary) >> online per luxadm. >> >> zpool iostat 10 gives me only about 6MB max write bandwidth. I was >> hoping it to lot higher. >> >> the battery on 3510 is expired and waiting for a replacement. >> >> besides replacing the battery, what else can I do to improve the write >> bandwidth? >> >> does the battery expire directly affecting the oracle's disk IO? I >> thought oracle will just write to zfs and done. >> and zpool will then write-through to controller instead of write-back >> since no battery. >> >> sun storage guys found no other issue besides the battery. >> >> should disabling zil improve performance? I won't try it until we get >> the battery so not to risk data loss >> during outage. > > so my 3510 is essentially behaving like a 3510 jbod but why would that > make the IO bandwidth this low? > > here are some iodata which make the t2000/3510 setup looks even worse > > http://pastebin.com/QeAKDbfj
with a raidz2 of 6 LD 146GB 15K rpm 2gb FC disks I should expect lot higher than 7MB/s write bandwidth even when 3510FC acting as JBOD in absence of battery > > >> >> -- >> Asif Iqbal >> PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu >> A: Because it messes up the order in which people normally read text. >> Q: Why is top-posting such a bad thing? >> > > > > -- > Asif Iqbal > PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss