List:Falcon Storage Engine« Previous MessageNext Message »
From:Matt.Ingenthron Date:December 19 2008 6:42pm
Subject:resource controls in the DB (was Re: [Drizzle-discuss] dropping
databases)
View as plain text  
On 12/19/08 09:52, Tim Soderstrom wrote:
>
> On Dec 19, 2008, at 11:49 AM, Roy Lyseng wrote:
>
>>
>> For even better control, fire up a Solaris zone and a database 
>> instance inside it. Then you can control IP, disk quota, memory 
>> usage, CPU, etc, and probably simpler than partitioning the database 
>> server...
>
> Yeah, but that's basically virtualizing or user-mode segmentation type 
> stuff it sounds like. We can do that today but there's overhead in 
> managing all that. And MySQL starts competing with itself for 
> resources. What if you have, say, 200 customers on one box, for 
> instance. That's a ton of VMs or slices to mess around with. Granted, 
> the solution works today and it's less complicated than inventing a 
> new way of doing something like this, but you take a pretty big 
> penalty for doing that I'd say.

Since zones are really a userspace abstraction (think of it as an 
additional column in the process table, though it's a lot more complex 
than that), there really isn't much overhead.  It's been a while since 
I've measured it, but in the past if you were using native branded zones 
(so lots of things are shared), and ran a minimal set of services it was 
something like 14MByte of memory.

If you use other OS level resource controls which don't use something 
like zones (like the project/task abstraction in OpenSolaris), there is 
no significant memory penalty (other than that incurred for running 
multiple drizzled's) and the CPU penalty is pretty small.  In any event, 
it'd be equivalent CPU overhead if resource controls were implemented at 
the application layer.  There's no free lunch here.  :)

As I said earlier, it's pretty easy to think of use cases where it would 
be better to do that at the application level (for instance, there are 
plenty of buffers that could be shared more efficiently, if only you 
didn't have that query-from-hell problem), so your point still stands.  
The penalty just may not be as much as you thought it could be.

However, using VMWare or Xen or VirtualBox, you certainly have a lot of 
things to manage and a lot of overhead.  Heck, you're running a 
scheduler and memory manager on top of a scheduler and memory manager!

Do you have a need for 200 drizzled processes on one box for multiple 
customers?  It'd be good to understand what you'd like to be able to do.

- Matt

-- 
Matt Ingenthron 
http://blogs.sun.com/mingenthron/
email: matt.ingenthron@stripped

Thread
Re: [Drizzle-discuss] dropping databasesJim Starkey18 Dec
  • Re: [Drizzle-discuss] dropping databasesStewart Smith18 Dec
    • Re: [Drizzle-discuss] dropping databasesJim Starkey18 Dec
      • Re: [Drizzle-discuss] dropping databasesStewart Smith19 Dec
        • Re: [Drizzle-discuss] dropping databasesMonty Taylor19 Dec
          • Re: [Drizzle-discuss] dropping databasesStewart Smith19 Dec
Re: [Drizzle-discuss] dropping databasesJim Starkey19 Dec
  • Re: [Drizzle-discuss] dropping databasesStewart Smith19 Dec
    • Re: [Drizzle-discuss] dropping databasesTim Soderstrom19 Dec
Re: [Drizzle-discuss] dropping databasesTim Soderstrom19 Dec
Re: [Drizzle-discuss] dropping databasesRoy Lyseng19 Dec
Re: [Drizzle-discuss] dropping databasesTim Soderstrom19 Dec
  • Re: [Drizzle-discuss] dropping databasesRoy Lyseng19 Dec
    • Re: [Drizzle-discuss] dropping databasesTim Soderstrom19 Dec
      • resource controls in the DB (was Re: [Drizzle-discuss] droppingdatabases)Matt.Ingenthron19 Dec
    • Re: [Drizzle-discuss] dropping databasesMatt.Ingenthron19 Dec