spreading partitions over multiple drives

Willem Jan Withagen wjw at withagen.nl
Fri Sep 10 15:02:15 PDT 2004

Geert Hendrickx wrote:

>On Fri, Sep 10, 2004 at 03:21:46PM +0200, Willem Jan Withagen wrote:
>>I would expect a bigger system to cache just about all file access 
>>during 'make buildworld'.
>>Even when building things with -j 64 I can not get my dual-opteron 1Gb 
>>system  get without free pages.
>>And as such most files will only be read once, and object output will be 
>>"slowly" synced on the disks.
>>Disk I/O rearly becomes the bottleneck, most of the time I'm missing raw 
>>CPU cycles.
>>And I have everything on 1 large 200Gb disk.
>Ok so adding more RAM may be more useful than an extra harddisk?  Maybe
>I could even put /tmp or /usr/obj on a RAM-disk?  A fully built /usr/obj
>is about 350Mb.  
It would be wise to consider these things rather different. It used to 
be black magic in the time of Sun Files and/or work servers and  I guess 
it has not changed all that much.

Since there is now a unified buffer the disctinction between the 2 has 
sort of faded, but in general you need as much memory as you need for 
running concurrent application where you sum the size of the workset of 
each of the applications. Hence you prevent swapping and/or paging as 
much as possible.
New in the equation is that that same memory know could also hold the 
file cache. (This used to be a hard configurable limit, set 
before/whilest booting not to be changed after that)
So you'll require extra memory for this as well.

How much?? Again that depends on you concurrent applications and the 
frequency they return to read/write certain files.... Binaries used to 
have something like a sticky bit, so that the OS would know that these 
executables were in high demand, e.g. ls(1) on a multi-user server. And 
thus it would be kept a little longer in the file-cache....

Memory is cheap, I payed the other day something like < 100 Euro for 
512Mb. I chose to use more memory versus buying faster processors. Next 
thing I would do is increase the number of spindels (aka disks), 
especially on the boxes that have losts of access from different clients 
for very different things.


More information about the freebsd-performance mailing list