地铁读书笔记-容量规划

容量规划

容量规划可以检查系统处理负载的情况，以及系统如何随着负载的增加而扩展。做容量规划有很多方法，包括研究资源极限和因素分析。本节还包括了扩展的解决方案，包括负载均衡器（load balancers）和分片（sharding）。关于这个专题的更多内容，参见The Art of Capacity Planning [Allspaw 08]。
针对某一应用程序做容量规划，这对制定其量化的性能目标是有帮助的。第5章的前半部分有关于这一内容的讨论。
2.7.1　资源极限
该方法是指研究在负载之下会成为系统瓶颈的资源，步骤如下：
1.测量服务器请求的频率，并监视请求频率随时间的变化。
2.测量硬件和软件的使用。监视使用率随时间的变化。
3.用资源的使用来表示服务器的请求情况。
4.根据每个资源来推断服务器请求的极限（或用实验确定）。
开始时要识别服务器种类，以及服务器所服务的请求种类。例如，Web 服务器服务HTTP请求、NFS 服务器服务NFS 协议请求（操作）、数据库服务器服务查询请求（或者是命令请求，把查询作为子集）。
下一个步骤是判断请求会消耗哪些系统资源。对于现有系统，与资源使用率相应的当前请求率是可以测量出来的。先推断出哪个资源先达到100%的使用率，然后看看那时候请求率会是怎样的。
对于未来的系统，可以用微基准测试或者负载生成工具在测试环境里仿真要施加的请求，同时测量资源的使用情况。给予充足的客户负载，你能够通过实验的方式找到极限。要监视的资源如下。
● 硬件：CPU 使用率、内存使用、磁盘IOPS、磁盘吞吐量、磁盘容量（使用率）、网络吞吐量。
● 软件：虚拟内存使用情况、进程/任务/线程、文件描述符。
比如，你现在正在看的系统当前每秒执行1000 个请求。最繁忙的资源是16 个CPU，平均使用率是40%，你预测当CPU 处于100%使用情况时会成为工作负载的瓶颈。问题就变成了：在那时每秒的请求率是多少？
每个请求的 CPU% = 总的 CPU% / 请求总数 = 16 x 40% / 1000 = 每个请求消耗 0.64% CPU
每秒请求最大值 = 100% x 16 CPU / 每个请求消耗的 CPU% = 1600 / 0.64 = 每秒 2500 个请求
在CPU 100%忙碌时，预测请求会达到每秒2500 个。这是一个粗略的最好估计，在达到该速率之前可能会先碰到其他的限制因素。
上述做法只用了一个数据点：应用程序1000 的吞吐量（每秒的请求数）和设备40%的使用率。如果监视过一段时间，可以收集到多个不同的吞吐量和使用率的数据值，这样就可以提高估计的精确性。图2.20 所示的是处理数据并推断应用程序吞吐量最大值的一个可视化方法。

图2.20　资源极限分析
每秒2500 个请求的性能足够吗？回答这个问题需要理解什么是工作负载的峰值，通常按每日的访问来显示。对于既有系统而言，只要你监视过一段时间，就应该会有峰值是什么样的概念。
想象一下一台Web 服务器每天处理100 000 次网站点击。这看起来可能挺多的，但平均下来，差不多每秒只有一次请求——并不多。然而，可能100 000 次网站点击的大多数都发生在新内容更新后的一秒，那样的话峰值就很高了。
2.7.2　因素分析
在购买和部署新系统时，通常有很多因素需要调整以达到理想的性能。这些调整包括磁盘和CPU 的数目、RAM 的大小、是否采用闪存设备、RAID 的配置、文件系统设置，以及诸如此类的事情。一般是用最小的成本来实现需要的性能。
对所有可能的组合做测试，可以决定哪个组合具有最佳的性价比。但是，真这样做的话很快就会失控：八种两个可能的因素就需要256 次测试。
解决方法是测试一个组合的有限集合。基于对系统最大配置的了解有下面这么一个方法：
1.测试所有因素都设置为最大时的性能。
2.逐一改变因素，测试性能（应该是对每一个因素的改动都会引起性能下降）。
3.基于测量的结果，对每个因素的变化引起性能下降的百分比以及所节省的成本做统计。
4.将最高的性能（和成本）作为起始点，选择能节省成本的因素，同时确保组合后的性能下降仍满足所需的每秒请求数量。
5.重新测试改变过的配置，确认所交付的性能。

文章来源: blog.csdn.net，作者：隔壁老瓦，版权归原作者所有，如需转载，请联系作者。

原文链接：blog.csdn.net/wxb880114/article/details/114041028