Everything is clear now.
Thanks for explanation.

Best regards

Nenad Bošnjak, M.Sc. MCITP, MCSA, MCTS, VCP, LPIC-1

IT Specialist at ComTrade Group
Banja Luka, Bosnia and Herzegovina

On Mon, Apr 23, 2012 at 8:08 AM, Ross S. W. Walker <RWalker@medallion.com> wrote:
On Apr 23, 2012, at 1:52 AM, "Nenad Bosnjak" <ned123@gmail.com> wrote:

> What I would like to know just for curiosity is why performance are shared inside target? Is it just the lack of MC/S (which if I'm correct none of OSS implementation haven't got anyway) or something else prevent saturation of target server NIC's. I use blockIO, dualcore 3GHz Xeon and 2GB RAM (cca 1GB free) so it's not hardware. On the other hand almost all commercial iSCSI targets I ran into can have only one target...

The performance bottleneck is the fact that there is a single disk queue per-target, not volume ,which causes multiple IO streams to different drives to fragment and randomize.

> I know of necessity to start with LUN0 but thanks for head start. In case of one LUN per target should I change for example the >>Wthreads<< value or having 64 threads is perfectly OK, system is used only for iSCSI and only other user daemon is Adaptec ASM (unfortunately java).

The more wthreads the better the random IO performance and the worse the sequential IO performance, the less wthreads is the opposite.

I have found 8 to be the perfect balance between random/sequential performance.

To get best MPIO performance with ESX make sure the MPIO driver does 1 IO per path.


This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.