我的计划是只启动100个模拟器,测量内存使用量,然后再次启动100个测量内存并重复直到分页开始上升(实际上我将获取三个以上的数据点.)这应该给我一个数字100个模拟器所需的额外内存量,使我能够预测需要多少内存.我只需要一个粗略的想法/ -30Gb,以避免购买服务器将采取的完整2Tb(价值150,000美元).我的问题是这是否是一种合理的使用方法,如果是这样,你会监控哪些性能计数器给出实际使用的内存量？
我在这里专门谈论内存,因为工作集,私有字节,提交,共享,虚拟和所有其他内存术语之间的区别让我感到困惑.我想我可以自己监控cpu,IO和网络.我注意到的另一件事是.Net Cache调整其内存使用量取决于可用的内容,这使得发现趋势很难看到.
在规划可以看到任何类型的实际工作负载的服务器时,我尽可能多地占用RAM(系统更有可能限制RAM受限制而不是cpu或磁盘受限 – 唯一的其他保证瓶颈是前端总线).
如果你想弄清楚你的应用程序可以使用多少RAM,你提出的基本负载测试是一个好的开始,但如果你已经在生产中使用这个系统(听起来像你这样做)并且你的生产系统正在交换你的任务更容易：计算出你使用了多少交换空间 – >添加至少2倍的RAM(向上舍入以适应系统的DIMM大小限制).
如果您执行负载测试以获取粗略数字并从那里推断,请记住要考虑以下几点：
>记忆曲线可能是两个不同的部分
(当缓存框架/共享库时,初始急剧上升,然后当每个新应用程序的不可共享代码放入内存时,曲线稍微不那么陡峭)
>您仍然需要用于磁盘和共享库缓存的免费RAM以及操作系统.
(这应该至少比您的应用程序需要的几个演出)
>所有软件泄漏内存(至少所有实用软件都有),因此请在测试中注意并确保您有足够的空间来处理泄漏.
>您的负载可能会在服务器的整个生命周期内增加.相应地计划.
(如果您没有良好的容量规划编号,请将今天的工作量加倍并计划处理该问题).
>今天购买太多内存比明天环境下降要便宜.
>第一个推论：如果你购买的服务器比你需要的要大一些,那么你就是那个让公司保持运转的有先见之明的管理员.你将在很大程度上被忽视和不受重视.>第二个推论：如果你的机器尺寸不足并且有问题,你就是无能的小丑,他们无法预料到500％的增长,而且每个人都讨厌你.
