Date: Tue, 20 Oct 1998 11:48:45 -0400 (EDT) From: Thomas F Keefe <keefe@cse.psu.edu> To: ken@plutotech.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Sequential Disk I/O Message-ID: <199810201548.LAA18346@remulak.cse.psu.edu>
next in thread | raw e-mail | index | archive | help
> Thomas F. Keefe wrote... > > I am trying to write the logging portion > > of a database and have had trouble getting > > good performance. I am trying to avoid seek > > and rotational latency by writing consecutive > > 512 byte blocks to the disk. > > You'd get better performance by writing larget blocks, most likely. Yes, and I may eventually need to do this. However, I want to understand why the performance is so much worse. I can see that there will be more overhead involved, but it seems that if the requests are submitted in order and in time the throughput should approach what I would get writing large blocks. > > Here are some details. I am using > > Mach/Lites, with the drivers for the Adaptec > > aic7xxx controller ported from FreeBSD > > (the version from around 9/97). > > Is this with the old or new SCSI layer? The SCSI layer in FreeBSD was > replaced in mid-September with a new, CAM-based SCSI layer. This is the pre-CAM driver that I ported. I moved the portion of the driver specific to the adapter. (That is, the code under /usr/src/sys/i386/scsi/aic7xxx.[ch] and a few other files.) > > Is it possible to achieve sequential I/O rates > > (i.e., no seek latency and no rotational latency) > > with small write requests? Any insight you can > > provide will be appreciated. Thanks. > > One thing to keep in mind is that you won't be able to achieve very good > performance at all with small block sizes unless you're able to get a large > number of tagged transactions to the drive at one time. I can understand the need for a large number of requests for random access patterns, but if the best possible request (the adjacent sector) is available to the adapter (and perhaps the drive) why are more needed? > I don't know what your SCSI subsystem is based on (you only mentioned > porting the Adaptec driver, not which Adaptec driver or what your SCSI > subsystem is like), but if it is based on the old FreeBSD SCSI subsystem, > you'll only be able to have 4 transactions outstanding to the disk at once. I am using the SCSI layer from Mach, but have modified it to allow more than one outstanding request per target. The modifications are based loosely on the pre-CAM SCSI layer used in FreeBSD (i.e., each target has a number of openings and requests are started if the openings for the target have not been exhausted). > Another problem is that your disk supposedly has horrible tagged queueing > performance. If you're trying to get good throughput with small > transactions, I'd suggest using a drive that behaves a little better. Most > IBM and Seagate disks work pretty well. > > For instance, I've got an IBM Ultrastar 9ZX (9G, 10000RPM). Running iozone > with 512 byte blocks for a 256MB file, I get: > > IOZONE performance measurements: > 8054322 bytes/second for writing the file > 14070326 bytes/second for reading the file > > With 64K blocks, I get: > > IOZONE performance measurements: > 14559211 bytes/second for writing the file > 15929410 bytes/second for reading the file > > This is on a filesystem of course, not a raw device. And this is with CAM, > not the old SCSI subsystem. So it is possible to get better performance > with small block sizes. You probably just need to get a better disk and > make sure you can handle more outstanding tagged transactions. I also get better performance when using the file system. I guess that is because the writes shipped to the controller are actually 8Kbytes blocks. Do these disks have write caching turned on? I have shut mine off and this makes a big difference in the throughput. I can get several MB/sec with it turned on and only about 50KB/sec with it off. Thanks for your response. Tom Keefe keefe@cse.psu.edu > Ken > -- > Kenneth Merry > ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810201548.LAA18346>