[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] Re: Problem with automatic VM (domU) creation
On Thu, 2007-02-22 at 22:18 +0530, Ligesh wrote: > On Fri, Feb 23, 2007 at 12:25:55AM +0800, Tim Post wrote: > > In fact, I helped write grawk, our utility that combines some of the > > most frequently grep + awk pipes together into something quite a bit > > smaller : http://dev1.netkinetics.net/grawk/ for log sawing and easy > > string extraction from delimited files / output scraping. Feel free to > > use it instead of sed for such a simple task. Patches for additional > > regex are of course welcome, provided they do not significantly increase > > the size of the executable and malloc() wisely. > > > > That being said, I do in fact realize that I am *over paranoid* about > > it :) I freely admit that I suffer from many odd 'ticks' that cause me > > to obsess about every single byte of RAM in every single system I > > maintain. Its a wonder I get anything done. > > > After becoming almost irrelevant, RAM is again becoming a very critical > commodity. > In the case of single machines, saving a couple of bytes ram was pretty much > absurd, > especially with enough swap, the affect would only be temporary, and there > wasn't any > real price difference between a 52MB system and a 512MB system. I think its very much like SUVs (which I call stupid useless vehicles). They don't seem so attractive anymore when the price of fueling them continues to climb. Some applications and services are SUVs. My first 'real' machines were 286's with 2 MB ( 2 x 1MB SIPPs), so I really do see your point. Those machines housed my dial up BBS really well. When I saw a 64 MB chip, I barked "Who the heck could even take advantage of that for home use?", like many other people did. > But with virtualization, 32MB means you can have 10 times the number of > virtual machines, > and the price actually goes down 1/10th. And to achieve true virtualization, you want isolated ram. You hit it right on the head. > ONce virtualization picks up, memory optimized systems are going to make a > come back. > And it seems to be an entirely new market, since all mainstream applications > seems to have > given up on memory optimization. For instance, the three of the most popular > applicatins: > bind, spamassassin, apache are all memory hogs, using memory unncessarily. I > mean, why > the heck do you need 200MB for running a web server? That's quite insane. Thank PHP, Perl, Java, mod_sec, mod_rewrite, etc. All very useful and needed things that add up. One of the reasons I love lighttpd so much :) You shouldn't *need* more than 64MB for a web server, but you do. The fact remains that predicting normal usage and application deployment is increasingly difficult. All it takes is one good 'digg' to make you re-evaluate how much you need. You never know what one of your users is going to decide to upload. So I just try to be paranoid where I can, where things *can* be predicted such as dom-0. The smaller I can make dom-0, the more ram I can give to the guests. So I force myself to constantly ask "Could this be done with fewer forks? Why are we grabbing this much ram?" The less we take up on the back end, the more public 'business' can get done. The other problem is web based control panels which everyone loves, like C-Panel. Its one of the most inefficient piece of junk I've ever laid eyes on, but my users demand it. Many people who simply just do not know any better insist on running all services on one machine, not realizing the cut throat competition that goes on within the process tree to grab contiguous memory blocks. All I can do is be sure they have ample, plus a little more. <shrug>. Anyway, we better shut up before we're flogged tarred and feathered for going horribly off topic :) Hey, I got dom-0 in there twice! Put down that carton of eggs! Best, --Tim _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |