(This is a forward of some private mail with the original poster,
with his permission.)
Date: Sun, 24 Nov 2002 22:59:33 -0500
From: Brian Reichert [EMAIL PROTECTED]
To: Sweethome.co.il Webmaster [EMAIL PROTECTED]
Cc: Brian Reichert [EMAIL PROTECTED]
Subject: Re: MySQL on virtual hosting
On Mon, Nov 25, 2002 at 03:15:00AM +0200, Sweethome.co.il Webmaster wrote:
The Virtual dedicated systems will need much more resources in real life.
I can't imagine having 40 MySQL servers running at once when I can't
restrain a single one :)
You can constrain a single one, very easily:
# nice limits -d whatever -m whatever /usr/local/mysql/libexec/mysqld
Of course, you may not want the jail methodology in general; I'm
not trying to trick you into it, by any means.
If you're virtual hosting, there is the implication that you have
more than one customer on a single system, say, forty of them.
You have at least two options:
- You can let all forty clients (with all of their myriad users,
sets of users, etc.) talk to a single MySQL daemon.
You have the ease of no clever engineering to get the to all use
this daemon, but you now have the task of accounting for their
usage, and constraining them individually.
- You can give each client their own separate MySQL daemon.
You have the overhead of each MySQL daemon process consuming some
OS resources, but now you have the freedom to almost completely
manage the resources of any one of these daemons.
Plus, you get to deal with the extra hassles of:
- Isolating which clients want binary replication: those logs each
eat up diskspace, and client's shouldn't unduly impair each other's
backups.
- What if one client make a request that makes MySQL spin? That'll
impair everyone else's ability to process queries.
- What if someone needs the ability to use DATAFILES under MySQL?
Now you get to juggle who gets read/write permission to the same
directories that the MySQL does...
If you generalize this work above to other services, such as mail
servers, web servers, etc., you'll see that you're re-solving the
same kind of problem, over and over again. And when you try to
worry about how much bandwidth each of these services is really
consuming, one tends to migrate to virtual machines as a more
complete, general solution.
No matter how you cut it, you'll still have forty clients (humans,
not mysql clients; each might be dozens of connections) wanting to
interact with your daemon(s). Either your machine has the gnads
to handle that, or it doesn't.
My desktop is a dual-CPU box, with 1.5G of memory. An idle instance
of MySQL looks like this:
natto% ps auxwwe -p 196
USERPID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
mysql 196 0.0 1.0 11896 10728 con- S29Oct02 5023:13.08
/usr/local/mysql/libexec/mysqld --basedir=/usr/local/mysql
--datadir=/usr/local/mysql/var --user=mysql
--pid-file=/usr/local/mysql/var/natto.numachi.com.pid
Having forty MySQL daemons, unto itself, doesn't cost the OS very
much at all.
But I _do_ think that for manageability, accounting, 'fairness' to
your other clients, that there's a lot to said for sandboxing them
as completely as possible. Using a jail gets you all they down to
network traffic.
If nothing else, you can learn who the 'piggy' clients are, and
decide to migrate them to another box, where they have more room...
Have fun. :)
Justin
--
Brian 'you Bastard' Reichert[EMAIL PROTECTED]
37 Crystal Ave. #303Daytime number: (603) 434-6842
Derry NH 03038-1713 USA Intel architecture: the left-hand path
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
