Rapid once deployed too

[Brian K. White]

----- Original Message ----- 
From: "Fairlight" <fairlite at fairlite.com>
To: "filePro Mailing List" <filepro-list at lists.celestial.com>
Sent: Thursday, May 04, 2006 12:31 PM
Subject: Re: Rapid once deployed too


> Four score and seven years--eh, screw that!
> At about Thu, May 04, 2006 at 11:38:13AM -0400,
> Howie blabbed on about:
>> No offense taken Mark.  I'm sure you know a lot more about this stuff 
>> than I
>> do.
>
> Some.  Not all, as you'll see in a sec.  Glad you took no offense though.
>
>> last pid:  3580;  load averages:  0.24,  0.36,  0.27 
>> 11:
>> 1415 processes:1387 sleeping, 7 running, 19 zombie, 2 onproc
>
> There you go.  Seven processes actually running out of 1415 total.  With
> only four of them being clerk or report, that's 228 processes that don't
> really even count towards the any sort of performance benchmark because
> they're not actually doing anything significant.  19 processes aren't even
> "there" at all, having exited already and they're waiting for their parent
> to exit.


Um, call me dumb, but if a binary does it's job fast when it actually has to 
do work, and then gets to spend more time sleeping because of that, to me 
that DOES count towards claiming that binary is very efficient (which == 
fast). We dont' know from this how active the users are, it's possible 
they're all sitting there not actively updating records, or it's possible 
they are active and fp is simply keeping up.
I would estimate that no more than 20% of the processes are really idle 
background/minimized windows, because we have a pretty short idleout setting 
so idle windows go away in 20 minutes.
This was necessary to reduce the time records spend locked up when a tcp 
session breaks ungracefully.

Also, it should be noted that it's doing this well despite running on the 
slowest OS & filesystem out there.
The cpu's & rest of the box are pretty good but not the fastest available. 
The box is almost 2 years old now. 2.6 ghz xeons with 533 fsb pc2700 ram.
The disks are still just about state of the art. 10 u320 disks in a raid10 
array split evenly over 2 u320 channels on a 64bit 133mhz LSI card with the 
cards cache options all set to the performance settings vs the safe settings 
(the card has it's own battery for the cache so it's reasonably safe).
Also, I've turned off both checkpointing and journalling in the htfs 
filesystem which improves performance some, at the cost of about an hour 
long fsck (170g fs) instead of a minute or so when the box reboots 
ungracefully. Even so the fs is still massively slow compared to any other 
current fs running on the same hardware.

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!