1

Customer is experiencing poor Sybase ASE 15 performance on a PS6000X SAN with 16 X 450GB 10K in RAID-50. The server is a Dell R710 running 2003 server R2 64bit in ESX 4.0.0,256968

I've used sqlio to benchmark the sequential write performance of 4KB blocks on the drive. 

sqlio -kW -t1 -s600 -dE -o1 -fsequential -b4 -BH -LS sqliotestfile.dat

Result is 1900 IOPS. However, when Sybase is running a sustained workload of small inserts SAN HQ shows a consistent 590 IOPS (and 100% 4K write activity). It also shows that the write latency increases to 1.2ms from <1ms.

Monitoring and tests in Sybase demonstrate the performance problem is IO related and in particular there is a lot of wait time writing to the log.

The SAN indicates that write caching is enabled.

What IOPS should the SAN be capable of for 4k sequential write activity? Also, with write caching enabled, shouldn't the controller be batching up the 4K writes into something more efficient?

Also, any tips on Sybase on ESX would be appreciated.

dss
  • 11
  • 2

2 Answers2

1

I'd expect sequential IO to be faster than what you are seeing but sustained 4K 100% random write IO would be around 500-600IOPS for that set up [assuming 14 active disks, 10K SAS, RAID 50] so the question I'd be asking is how are you sure that the IO pattern on the volume really is sequential?

What other volumes are being presented by the PS600X and what are they used for. The Equallogic arrays do not really allow you to isolate IO patterns between volumes on the same array and if you have another volume or volumes carved out of the same disks that is experiencing random IO traffic then that could be causing this.

Helvick
  • 20,019
  • 4
  • 38
  • 55
0

First things first - Is the test file comparable in size to the real database? If not, seek times may be the differentiating factor here.

If you're not already using the vmware paravirtual scsi adapter for the log volume, I'd recommend giving it a whirl. It's not a magic fix, but certain workloads benefit from it. Usually, it adds a little latency but allows for higher overall throughput when dealing with a high number of writes.

If it's feasible, and I realise it's a big hassle, you may want to look into hooking up a physical instance of this same server directly into the SAN and running the same test, taking ESX out of the equation. Since you're reading the IOPS figures from two seperate locations and products, I would also consider that a possible factor. That said, I wouldn't expect the figures to be off by 3x.

Chris Thorpe
  • 9,953
  • 23
  • 33