<p dir="ltr">My tuning time costs more than an extra pair of 16GB DIMMS.</p>
<p dir="ltr">It does sloppy but it's far easier to over deploy hardware and regain it later with tuning.</p>
<div class="gmail_quote">On Mar 28, 2016 9:50 AM, "Beddingfield, Allen" <<a href="mailto:allen@ua.edu">allen@ua.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It is not worth my time and effort to tune a VM to fit in a tiny amount of space. VMware does an excellent job of "thin provisioning" the memory in use. Ditto for our SAN with the storage. I know people who spend a lot of effort on "right sizing" virtual machines, but when the virtualization platform does a good enough job of it (as opposed to the old days where giving a VM was a hard allocation of 2G), it is not worth the effort. No matter how much you plan, at some point, you are going to have to take the VM down to add more.<br>
My approach to capacity planning is to always have enough capacity in reserve to not have to worry about it, and to have enough spare allocated to each VM that I don't have to worry about that. Yes, I know there is always the theoretical case where something goes awry across all the systems at once, and consumes resources that the VM would otherwise not have access to, but if that happens, you have bigger problems anyway.<br>
<br>
As for overhead with monitoring, etc.. our biggest resource eater is Tripwire Enterprise. That thing is a bloated Java-based monstrosity. I have to limit how much memory it can use, or it will consume everything available. In many cases, it is using more resources than the actual application on the server.<br>
<br>
Allen B.<br>
--<br>
Allen Beddingfield<br>
Systems Engineer<br>
Office of Information Technology<br>
The University of Alabama<br>
Office <a href="tel:205-348-2251" value="+12053482251">205-348-2251</a><br>
<a href="mailto:allen@ua.edu">allen@ua.edu</a><br>
<br>
________________________________________<br>
From: <a href="mailto:ale-bounces@ale.org">ale-bounces@ale.org</a> [<a href="mailto:ale-bounces@ale.org">ale-bounces@ale.org</a>] on behalf of DJ-Pfulio [<a href="mailto:DJPfulio@jdpfu.com">DJPfulio@jdpfu.com</a>]<br>
Sent: Monday, March 28, 2016 8:37 AM<br>
To: <a href="mailto:ale@ale.org">ale@ale.org</a><br>
Subject: Re: [ale] KDE, Gnome, XFCE OT?<br>
<br>
Supporting 200 email accounts on a 512MB box is possible.<br>
<br>
Certainly there are times when more CPU/RAM is needed, but most servers<br>
in most data centers run at 13% utilization. Why? "Bigger is better"<br>
syndrome. That includes 5% for systems monitoring. ;) I've heard of<br>
people using 2G of RAM as a minimal VM. Sounds like the team would<br>
rather blow more RAM than tune for actual needs. Sometimes that is<br>
needed as a rough starting point for green-field deployments ... but if<br>
that is true then why do Amazon and GoDaddy offer multiple, smaller,<br>
system sizes? Why?<br>
<br>
I would never try to put a geospatial DB on 2G of RAM. 32G of RAM is<br>
more like it for that need.<br>
<br>
There are methods to reduce CPU/RAM loading that aren't used enough.<br>
Micro-caching, for example. Caching results for 5 seconds at a time<br>
doesn't impact the end user much, if at all, but reduces the DB load<br>
hugely on primarily read-data. Transactional DB requirements are<br>
different. There are other times when more RAM is needed too. Impossible<br>
to say all the different times when more RAM is needed, but assuming<br>
more RAM is the solution is wasteful.<br>
<br>
There are 3 main things to watch when deploying a system:<br>
* RAM use (including VM)<br>
* CPU use<br>
* I/O (network, disk, etc)<br>
I've seen people assume that more RAM will solve a CPU issue. It won't,<br>
but it might solve an I/O issue (if swapping is the problem). This<br>
isn't rocket science.<br>
<br>
If the system is doing 10K TPS, a ballpark guess isn't sufficient. Real<br>
data and facts are necessary to properly architect the total solution -<br>
to include transactions, read-mainly requests, DR, and reporting.<br>
<br>
<br>
On 03/28/2016 08:28 AM, Lightner, Jeff wrote:<br>
> No server needs more than 2 GB unless running Java?!<br>
><br>
> That maybe true for small front end web servers but if you're doing<br>
> major DBs or APPs 2 GB is NOT plenty even if they're not Java based.<br>
> Even more active web servers use more than 2 GB.<br>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
<br>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</blockquote></div>