DBA的一块主要的工作是后台系统维护, 当你在一家高速增长的网络公司做这个职位时, 已经不能光做些事后故障处理的事了, 需要对数来1源gaodai#ma#com搞*代#码1网据容容量(Capacity)作了一些有效的预测, 否则当业务高峰来临时, 就会手忙脚乱. 要将高可用性当成第一目标, 也不能光看目前的系统
DBA的一块主要的工作是后台系统维护, 当你在一家高速增长的网络公司做这个职位时, 已经不能光做些事后故障处理的事了, 需要对数据容容量(Capacity)作了一些有效的预测, 否则当业务高峰来临时, 就会手忙脚乱. 要将高可用性当成第一目标, 也不能光看目前的系统可用性, 要结合业务增长速度来看系统可用性, 这样容量预测的工作就势在必行.
从数据库的角度来的看, 可以先去分析下面几个因素和系统负荷的关系.
1, Execute Count
2, Logical Read
3, Physical Read
4, Physical Write
5, Transactions
当了解了上面的因素和系统负荷之间的变化关系后, 需要再分析资源和上面这些因素的关系, 以及资源的限制. 有那些方面资源呢?
1, CPU
2, IOPS & IO Time & Storage Space
3, Transaction Process
再从业务上来分析, 分析一下完成你的一笔交易需要产生多少次数据库的活动, 再根据业务发展的速度就可以初步评价出, 目前的系统可以支持多少的事务量了, 从而知道现有的系统可以再支持多少时间, 有了这些预测, 就可以提前作出一些行动, 进行相关的升级或改造了.
很想做一个比较好的预测模型, 由于不能用真实的数据去检验一下模型的有效性, 因此永远局限于理论模型, 目前还没有很好的很准的模型, 正在思考中……
转载请注明原文链接：数据库容量(Capacity)预测?
