RE: [Xen-devel] tap:aio performance

["James Harper" <james.harper@xxxxxxxxxxxxxxxx>]

> >
> > Now that I have tap:aio working under GPLPV, I have found that the
> > performance is terrible (as in something is wrong). Under any sort
of
> > load, the system becomes effectively frozen - block requests appear
to
> > be taking seconds.
> >
> > Currently I have up to 16 requests 'in the air' at a time... is that
> too
> > much for tap:aio? Is there something else I could be doing wrong?
> >
> > It's got me baffled at the moment...
> >
> 
> This continues to frustrate me. I thought maybe using 'sparse' files
to
> back tap:aio might be causing problems so I freed up some space and
> created a non-sparse file, but that didn't change anything.
> 
> The backup exec restore fly's along at about 600mb/min until it has
> restored about 500mb and then it drops to about 12mb/min, and the DomU
> is effectively unusable (anything that needs disk activity takes
forever
> to get there...). Once the restore finally cancel's (this takes a long
> time too) the performance comes back to being usable.
> 
> Next I'll try it under Linux instead of GPLPV... but I can't think why
> that would make a difference...
> 

Just for the archives, I have resolved the problem. The disks are all on
a HP Smart Array E200 controller using the cciss driver. Using a disk on
the onboard SATA interface instead, tap:aio can easily sustain restore
throughput of over 600mb/min.

Looking more closely, the raid controller and Ethernet adapter are both
sharing an interrupt, so I think that the Ethernet interrupts were being
serviced at the expense of the raid interrupts.

I'll try moving the raid controller to a different slot and I'm sure
that the problem will go away, but either way the problem is not xen or
tap:aio related.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel