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

Reply via email to