计算机系统性能容量规划-实施办法-原创PPT.ppt

,单击此处编辑母版标题样式,#,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,主机性能容量规划实施办法,作者：,Tony Shi,Email,：,tony26600882,欢迎通过邮件交流,2,容量规划能够解决的问题,IT,资源配置是否满足目前的业务需求？,是否存在未充分利用的,IT,资源和容量？,未来,6,个月,IT,资源是否能够满足业务增长需要？,增加多少,IT,硬件资源，才能满足,2,年内的业务处理？,业务系统合并和拆分，如何配置硬件资源？,业务以每月,5,增长时，什么时候需要,IT,扩容？,IT,基础设施,监控体系,为了能准确反映业务量和性能之间的函数关系，应为不同类型的业务系统规划相应的监控指标，这是生成容量基准模型的必要条件。,通过有效监控可以提供准确的性能数据。,业务量估算,模型分析,IT,系统主要的资源包括,CPU,、内存、磁盘,/,磁盘控制器三大类。因此，由于资源数量、单个资源不同体系架构的影响，需要将影响性能的资源的数学关系公式和经验值有效结合在模型中，才能进行,有效的性能趋势和假设性分析,。,不同的,应用系统的业务量估算有不同方法和流程,。,容量规划的主要工作,3,克服,TPC-C,、,SPEC,等国际标准主要体现主机,/,存储、系统平台性能的局限性，将业务量、服务等级、,IT,系统性能统一规划和管理，建立三者之间的关系模型。容量规划有助于企业有效控制,IT,基础设施的投入成本；并帮助企业,(,特别是电信运营商、银联系统,),的,IT,系统的服务输出能力。,增强对短、中期投资的可预见性。,IT,投资成本,IT,服务,提高投资回报率,实施容量规划意义何在？,4,5,容量规划的价值体现,隐式价值,显式价值,Capacity Planning,降低采购成本：,对在建项目预先进行容量规划，确定最优化的硬件资源配置并指导投资预算；,找出未充分利用的资源和容量，以便指导业务系统合并或者将其它业务系统加入进来。,节约维护成本：,在约,5,年的硬件资源有效期内，系统维护、配置、升级等方面的费用要高于硬件的购买投资，容量规划帮助成比例的降低了这些附加成本。,减少人力资源成本：,容量规划帮助合理分配,IT,硬件资源，从而也会帮助组建合理的,IT,团队，以降低人力成本。,增强,IT,系统可靠性：,减少资源或容量的过度冗余，会减少风险节点，从而降低风险转变成灾难的概率；,准确预测资源或容量的过度负载时间点，降低宕机概率。,提高,IT,系统可用性：,通过短期、不间断的容量规划，及时监控服务质量要求和响应时间的差距，提前采取措施，避免因服务质量降低导致的客户不满。,降低,IT,投资成本,&,提高,IT,的,QoS,系统迁移,。通过在测试环境下的有效性能监控，建立业务量、服务等级、,IT,硬件资源三者之间的容量基准模型，通过,what-if,分析业务量变化时的资源需求和性能表现，有效控制,IT,系统运营环境下的软硬件资源成本。,系统的扩容改造,。通过在运维期内的有效性能监控，收集系统在运营期的性能数据，建立业务量、服务等级、,IT,资源三者之间的容量模型，分析未来不同时间（例如,6,个月内、,1,年内等）的资源需求和性能表现，为,IT,系统的扩容提供依据，并对,IT,系统的性能进行有效的监控和预警。,系统迁移,系统扩容改造,何时？何处？实施容量规划,6,7,容量规划时机,需求,开发,上线,运维,系统架构,确定开发环境,代码测试,功能测试,性能测试,系统测试,系统调优,系统监控,需求,(,扩容,),容量规划,容量规划,上线容量规划 扩容容量规划,8,容量规划的前提条件,上线容量规划,扩容容量规划,对测试环境的要求,性能调优后收集容量规划的基础数据：即确保应用每个组件（,Web,、,DB,等）的瓶颈都在于硬件平台，即每个组件都可能因为压力的增加而使,CPU,或内存的利用率接近,100,；,测试环境中,DB,的数据量要基本和现网一致，否则结果会有偏差；,在测试中如果发现各组件间系统资源占用情况差别过大（如,DB CPU100,时,Web CPU 10,），应调整测试环境；,尽量保证测试环境和上线环境的硬件平台有相同的技术架构。,对应用系统运行环境的要求,确认网络不是造成响应时间过长的原因,假设应用系统处在最优状态（如果瓶颈在应用系统，容量规划的结果会有较大的误差）；,准确统计目前的业务量，作为容量规划建模的输入数据，业务量偏差大会导致不能和实际的性能表现相匹配；,性能监控代理,。客户端软件，安装在每台主机上，收集并存储主机的性能数据；根据容量规划的要求，对性能数据进行统计分析。提供性能数据导出工具；用户可以通过,web,页面展现系统的性能变化曲线。,容量监控,/,管理工具,。服务器端软件，汇总各代理收集的性能数据，建立业务系统的动态性能模型，对主机的性能、硬件资源进行动态的监控和管理，可以设置阈值在设定的条件下实现预警。,容量建模工具,。根据采集的性能数据建立系统性能容量模型，使用系统容量模型进行假设性问题试验,事先了解应用系统环境的变化对应用系统部署、服务器的整合、业务扩展或增加工作负荷所产生的影响，从而对系统容量规划作出正确的决策。,容量建模工具,容量监控,/,管理工具,IBM Host,性能监控代理,Sun Host,性能监控代理,HP Host,性能监控代理,windows,性能监控代理,容量规划架构,9,10,容量规划的基本过程,理解业务,最大的应用,/,负载,业务量的增长幅度,2.,划分主机负载,a.,定义,workload,b.workload,的服务方式,3.,分析当前系统容量,a.,测量所有的应用资源,b.,使用,workload,测量应用资源,c.,确定硬件系统各部分的反应时间,4.,系统中,/,远期预测,a.,确定未来系统的资源配置需求,b.,结合业务发展，规划远期系统配置,5,编制详细性能报告,11,Step1,：理解业务,第一步 工作负载,workload,是计算机系统上所有工作的逻辑分类，如果将计算机的工作想象成一块大饼，那么每一个,workload,就是大饼的一块扇区。,可以按照以下逻辑对,workload,进行分类：,who,：谁在工作？例如特定的用户或组织,what,：什么类型的工作？例如订单处理，财务报表,how,：如何做这些工作？在线查询，批量数据备份,每个,workload,应具备业务敏感度，也就是说业务量的增加或减少和,workload,的性能表现有较明显的相关性；,不管以何种逻辑划分,workload,，都应找出每个,workload,的相关业务指标，并用业务语言描述和定义该指标。,第二步 工作单元,第三步 服务等级,将工作单元和,workload,联系起来，与完成某项工作而消耗的系统资源的数量类似，工作单元是一类可量化的变量，只不过需要用业务语言来描述。,工作单元可以看成为,workload,而设定的几个可量化的参数，其数值的变化代表了,workload,对资源消耗的变化。,例如：,1,、应用的交易事务数量,2,、连接数据库的用户数,3,、呼叫中心处理的呼叫次数,4,、帐务中心的订单处理数量,都可以作为工作单元。,服务等级协议由服务提供者和服务消费者双方制定，定义一个在服务消费者接受范围内的服务，一般通过,响应时间,和,吞吐量,来描述服务等级。签订服务等级协议时最好按照,workload,，理由是,workload,类似与性能和业务量之间的纽带，有很大的相关性；而且,workload,中工作单元的数值大小对业务量变化具备相当的敏感度。,比如对一个预约应用系统，我们可以这样定义其服务等级：,1,、一小时内能够处理的电话预约数量不少于,200,个；,2,、每一个预约需在,30,秒内完成；,3,、每一个预约请求在队列中的等待时间不能超过,60,秒。,12,Step1,：理解业务,系统,(System),工作负载,(Workload),工作单元,(Unit of work),资源,(Resource),SAP,主机,财务模块,活动用户数,每个工作单元对多个资源都有消耗,CPU,业务处理数,I/O,Tuxedo,服务器,查询模块,事务数,Memory,取款模块,事务数,Network connection,店面,(System),部门,(Workload),业务指标,(Unit of work),资源,(Resource),快餐店,厨房,食物重量,每个业务指标对多个资源都有消耗,鸡蛋,每天生产三明治数量,生肉,大厅,就餐的顾客数量,泡菜切片,面粉,as opposed to,对比,13,Step2,：划分,workload,类型,解释,Batch,用于,mainframe,结构的主机容量规划，该环境下没有用户，,workload,根据预先定义的,schedule,启动,/,停止,/,休眠，即有处理任务就启动，没有就休眠直到有新的处理任务。,Process,用于,open system,结构的主机，即适用于小型机和,pc,机。,Interactive,有用户参与，并且一般用户通过终端连接，执行一些交互性的工作。例如用户对,oracle,数据库发出请求。,Transaction,多个进程一起执行事务，,transaction,不是由某一个用户发起或者执行，这是和,interactive,差异的地方。,14,Step3,：收集数据,上线容量规划,扩容容量规划,通过性能测试收集业务数据和性能数据,业务数据：,通过性能测试阶段指定的加压方式和测试策略，收集业务数据,性能数据：,收集不同负载测试时的性能数据，作为容量规划的原始数据。,通过业务统计和系统监控收集数据,业务数据,:,通过业务量统计或其它监控方法，收集业务数据。,性能数据：,通过实时监控收集性能数据,15,Step4,：模型分析,模型基础数据：根据当前的性能数据，建立性能,benchmark,，作为模型分析的基础。,趋势分析,不同的业务增长量,What-if,分析,MVAP,模型,Simulation,模型,按照计算模型的差异，可以建立的模型包括：,单机模型,改变硬件配置,Multi-tier,模型,改变各层的硬件配置；,改变各层的主机数量,按照应用系统的类型，可以建立的模型包括：,模型分析时能够定义的资源：,CPU,Disk,Disk controller,模型分析时可以改变的参数：,业务增长量,Workload,类型,Disk,间的,I/O,平衡,16,Step5,：结果报告,结果报告：,容量规划最终将为硬件采购提供必要的依据，在预先制定的业务目标前提下，给出最佳的硬件配置方案。,一般情况下，对平均负载的模型分析以及对峰值负载的模型分析，都需要实施。,17,谢谢！,(,后附容量规划案例,),结 束,18,案例,SAP,系统容量规划,通过容量规划预测两年内的性能表现，回答以下几个问题：,为了满足平均负载，系统需要在什么时候扩容？,扩多少资源？,为了满足峰值负载，系统需要在什么时候扩容？,扩多少资源？,过程：,理解业务：,估算业务量,划分负载,(workload),：,从业务上对引起应用,/,负载的活动进行分类,采集数据：,平均负载下的性能数据；峰值负载下的性能数据,建模分析,:,趋势分析,What-if,分析,建议,:,回答假设性问题,19,5,结果,4,模型分析,3,采集数据,2,划分负载,1,估算业务量,应用,/,负载代表了,sap,系统的业务量，根据和,sap,系统和业务人员的讨论，并从业务角度来描述，业务量受到两个主要因素的影响：活动用户数；用户的平均业务处理量,用户数和业务处理量的增加，必然带动业务量的增长。反映到,SAP,应用系统，必然需要更多的硬件资源用于业务处理，通过对两个自变量在,IT,系统的功能映射分析，我们可以确定：,用户数增加需要,SAP,应用系统和,Oracle,数据库相应启动更多的进程，以增加业务处理能力，,TeamQuest,容量规划中的,Population,就代表了某一时刻,SAP,用户和,oracle,用户启动的进程数量，因此进程数的增长趋势可以较好的模拟用户数引起业务量增长的趋势。,用户操作数的增加需要计算机处理更多的用户请求，表现在硬件层面上即计算机的,CPU,、,Memory,、,DISK,需要处理更多的机器指令，,TeamQuest,容量规划中的,visits at active resource,的值就代表了一个用户的业务操作数，因此,visits,值的增长趋势可以较好的模拟用户操作数引起的业务量增长趋势。,ID,业务量因子,(,工作单元,),模型中对应的变量,1,活动用户数,Population,2,平均业务处理量,Visits at active resource,案例,SAP,系统容量规划,20,5,结果,4,模型分析,3,采集数据,2,划分负载,1,估算业务量,由于业务每月增长量暂时缺乏精确的统计数据，本次案例暂时通过假设设定一个增长比例：,负载类型,Population,(,活动用户数,),Visits at active resource,(,处理请求数,),平均负载,SAP,系统,10%,10%,Oracle,数据库,10%,10%,峰值负载,SAP,系统,5%,5%,Oracle,数据库,5%,5%,本次预测“,2,年”内的业务满足程度，设计,24,步（,step,），每,step,代表一个月，上表为假设的业务量每月的变化。,案例,SAP,系统容量规划,21,机器,Workloads,备注,Sapapp1,r3padm user,hp OpenView,root except OpenView,used by r3padm,used by OpenView agent,used by root except OpenView,Sapapp2,r3padm user,hp OpenView,root except OpenView,used by r3padm,used by OpenView agent,used by root except OpenView,SapDB,SapDB orar3p,r3padm user,hp OpenView,root except OpenView,used by orar3p,used by r3padm,used by OpenView agent,used by root except OpenView,5,结果,4,模型分析,3,采集数据,2,划分负载,1,估算业务量,根据业务类型划分工作负载,案例,SAP,系统容量规划,22,5,结果,4,模型分析,3,采集数据,2,划分负载,1,估算业务量,Sap,系统在每月,25,下月,5,日业务比较繁忙，本次建模就在该时间段内收集数据，由于该时间段的性能表现有一定的代表性，所以对系统扩容有一定的参考意义。,经过筛选，确定选取,2006-5-26 8:2017:20,之间共,9,个小时的数据段：,对平均负载性能数据，以,10,分钟作为数据聚合尺度；,(,保证计算出精确的平均值,),；,对峰值负载性能数据，以,1,小时作为数据聚合尺度。（真正反映业务峰值，而不是瞬时性能峰值）。,确定采集段,数据聚合尺度,生成,abr,文件,案例,SAP,系统容量规划,23,5,结果,4,模型分析,3,采集数据,2,划分负载,1,估算业务量,Workload Name,CPU Utilization,I/Os per second,Population,Throughput,OTHER,0.29%,less than.01,1.01,less than.01,hp OpenView,less than.01%,less than.01,2.00,less than.01,r3padm user,32.55%,4.79,45.24,less than.01,root except OpenView,0.31%,5.13,134.08,less than.01,Workload Name,CPU Utilization,I/Os per second,Population,Throughput,OTHER,0.42%,0.00,1.02,less than.01,hp OpenView,less than.01%,less than.01,2.00,less than.01,r3padm user,81.44%,4.76,45.01,0.08,root except OpenView,0.27%,5.45,135.03,0.22,SapApp1,峰值负载,平均负载,案例,SAP,系统容量规划,24,5,结果,4,模型分析,3,采集数据,2,划分负载,1,估算业务量,Workload Name,CPU Utilization,I/Os per second,Population,Throughput,OTHER,0.38%,less than.01,1.02,less than.01,hp OpenView,24.97%,less than.01,2.00,less than.01,r3padm user,15.41%,2.82,40.00,less than.01,root except OpenView,0.13%,4.99,132.08,less than.01,Workload Name,CPU Utilization,I/Os per second,Population,Throughput,OTHER,0.36%,0.00,1.01,less than.01,hp OpenView,24.98%,less than.01,2.00,less than.01,r3padm user,25.49%,2.43,40.00,0.01,root except OpenView,0.14%,6.00,133.01,0.04,SapApp2,峰值负载,平均负载,案例,SAP,系统容量规划,25,5,结果,4,模型分析,3,采集数据,2,划分负载,1,估算业务量,Workload Name,CPU Utilization,I/Os per second,Population,Throughput,OTHER,0.18%,0.00,1.01,less than.01,hp OpenView,less than.01%,less than.01,2.00,less than.01,r3padm user,0.02%,0.01,3.00,less than.01,root except OpenView,0.34%,5.07,134.10,less than.01,sapdb orar3p,45.39%,610.49,78.99,less than.01,Workload Name,CPU Utilization,I/Os per second,Population,Throughput,OTHER,0.40%,0.00,1.02,less than.01,hp OpenView,less than.01%,0.01,2.00,less than.01,r3padm user,0.02%,0.02,3.00,less than.01,root except OpenView,0.37%,6.33,134.97,0.04,sapdb orar3p,82.31%,938.16,78.98,0.02,SapDB,峰值负载,平均负载,案例,SAP,系统容量规划,26,5,结果,4,模型分析,3,采集数据,2,划分负载,1,估算业务量,在建模阶段，需要,IT,人员提供的数据包括：,主机,/,存储的,CPU,、,disk controller,、,disk,的类型或者性能参数；,对每台主机平均负载、峰值负载单独建立并校验,model,，模型分析的思路：,首先正确匹配硬件资源类型，保存为,baseline,模型；,平均负载按照每月,10,业务量增长，峰值负载按照每月,5,业务量增长，分别进行趋势分析；,如果在某些硬件资源处形成瓶颈，增加该资源，进行,what-if,分析。,案例,SAP,系统容量规划,27,5,结果,4,模型分析,3,采集数据,2,划分负载,1,估算业务量,SapDB,SapApp2,SapApp1,平均负载,_,趋势分析,AVG(,4CPU),Step:16,Step:17,Step:18,Step:19,Step:20,Stretch Factors,1.50,1.64,1.84,2.14,2.55,CPU Utilization,80.26,83.13,85.82,88.25,90.34,分析结果：,在,step16,step18,之间，即平均,CPU,利用率在,80.3%85.8%,之间时，为了满足平均业务量需求，,应考虑,对系统进行扩容。,案例,SAP,系统容量规划,28,5,结果,4,模型分析,3,采集数据,2,划分负载,1,估算业务量,SapDB,SapApp2,SapApp1,峰值负载,_,趋势分析,分析结果：,PEAK,（,4CPU,）,Step1,Step2,Step3,Step4,Step5,Stretch Factors,1.51,1.67,1.89,2.17,2.51,CPU Utilization,81.44,84.52,87.18,89.34,91.05,在,step1,step3,之间，为了满足峰值业务处理，,应考虑,对系统进行扩容；,在第,24 step,之前，,必须考虑,对,CPU,进行扩容，以防系统崩溃不再提供服务，或者,CPU,过于繁忙导致不能正常返回响应。,案例,SAP,系统容量规划,29,5,结果,4,模型分析,3,采集数据,2,划分负载,1,估算业务量,SapDB,SapApp2,SapApp1,峰值负载,_,what-if,分析,分析结果：,PEAK,（,8CPU,）,Step20,Step21,Step22,Step23,Step24,Stretch Factors,1.27,1.33,1.41,1.51,1.64,CPU Utilization,86.33,88.13,89.78,91.25,92.49,增加,4,个,CPU,后，在未来,24,个月内，硬件资源可以较好的满足业务需要。,案例,SAP,系统容量规划,30,5,结果,4,模型分析,3,采集数据,2,划分负载,1,估算业务量,SapDB,SapApp2,SapApp1,平均负载,_,趋势分析,分析结果：,AVG,（,4CPU,）,Step19,Step20,Step21,Step22,Step23,Step24,Stretch Factors,1.17,1.19,1.20,1.22,1.24,1.27,CPU Utilization,43.08,44.61,46.13,47.66,49.18,50.70,未来,24,个月内，硬件资源可以较好的满足均值业务需要。,案例,SAP,系统容量规划,31,5,结果,4,模型分析,3,采集数据,2,划分负载,1,估算业务量,SapDB,SapApp2,SapApp1,峰值负载,_,趋势分析,分析结果：,PEAK,（,4CPU,）,Step19,Step20,Step21,Step22,Step23,Step24,Stretch Factors,1.23,1.25,1.27,1.29,1.31,1.33,CPU Utilization,48.14,49.39,50.63,51.87,53.11,54.34,未来,24,个月内，硬件资源可以较好的满足峰值业务需要。,案例,SAP,系统容量规划,32,5,结果,4,模型分析,3,采集数据,2,划分负载,1,估算业务量,SapDB,SapApp2,SapApp1,平均负载,_,趋势分析,分析结果：,AVG,（,4CPU,）,Step8,Step9,Step10,Step11,Step12,Stretch Factors,1.35,1.47,1.66,2.00,2.55,CPU Utilization,76.58,80.79,84.80,88.40,91.37,在,step10,step11,之间，即平均,CPU,利用率在,84%88%,之间时，为了满足,Oracle,用户的业务处理需求，,应考虑,对系统进行扩容。,在,step20,时，数据库对用户的请求将不能正常返回响应，即在第,step20,之前，,必须考虑,对系统进行升级。,案例,SAP,系统容量规划,33,5,结果,4,模型分析,3,采集数据,2,划分负载,1,估算业务量,SapDB,SapApp2,SapApp1,平均负载,_what-if,分析,分析结果：,Avg,（,8CPU,）,Step19,Step20,Step21,Step22,Step23,Step24,Stretch Factors,1.16,1.18,1.21,1.24,1.27,1.32,CPU Utilization,70.24,72.70,75.14,77.58,79.99,82.38,CPU,不再是性能瓶颈，在,24,个月内，硬件资源基本上可以较好的满足业务需求；,磁盘,I/O,在后期会越来越繁忙，指令在磁盘处的排队有逐渐增多的趋势，在,24,个月后,应考虑,优化磁盘结构 或者 更换更快的磁盘。,案例,SAP,系统容量规划,34,5,结果,4,模型分析,3,采集数据,2,划分负载,1,估算业务量,SapDB,SapApp2,SapApp1,峰值负载,_,趋势分析,分析结果：,PEAK,（,4CPU,）,Step1,Step2,Step3,Step4,Step17,Stretch Factors,1.54,1.74,2.04,2.45,12.02,CPU Utilization,82.32,85.60,88.42,90.68,98.15,在,step1,step2,之间，即平均,CPU,利用率在,82%86%,之间时，为满足峰值业务处理需求，,应考虑,对系统进行扩容。,在,step17,时,(Stretch Factor,值超过,12),，数据库对用户的请求将不能正常返回响应，即在第,step17,之前，,必须考虑,对系统进行升级。,案例,SAP,系统容量规划,35,5,结果,4,模型分析,3,采集数据,2,划分负载,1,估算业务量,SapDB,SapApp2,SapApp1,峰值负载,_what-if,分析,分析结果：,PEAK,（,8CPU,）,Step19,Step20,Step21,Step22,Step23,Step24,Stretch Factors,1.37,1.45,1.56,1.71,1.92,2.18,CPU Utilization,87.07,88.99,90.75,92.27,93.49,94.44,在,step21,step23,之间，即平均,CPU,利用率在,90%93%,之间时，为了满足,Oracle,用户的业务处理需求，,应考虑,对系统进行扩容。,未来,24,个月内，硬件资源基本上可以满足峰值业务需求。,案例,SAP,系统容量规划,36,5,结果,4,模型分析,3,采集数据,2,划分负载,1,估算业务量,SapDB,SapApp2,SapApp1,峰值负载,_what-if,分析,分析结果：,PEAK,（,10CPU,）,Step19,Step20,Step21,Step22,Step23,Step24,Stretch Factors,1.16,1.18,1.20,1.23,1.26,1.29,CPU Utilization,76.21,78.13,80.03,81.92,83.77,85.59,CPU,不再是性能瓶颈，在,24,个月内，硬件资源基本上可以较好的满足业务需求；,磁盘,I/O,在后期会越来越繁忙，指令在磁盘处的排队有逐渐增多的趋势，在,24,个月后,应考虑,平衡磁盘的,I/O,或者 优化磁盘结构。,案例,SAP,系统容量规划,37,5,结果,4,模型分析,3,采集数据,2,划分负载,1,估算业务量,容量分析,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,SAPAPP1,平均负载,SAPAPP1,峰值负载,SAPAPP1,+4CPU,峰值负载,SAPAPP2,平均负载,SAPAPP2,峰值负载,SAPDB,平均负载,SAPDB,+4CPU,平均负载,SAPDB,峰值负载,SAPDB,+4CPU,峰值负载,SAPDB,+6CPU,峰值负载,结果的判断依据：,Stretch Factor,period,正常期,考虑扩容期,响应很慢期,服务崩溃期,Stretch Factor,12,案例,SAP,系统容量规划,38,5,结果,4,模型分析,3,采集数据,2,划分负载,1,估算业务量,三条建议：,在未来,2,年内，为保证,SapApp1,、,SapApp2,、,SapDB,三台主机的硬件资源不会形成性能瓶颈，建议为三台主机分别增加,4,个、,0,个、,6,个同类型,CPU,；,相应增加各主机的内存数量。,SapDB,在,2,年内磁盘的,I/O,不会形成瓶颈，但在后期,disk,的,queue,越来越长，预计,2,年后,I/O,会成为瓶颈，建议提前对,I/O,进行优化，例如在,busy disk,和,idle disk,之间进行,I/O,平衡，优化磁盘阵列的卷组管理等。,容量规划能够回答的问题,(,回顾,),：,公司需要,多少资源,才能满足对客户的,服务承诺,？,按照目前业务的,增长速度,，,什么时候,系统容量会超负荷？,什么时候,需要增加,多少资源,？,案例,SAP,系统容量规划,