[Fwd: [H-GEN] partitioning again]

[Robert Stuart]

(Note reply-to: being general at humbug.org.au vs Robert Stuart <rstu at qbssss.edu.au>)

I've reforwarded this because I couldn't post to the general list.....

Robert Stuart wrote:
> 
> James McPherson wrote:
> >
> > well from an enterprise point of view (ie we run oracle ;>), that sort of
> > scheme is laughable because there are just too many things which can go wrong
> > if there is not enough space - we can't afford that possibility. On the
> > machine I admin, we generally have two internal disks (we only do scsi btw),
> > and any number of external disks on separate fast/wide controllers on which we
> > have the following:
> >
> > /dev/dsk/c0t0d0s0      57143   19234   32195    38%    /
> > /dev/dsk/c0t0d0s1     962582  399296  505532    45%    /usr
> > /dev/dsk/c0t0d0s4     448143  207353  195976    52%    /var
> > swap                 1069220  252500  816720    24%    /tmp
> > /dev/dsk/c0t1d0s0     480919  126977  329897    28%    /opt
> > /dev/dsk/c0t1d0s1     962582  476992  437461    53%    /home
> >
> > ^^these are the internal disks - luns 0 and 1 on the internal chain.
> 
> I use one large _fs_ for /, /usr, and /var (see below) on our Solaris
> servers because we are running SDS and the root disk is mirrored.  It is
> simply easier to manage that way.  We also have UPSs (and the building
> has emergency power) so I am not concerned about losing the fs except
> due to some sort of software problem screwing the root fs which
> partitioning can't help anyhow.  This solves my fs space problems too
> (var filling etc). The one issue I have with this is root fs' disks
> performance because is holds both swap and root (and usr var ...), both
> of which are hit heavily when the machine is loaded.
> 
> Comments?
> 
> [snip]
> 
> > While we're at it, what do people think about Solaris' use of tmpfs for
> > virtual memory? This what we're seeing at the moment on this particular
> > machine:
> >
> > # swap -l
> > swapfile             dev  swaplo blocks   free
> > /dev/dsk/c0t0d0s3   32,3       8 1024472 721296
> > /dev/dsk/c0t1d0s3   32,11      8 1080712 770976
> >
> > interestingly, before we cut over to 100Mbit (hme0 is the standard 100Mbit
> > device - the hme stands for "happy meal" ;>), we were seeing about 50% swap
> > utilization - now it rarely gets above 30%. (Yes, that was the _only_ thing we
> > changed).
> >
> > Comments/queries anybody? Or is Solaris the Dark Side ? ;)
> 
> That's a bit odd (the use of /tmp being reduced by change to 100Mbit).
> Three possibities I can think of:
> 1. memory leak in driver for old 10Mbit....
> 2. something else changed (how clients access the DB?) that caused your
> users to use the DB server in a different way, hence using less memory
> (eg fewer oracle server processes running?).  Any DB parameters change
> (and DB restarted due to shutdown)?
> 3. something else had a memory leak that you haven't triggered again or
> just plain used a heap of memory at some stage (memory doesn't get
> released back to the OS until the process finishes).
> 
> You seem to be using a huge amout of swap (~250MB).  Unless you have
> large files in /tmp, I'd suggest you get more memory.  I think having
> /tmp as virtual memory is great.  Our stats are as follows:
> 
> #df -k
> Filesystem            kbytes    used   avail capacity  Mounted on
> /dev/md/dsk/d2        963869  640089  265948    71%    /
> /dev/md/dsk/d6       17398449 9602512 7621953    56%    /md6
> swap                 1440600    5976 1434624     1%    /tmp
> 
> #swap -l
> swapfile             dev  swaplo blocks   free
> /dev/md/dsk/d5      85,5      16 2050432 1993488
> 
> We haven't even touched our swap space (and we have 1GB of it) - its a
> fairly quiet time of year for us.  As a result, all of the files in /tmp
> are in memory -> fast access etc.  This is great until someone decides
> to put a couple of huge files in /tmp, but Solaris then moves them onto
> real disk space over time.
> As you can see, our root fs has heeps of space (the only print jobs are
> small PCL stuff - this machine is a DB server).
> 
> /md6 is made up of 4 9GB SCSI drives striped and mirrored.
> 
> NB we use DB files rather than raw paritions (at this point in time, we
> can afford to shutdown the DB every night for backup).
> 
> --
> Robert Stuart
> Ph  61-7-3864 0364

-- 
Robert Stuart
Ph  61-7-3864 0364

--
This is list (humbug) general handled by majordomo at lists.humbug.org.au .
Postings only from subscribed addresses of lists general or general-post.