Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 Aug 2007 06:57:36 -0600
From:      Scott Long <scottl@samsco.org>
To:        "Lutieri G." <lutierigbtrabalho@gmail.com>
Cc:        FREEBSD - SCSI - LIST <freebsd-scsi@freebsd.org>
Subject:   Re: performance with LSI SAS 1064
Message-ID:  <46D6BEC0.1050104@samsco.org>
In-Reply-To: <71d0ebb0708300502x632fe83bo617f84ca2008dc7d@mail.gmail.com>
References:  <71d0ebb0708291245g79d2141fx73cc8a6e76875944@mail.gmail.com>	 <46D5E17F.3070403@samsco.org>	 <71d0ebb0708291416v17351c65u7ccc1b7bbe0271d2@mail.gmail.com>	 <46D5E5B1.207@samsco.org>	 <71d0ebb0708291506i49649a60l8006deafb20891ac@mail.gmail.com>	 <46D63710.1020103@freebsd.org> <71d0ebb0708300502x632fe83bo617f84ca2008dc7d@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Lutieri G. wrote:
> 2007/8/30, Eric Anderson <anderson@freebsd.org>:
>> I'm confused - you said in your first post you were getting 3MB/s, where
>>   above you show something like 55MB/s.
> Sorry! using blogbench i got 3MB/s and 100% busy. Once is 100% busy i
> thinked that 3MB/s is the maximum speed. But i was wrong...

%busy is a completely useless number for a anything but untagged,
uncached disk subsystems.  It's only an indirect measure of latency, and
there are better tools for measuring latency (gstat).

>> You didn't say what kind of disks, or how many, the configuration, etc -
>> so it's hard to answer much.  The 55MB/s seems pretty decent for many
>> hard drives in a sequential use state (which is what dd tests really).
>>
> SAS disks. Seagate, i don't know what is the right model of disks.
> 
> Ok. If 55Mb/s is a decent speed i'm happy. I'm getting problems with
> squid cache and maybe should be a problem related with disks. But...
> i'm investigating and discharging problems.
> 
> 
>> Your errors before were probably caused because your queue depth is set
>> to 255 (or 256?) and the adapter can't do that many.  You should use
>> camcontrol to reduce it, to maybe 32.  See the camcontrol man page for
>> the right usage.  It's something that needs setting on every boot, so a
>> startup file is a good place for it maybe.
>>
> Is there any way of get the right number to reduce?!
> 

If you're seeing erratic performance in production _AND_ you're seeing
lots of accompanying messages on the console about tag depth jumping
around, you can use camcontrol to force the depth to a lower number of
you're choosing.  This kind of problem is pretty rare, though.

Scott




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46D6BEC0.1050104>