From: Ming Z. <mi...@el...> - 2006-03-10 15:06:22
|
* open-iscsi has newer code, u can get from svn://svn.berlios.de/open-iscsi * we need more information about the HW configuration of your boxes. * how you produce large # of parallel r/w and can you reproduce this every time. * some of your description looks at ini side, some are target side. pretty mixed. so it is quite hard to understand. when u mention fopen, it is ini side? then iowait 60-70%, it is ini or target side? ming On Thu, 2006-03-09 at 22:18 -0500, Jeff Hardy wrote: > I have iscsitarget-0.4.13 exporting some block devices to a box running > open-iscsi-1.0-485. Both boxes are running linux-2.6.14.6. I have done > all kinds of read and write tests and gotten great performance with scsi > exports, AoE exports, RAID exports, lvm exports, etc. > > However I am having a problem when I do lots of parallel writes on a > volume. Many of the processes end up in the 'D' state for lengthy > periods of time, and with lots of parallel reads and writes (thousands) > I can often overburden things to the point where things just grind to a > halt. > > Here are my iet settings for each of the volumes: > > InitialR2T=No > ImmediateData=Yes > MaxConnections=1 > MaxRecvDataSegmentLength=8192 > MaxXmitDataSegmentLength=8192 > MaxBurstLength=262144 > FirstBurstLength=65536 > DefaultTime2Wait=2 > DefaultTime2Retain=0 > MaxOutstandingR2T=1 > DataPDUInOrder=Yes > DataSequenceInOrder=Yes > ErrorRecoveryLevel=0 > HeaderDigest=None > DataDigest=None > OFMarker=No > IFMarker=No > OFMarkInt=Reject > IFMarkInt=Reject > Wthreads 16 > > > On the open-iscsi side: > > node.transport_name = tcp > node.tpgt = 1 > node.active_conn = 1 > node.startup = manual > node.session.initial_cmdsn = 0 > node.session.reopen_max = 32 > node.session.auth.authmethod = None > node.session.auth.username = <empty> > node.session.auth.password = <empty> > node.session.auth.username_in = <empty> > node.session.auth.password_in = <empty> > node.session.timeo.replacement_timeout = 0 > node.session.err_timeo.abort_timeout = 10 > node.session.err_timeo.reset_timeout = 30 > node.session.iscsi.InitialR2T = No > node.session.iscsi.ImmediateData = Yes > node.session.iscsi.FirstBurstLength = 262144 > node.session.iscsi.MaxBurstLength = 16776192 > node.session.iscsi.DefaultTime2Retain = 0 > node.session.iscsi.DefaultTime2Wait = 0 > node.session.iscsi.MaxConnections = 0 > node.session.iscsi.MaxOutstandingR2T = 1 > node.session.iscsi.ERL = 0 > node.conn[0].address = 10.10.0.1 > node.conn[0].port = 3260 > node.conn[0].startup = manual > node.conn[0].tcp.window_size = 524288 > node.conn[0].tcp.type_of_service = 0 > node.conn[0].timeo.login_timeout = 15 > node.conn[0].timeo.auth_timeout = 45 > node.conn[0].timeo.active_timeout = 5 > node.conn[0].timeo.idle_timeout = 60 > node.conn[0].timeo.ping_timeout = 5 > node.conn[0].timeo.noop_out_interval = 0 > node.conn[0].timeo.noop_out_timeout = 0 > node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072 > node.conn[0].iscsi.HeaderDigest = None,CRC32C > node.conn[0].iscsi.DataDigest = None > node.conn[0].iscsi.IFMarker = No > node.conn[0].iscsi.OFMarker = No > > > > I can only say it seems to be a concurrency issue, with lots going on on > the volume. Even with just a few hundred random read or write ops, just > requesting an fopen() can take several seconds. Overall processor load > (2 processors) is low but wait states run 60-70%. Doubling the Wthreads > value seems to have helped a bit. Is there anything I am missing that > might help with this? > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Iscsitarget-devel mailing list > Isc...@li... > https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel |