Date: Wed, 4 Mar 2009 00:53:30 -0000 From: "Steven Hartland" <killing@multiplay.co.uk> To: "Barry Pederson" <bp@barryp.org>, "Mike Tancsa" <mike@sentex.net> Cc: FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: HEADS UP: Major CAM performance regression Message-ID: <A6604B9BCB15496980ACA8304444633C@multiplay.co.uk> References: <499551B9.7050805@samsco.org><200902172307.n1HN74ml025580@pyroxene.sentex.ca><49AD6130.8040703@barryp.org> <200903031840.n23IeXuk032580@lava.sentex.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
That's areca fix is a really interesting fix for us. I applied it to our
rrd graph machine which constantly becomes unresponsive currently under
high IO load for periods at a time.
I can confirm that we also now get Command Queuing Enabled and that
camcontrol tags da0 is reporting more that is expected.
(pass0:arcmsr0:0:0:0): device openings: 255
I cant say for sure if this has helped as our testing is quite
subjective for the most part i.e. does my ssh session stop responding.
I can however say the machine is still locking on a regular basis
apparently due to the IO load as its doing very little else.
Our test here is to run a very simple piece of C:
[code]
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int main( char **argv, int argc )
{
time_t last = time( NULL );
while ( 1 )
{
time_t now = time( NULL );
time_t diff = now - last;
if ( diff >= 2 )
{
fprintf( stderr, "stalled for %d seconds\n", diff );
}
fprintf( stderr, ctime( &now ) );
last = now;
sleep ( 1 );
}
exit( 0 );
}
[/code]
[log]
Wed Mar 4 00:31:36 2009
Wed Mar 4 00:31:37 2009
stalled for 4 seconds
Wed Mar 4 00:31:41 2009
Wed Mar 4 00:31:42 2009
Wed Mar 4 00:31:43 2009
Wed Mar 4 00:31:44 2009
Wed Mar 4 00:31:45 2009
stalled for 5 seconds
Wed Mar 4 00:31:50 2009
Wed Mar 4 00:31:51 2009
stalled for 4 seconds
Wed Mar 4 00:31:55 2009
Wed Mar 4 00:31:56 2009
stalled for 2 seconds
Wed Mar 4 00:31:58 2009
Wed Mar 4 00:31:59 2009
[/log]
As you can see above there a several multi second pauses where above exe
was stalled.
At the points of stall the process using serious IO are bufdaemon and
or syncer.
Anyway off thread, thanks for alot for fix to the areca driver Scott, I'm
sure it will even if it doesnt totally solve our performance issue here.
Regards
Steve
----- Original Message -----
From: "Mike Tancsa" <mike@sentex.net>
> At 11:56 AM 3/3/2009, Barry Pederson wrote:
>
>>I can report a "metoo" on a 7.0-RELEASE-p3 machine with an Areca
>>ARC-1212 card and SATA drives. "camcontrol tags da0" reports:
>>
>> (pass0:arcmsr0:0:0:0): device openings: 1
>>
>>The machine is just a dog sometimes. Haven't tried the patch though.
>
>
> RELENG_7 has all the fixes in. There seem to be quite a few cam
> fixes plus the one areca fix. With the patches, post reboot I now see
>
> da1: Command Queueing Enabled
>
> raw throughput seems to be the same (which is should). It when there
> are multiple reads/writes that the biggest difference should show up.
>
> ---Mike
>
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
>
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A6604B9BCB15496980ACA8304444633C>