On Thu, May 20, 2010 at 8:34 PM, Richard Elling <richard.ell...@gmail.com> wrote: > On May 20, 2010, at 11:07 AM, Asif Iqbal 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? > > The application is not driving enough load to make the bandwidth be > higher. Why? Because it is an Oracle database and will be making > sync writes, by default. Since you do not have a working battery, those > writes are taking 10-40ms each. Replace your battery.
replaced the battery on the 3510 FC array sccli> show battery-status Upper Battery Type: 1 Upper Battery Manufacturing Date: Tue Mar 30 00:00:00 2010 Upper Battery Placed In Service: Wed Jun 2 19:49:34 2010 Upper Battery Expiration Date: Sat Jun 2 07:49:34 2012 Upper Battery Expiration Status: OK sccli: retrieving battery status: error: not an existing target --------------------------------------------------------------- Upper Battery Hardware Status: OK Lower Battery Hardware Status: N/A active service time still pretty high http://pastebin.com/TRs6UDqm current write cache policy is write-back sccli> show cache-parameters mode: write-through optimization: sequential sync-period: disabled current-global-write-policy: write-back > -- richard > >> >> here are some iodata which make the t2000/3510 setup looks even worse >> >> http://pastebin.com/QeAKDbfj >> >> >>> >>> -- >>> 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 > > -- > ZFS and NexentaStor training, Rotterdam, July 13-15, 2010 > http://nexenta-rotterdam.eventbrite.com/ > > > > > > > -- 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
