From: Nenad B. <ne...@gm...> - 2012-04-23 07:29:42
|
Everything is clear now. Thanks for explanation. Best regards Nenad * * *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 <RW...@me...>wrote: > On Apr 23, 2012, at 1:52 AM, "Nenad Bosnjak" <ne...@gm...> 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. > > -Ross > > > > ______________________________________________________________________ > 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. > > |