[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: Web server Partitions

I have separate directories for each website but they are in /var.
Is there any particular reason why you have yours in /home? I tend to
keep /home strictly for users home directory's. There isn't many users
that will have shell access, but my home directory is usually quite
large 3=).

The plan is that all development of code for websites will be done by a
user in there shell account uploaded to CVS and then when it is ready it
will be deployed in /var/www or /var/www2 etc.

I currently have 1GB of swap space which seams sufficient, 2GB seems a
bit excessive. I was told that the rule of thumb is double the amount of
physical RAM.

My main concern is running out of space in a partition once everything
is setup and running. So I want to be sure before I go ahead. It's a
shame that there isn't a tool for Linux like Partition Magic. I have
always been to freaked out to resize partitions on an existing
installation of Linux.

What do people think about the following:

/ - 7GB
/usr - 10GB
/home - 10GB
/var - 10GB
/tmp - 1.5GB
SWAP - 1.5GB


-----Original Message-----
From: Edward Murrell [mailto:edward@murrell.co.nz] 
Sent: Tuesday, 16 December 2003 2:12 PM
To: debian-user@lists.debian.org
Subject: Re: Web server Partitions

On Tue, 2003-12-16 at 16:38, Braxton Neate wrote:
> Hi Everyone,
> I know this is a question that gets asked a lot, but googling around I

> can't seem to find a good answer. I'm re-installing a web/sql server 
> which currently has one large root partition and a swap partition.
> This is obviously not the best setup. 
> I'm wondering what other people would recommend in the way of 
> partitioning?
> The server is a 2x 800mhz PIII with 512MB RAM and a 40GB hard drive.
> There will be 3 main users of this system. This box would probably get
> around 200 hits a day max, but also hosts and internal intranet as
> as an external website so there is quite a bit of data in /var/www.
> -Braxton Neate

The first thing I'd look at doing is moving the default webpage to a
directory in /home/. In the case of my companies webserver, there's
/home/mcnz/ directory, with various company sites in directories off
that. People who have admin rights to the website accounts are part of
the webedit group.

With that in mind, I would divy up your drive as follows
(the following assumes that the server doesn't have any major mail
server roles (/var/), that /usr/local/ will be free of anything major,
that there's no NFS mounting, and that the server will run a database
that will keep things somethere in /lib/, and that /home/ will stay
mostly free of general user files.

/	- 10 GB
/home/	- 20 GB
/lib/	- 2 GB
/var/	- 1 GB
/tmp/	- 5 GB
swap	- 2 GB

The reasoning behind large swap, /tmp/, /var/, and /lib/ file systems
that are partition off, is due to Joe Random Webdeveloper doing some
creative web developing on the server. At some point, someone is likely
to try and do something funky like try and run licq through php, and
chew through several gigs of storage of infinitely recursive log files.
(Yes, I had something like this a few years ago, thankfully, it was on a
test server.)

I have a webserver with a similar setup, and the swap goes unused most
of the time, but with anything where people have shell access,
eventually someone does something stupid, and you end up being thankful
for that extra memory space.

The reason for /tmp/ comes from various things that write there, that
don't always clean up properly, and things that put files there before
doing something to them, and that happening multiple times. One of my
users once had a stats package that chewed through 1500 MB of data in
about two hours, and then would condense it down to less than 100 kb of
text. It took me about two weeks to discover why users would complain of
running out of space, but whenever I got the email, they would have more
than enough.

At the end of the day, partitioning the drives up seems to be a case of
not so much what's going to work, but what's going to go wrong.


To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact

Reply to: