I've been poking comstar pretty hard for the last week, and I've pretty much 
come to the end of my ropes-  I think in order to get things to work 
reasonably, I need a couple more knobs to twiddle.

Right now, this system is purely testing, but the desire is to make it work 
reasonably for an oracle data-warehouse workload. Right now, I'm trying to get 
it to run a scale-100 TPCH reasonably.

The hardware is a Supermicro 2-U chassis with 24 2.5" disk slots,  3x 
LSI3081E-R 8-port SAS/SATA controllers, 18x 500gb SATA disks, and a qlogic 
QLE2462 dual 4gig HBA.

The heart of what I've discovered is that COMSTAR picks a block size based on 
the device behind it, and appears to *always* issue IOs using that block size, 
no matter what the size of the requests coming in across the wire.  If the 
block device is zvol, it uses the zvol record size, which makes sense.  If the 
block device behind it is a physical disk, or SVM volume, it picks 512 bytes as 
the block size.

As best I can discern, the ZFS fragmented-by-design setup is very reasonable 
for OLTP applications, but it seems to be less than optimal for data-warehouse 
workloads, and the ZFS design is also a bit at odds with ASM, as ASM is trying 
to do certain similiar bits to ZFS by accepting a bunch of disks and spreading 
the work across them.

I've got a couple of questions for folks;
  1.  I've googled and browsed around quite a bit, and almost all the stuff I 
can find relating to using databases against ZFS/comstar is talking about 
OLTP-style databases.  Is there anyone out there getting reasonable results 
with a data-warehouse workload?

  2.  Is there any work going on with comstar to allow it to do different size 
block IOs instead of it's current approach?

  3. Lastly... is there any chance of adding a knob to sbdadm to allow us to 
specify a block size when we create a LU, especially in the case of raw disk or 
SVM back-end targets?


Thanks
   Ross
-- 
This message posted from opensolaris.org
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss

Reply via email to