(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 USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND mysql 196 0.0 1.0 11896 10728 con- S 29Oct02 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. #303 Daytime 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
