Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 03 Nov 2000 06:56:53 -0800
From:      Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>
To:        Matt Dillon <dillon@earth.backplane.com>
Cc:        Marius Bendiksen <mbendiks@eunet.no>, Alfred Perlstein <bright@wintelcom.net>, Randell Jesup <rjesup@wgate.com>, arch@FreeBSD.ORG
Subject:   Re: Like to commit my diskprep 
Message-ID:  <200011031457.eA3Evdr39709@cwsys.cwsent.com>
In-Reply-To: Your message of "Thu, 02 Nov 2000 19:39:09 PST." <200011030339.eA33d9D43976@earth.backplane.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <200011030339.eA33d9D43976@earth.backplane.com>, Matt Dillon 
writes:
> 
> :
> :>     Indirect blocks aren't relevant if you are using a large block size, 
> :>     because there are few enough of them the OS has no problem caching
> :>     them.
> :
> :The problem is related to highly random access, as the indirect blocks
> :will tend to get pushed out of the cache on occasion, requiring multiple
> :seeks when the file is being accessed. Using extents will solve this.
> :
> :>     32K block size	4MB
> :
> :Note that these 4MB are better spent on caching real data than they are on
> :compensating for the absence of extents in the FFS inode.
> :..
> :
> :>     It becomes somewhat more of an issue for a terrabyte-sized database,
> :>     but still no biggy considering the memory you can get these days.
> :
> :I reiterate the above point. The kind of memory in question here is really
> :way over the top, compared to the 8/16 bytes required to hold an extent
> :reference and the bit to indicate that the inode uses such.
> :
> :Marius
> 
>    Lets put things into perspective here.  You have a multi-gig or terrabyte
>    database, and that pretty much means you have to at least a gig of ram
>    in the machine that's going to be accessing it.  Otherwise why bother
>    with caching at all?
> 
>    If you have a machine with a gig of ram, losing 4MB is REALLY not a big
>    deal.

Assuming an Oracle database of that size, you probably want at least 
12-16 GB of memory with 80% of it used for SGA.  I would think that 
most other DBMS's would have the same features and requirements.

The Veritas filesystem (vxfs) has an option to turn of caching for for 
a specified filesystem.  Otherwise Oracle would cache in the SGA and 
the filesystem would cache as well.  Prior to this, performance wise, 
you'd be better off using raw slices.

The ability to turn of caching of data, while still caching metadata, 
would be a good mount or tunefs option for applications that perform 
their own caching, e.g. Oracle.


Regards,                       Phone:  (250)387-8437
Cy Schubert                      Fax:  (250)387-5766
Team Leader, Sun/DEC Team   Internet:  Cy.Schubert@osg.gov.bc.ca
Open Systems Group, ITSD, ISTA
Province of BC





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




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