《绝地求生》服务器再瘫痪 你再不搞定服务器叫人怎么玩
《绝地求生》服务器再瘫痪 你再不搞定服务器叫人怎么玩
橙善娱乐爱八卦
今天晚上《绝地求生》再次出现了服务器问题，《绝地求生》同时在线玩家已经超过150万人，超过总和，所以服务器炸服可以理解，但是你再不搞定的话叫大家还怎么愉快的吃鸡？《绝地求生》服务器压力日渐增大。不过蓝洞公司很多精力还是放在新地图，新车型以及封号上，虽然这些也是玩家需求，不过扩张服务器的问题不优先解决，玩家们还是不买账的，评论区就有玩家已经开始吐槽了。就在官方再次公布最新的封禁外挂的进展，官方自豪的表示自己一个星期封号了两万五千个，以为玩家们会表扬表扬，结果网友们直接一句呛了回去：能先搞好服务器？反正不管如何，还是希望服务器爆炸的日子可以早点结束，现在《绝地求生大逃杀》官方微博的“日常道歉”都已经快成为真正的日常了，哎。■
本文仅代表作者观点，不代表百度立场。系作者授权百家号发表，未经许可不得转载。
橙善娱乐爱八卦
百家号 最近更新：
简介: 没有最八卦，只有更八卦
作者最新文章参考网站：
http://www.spec.org/jbb2005/results/jbb2005.html
1 术语和定义
1.1 信息系统
由计算机、通信设备、处理设备、控制设备及其相关的配套设施构成，按照一定的应用目的和规则，对信息进行采集、加工、存储、传输、检索等处理的人机系统。
1.2 软硬件平台
指信息系统运行的环境，主要包括硬件（服务器、存储）和软件（操作系统、数据库和中间件）部分。
1.3 非安全区
即Internet，此区域允许外网用户随意访问。
1.4 安全区
内网，此区域通常不对外提供服务。
1.5 DMZ区（Demilitarized Zone）
又称非军事区，介于非安全区与安全区之间，此区域按需对外网用户提供部分服务。
1.6 FC SAN（Fiber ChannelStorage Area Network）
指采用光纤通道的存储区域网络，是一种将存储设备、连接设备和服务器集成在一个高速网络中的技术，SAN作为存储网络，与LAN网络隔离，主要承担数据存储任务。
1.7 FC Switch（Fibre Channel Switch）
指光纤通道交换机，是一种高速的网络传输中继设备，以光纤作为传输介质，是组成FC SAN光纤存储网络的光纤交换机。
1.8 HBA（Host Bus Adapter）
指主机总线适配器，是一个使计算机和存储设备间提供输入/输出处理和物理连接的电路板和/或集成电路适配器。
1.9 磁盘阵列（Redundant Arrays of Inexpensive Disks，简称Raid）
由多个容量较小、速度较慢的磁盘组合成一个磁盘组，以提升整体性能和存储空间。
1.10 虚拟机
指使用系统虚拟化技术，运行在一个隔离环境中、具有完整硬件功能的逻辑计算机系统。
1.11 负载均衡
分为硬件和软件负载均衡，软件负载均衡指通过将负载均衡软件***在一台或多台服务器相应的操作系统上来实现负载均衡，硬件负载均衡是直接将负载均衡设备部署在服务器和外部网络之间，专门完成负载均衡任务。
1.12 关键应用系统
指对业务开展起核心的支撑作用的,对可靠性（Reliability）、可用性（Availability）和可服务性(Serviceability)等具有非常高要求的应用系统，如资产管理系统、营销管理系统、财务管理系统、人力资源系统、协同办公系统和综合管理系统。
1.13 非关键应用系统
指除关键应用系统外的应用系统。
1.14 TPC-C测试
指模拟一个批发商的订单管理系统进行数据库事务处理测试,主要衡量服务器及数据库软件处理在线查询交易处理（OLTP）的性能表现，正规 TPC-C 测试结果发布必须提供 tpmC值, 即每分钟完成多少笔 TPC-C &(TPC-C Transaction Per Minute)数据库交易。
1.15 SPECweb2005
SPEC Web2005延续了SPEC传统测试的原理，通过多台客户机向服务器发出Http Get请求，请求调用Web服务器上的网页文件，这些文件从数千字节到数兆字节不等。在相同的时间里，服务器回答的请求越多，就表明服务器对客户端的处理能力越强，系统的Web性能就越好。
1.16 业务交易
在TPC-C估算法中，业务交易指的是用户的业务请求，用户每次查询、修改和删除操作均各算一次业务交易。
1.17 数据分级存储
数据分级存储是指将数据存放在不同级别的存储设备（磁盘、磁盘阵列、光盘库、磁带库）中，通过数据分级存储管理软件实现数据在存储设备之间的自动迁移。
2 基本原则
架构一致性原则。
安全性原则。
可靠性原则。
可扩展性原则。
绿色低碳原则。
3 软硬件平台架构
网络从安全角度上分，一般分为DMZ区和安全区（内网），根据应用的用途、架构、功能，选择适合的网络环境。
DMZ区和安全区（内网）内各信息系统应按照相关信息安全等级保护的要求，依据分区、分级、分域的的原则，进行安全域的划分，实现各安全域差异化的信息安全防护。
软件架构方面，对维护简单、不需要更新客户端的应用系统，建议采用Browser/Server（B/S）架构，对响应时间要求快、客户端操作界面复杂和有较多个性化要求的应用系统，可采用Client/Server（C/S）架构。
对性能要求不高的B/S架构应用系统，可采用Web客户端/应用服务器/数据库服务器三层架构；对性能要求高的B/S架构应用系统，应采用Web客户端/Web服务器/应用服务器/数据库服务器四层架构，Web服务器用于专门处理HTTP请求(request)，应用服务器通过多种协议为应用系统提供处理商业逻辑(business logic)。
4 存储设备
存储设备包括本地物理服务器（或者虚拟机）的存储设备和共享存储设备。对于共享存储设备，结构化数据建议采用支持FC SAN 或高带宽、低延迟的InfiniBand 网络的磁盘阵列，非结构化数据可以采用高性价比的NAS 作为存储设备。
存储网络交换机可选择FC SAN 交换机或InfiniBand 交换机，交换机应实现2N方式的冗余；存储网络交换机应支持Trunk级联，以便实现多套存储设备的共享。
存储设备的选择主要考虑性能、管理复杂程度与可扩展性，应支持存储虚拟化技术，以提高存储资源的利用率，降低管理复杂度和成本，支持开放结构，可方便的被其他厂商的系统管理软件使用，支持动态可扩展，无须终止应用程序即可扩展存储空间。
建议在DMZ区和安全区（内网）各配置一套共享存储设备，以满足不同信息系统对存储设备的需求。
对可用性要求高、数据读取速度快、存储空间需求大、在线可扩展等应用系统，原则上应使用共享存储设备；数据库服务器及虚拟化的物理服务器应通过存储网络和共享存储设备相连。
对于关键应用系统，建议采用数据分级存储，根据数据的访问频率、保留时间、容量、性能要求等因素设置数据迁移规则，将访问频率较低的数据存储在磁带库等成本较低、速度较慢的存储设备中，将访问频率较高的数据存储在磁盘或者磁盘阵列等成本较高、速度较快的存储设备中。
5 数据库服务器
关键应用系统的Oracle数据库集群建议采用多台小型机，可通过合理密度的虚拟化分区技术将一台小型机分为不同分区，建议将不同关键应用系统集群数据库的节点应***在物理服务器的不同分区上，同一应用系统集群数据库的不同节点应***在不同物理服务器分区上，节点的分布要结合系统的特点进行错峰安排。
Oracle数据库集群建议采用Real Application Cluster（RAC）的方式构建，可以充分利用RAC提供的负载均衡和实时灾难恢复的功能。RAC方式搭建Oracle数据库集群对应用系统架构有一定要求，应当注意：
1）通过程序控制各个RAC节点承担系统中相对独立的业务逻辑的后台数据处理，应尽量避免在多个不同节点上存放相同表的数据，以减少各个节点间内存数据通讯。
2）应用程序访问后台数据源的链接配置设置为Service方式，将多个数据源指向的数据库节点配置为不同的优先顺序，例如：3台数据库服务器机器为A、B、C，配置3个数据源，其中数据源1指向的数据库优先顺序为ABC，数据源2指向的数据库优先顺序为BCA，数据源3指向的数据库优先顺序为CAB。
为满足某些高负载、大用户量、数据库读写访问非常频繁的应用系统需求，可以考虑通过主从复制、垂直分区、水平分区等技术将数据库进行结构***。
1）主从复制：进行读写分离，写操作作用在主数据库节点上，通过数据库复制软件，结合业务数据更新周期利用业务低谷期进行数据同步。
2）垂直分区：将不同类型的数据存储在不同的数据库节点中，方便上层业务模块在部署上的分离。
3）水平分区：将同一个表的数据通过某种算法分布到不同的数据库节点上。
6 应用服务器/Web服务器
建议采用微机服务器或刀片服务器作为应用服务器/Web服务器的物理服务器，通过服务器虚拟化技术，在物理服务器 上创建虚拟机，将不同应用系统的应用服务器/Web服务器***在同一台物理服务器的不同虚拟机上；在部署多节点应用系统时，不同节点应尽量均衡分布在不同物理服务器上，以保证应用的高可用性。
针对服务器硬件配置要求较低、无特殊硬件（图像显示卡、音频卡、加密卡等）要求和I/O需求不高（IO吞吐率不超过50MB/s）的信息系统建议运行在虚拟机上，以提高资源利用率。
运行虚拟机的服务器应提供主要配件（如电源、硬盘、风扇、内存、网卡）的热插拔技术。
虚拟机数据应存放在共享存储设备上，以提高整体系统的可用性和性能。
关键应用系统的应用服务器/Web服务器前端应部署硬件负载均衡设备，根据预设的负载均衡策略，将用户访问导向负载压力较小的虚拟机/物理服务器。
使用Weblogic应用服务器组建集群时，应用系统软件设计中不能包含文件共享的文件服务和时间服务，可以在集群中的单个节点使用此类服务，但是不能提供平衡负载或故障转移功能。
针对Java应用服务器软件，应当根据应用系统实际情况和硬件服务器配置，调整Java的运行参数，最大程度优化系统的性能，如Java虚拟机堆的大小缺省是256M，建议根据虚拟机/物理服务器的内存大小将Java虚拟机堆进行调整，范围从512M（当内存大于2GB时）至1024M（内存大于4GB时）之间。
Java应用服务器 Weblogic和Websphere 集群必须满足以下条件：集群中的主机必须使用永久的静态IP地址，动态IP地址不能用于集群环境；集群中的所有服务器必须位于同一个局域网，并且必须是IP广播可到达的；集群中的所有服务器必须使用相同的版本，其中Websphere要求所有服务器都采用WSA ND版本；对于使用了JDBC连接的EJB，所有部署了某EJB的服务器必须具有相同的部署与持久化配置，即所有服务器均应有相同的JDBC配置；所有部署了servlet的主机必须维护一组具有相同ACL的servlet。
对于使用Weblogic的应用服务器系统，应避免将管理服务器(admin server)设置在集群的服务器中。
对web服务器，可采用各种缓存技术提升性能：将访问频率高的页面放到缓存服务器中进行缓存。
7 负载均衡
负载均衡设备主要应用于应用服务器和WEB服务器，关键应用系统因对性能要求较高，建议以共享的方式使用硬件负载均衡设备。
使用硬件负载均衡有两种部署方式：直联和旁路方式，建议采用旁路方式，将多台负载均衡设备分别连接到多台核心交换机，多台负载均衡设备间互为备份，不同应用系统的应用服务器/Web服务器集群共用多台负载均衡设备。
判断负载均衡是否采用主要和物理服务器/虚拟机的性能、应用系统所执行事务的复杂性等有关。Weblogic建议每个服务器并发线程数为（25-50）*CPU核数最优，如果应用系统所需最多的并发数超过（25-50）*CPU核数，建议配置多个服务器组成集群，使用负载均衡技术，将负载分布在不同的服务器上
建议将Weblogic或者Websphere的server部署在不同的物理服务器的虚拟机上，组成集群，以提高系统的可用性、稳定性。
8 资源分配方法
对存储资源采用***法估计，对数据库服务器资源采用TPC-C值估算法，对Web服务器资源采用SPECweb2005估算法，对应用服务器采用SPECjbb2005估算法。
资源分配的基本方法是首先了解信息系统的非功能性需求，初步估计各类型服务器（数据库服务器、应用服务器、Web服务器、接口服务器和其他服务器）总体资源需求，再根据需求冗余、安全等方面要求，确定各类型服务器所需物理服务器数量，基本原则如下：
1）单台服务器能提供足够处理能力的不再***为多台物理服务器。
2）数据库服务器采用双节点冗余（如Oracle RAC）时，处理容量一般按增长50%计算。
3）应用服务器采用多个逻辑(物理)节点组成集群时，4个节点以下（含4个）的集群，总体处理能力一般按各节点处理能力总和的60%计算，4个节点以上的集群，总体处理能力一般按各节点处理能力总和的50%计算。
4）web服务器采用多个逻辑(物理)节点组成集群时， 4个节点以下（含4个）的集群，总体处理能力一般按各节点处理能力总和的70%计算，4个节点以上的集群，总体处理能力一般按各节点处理能力总和的60%计算。
4.3 本指导意见的资源主要介绍存储设备、数据库服务器、应用服务器、Web服务器的资源估算方法，其他类型服务器的资源可参考进行估算。
4.4 在进行实际分配资源时，可根据资源需求的估算进行一定程度上的调整。
9 服务器资源估算方法
9.1.1 方法一：数据库服务器TPC-C估算法
适用范围：适用于对数据库服务器（应用服务器、Web服务器可参考）所需服务器的CPU能力进行估算。根据估算出的TPC-C值选择合适的服务器和服务器配置。
原理介绍：该估算法是通过计算应用系统峰值每分钟需要处理的业务交易数，再综合考虑业务交易的复杂程度、未来业务交易数量的增长和CPU处理余量等因素，通过公式计算得出一个估算值，以此来评估需要服务器必须达到的TPC-C值。
计算公式：TPC-C值 = ((TASK x 80%) /T) x S x F/C
参数解释：
TASK：典型工作日平均业务交易总量，指的是应用系统需要处理的用户业务请求的总和。
TASK x 80%：假设典型工作日80%的业务交易集中在高峰时段。
TASK x 80% / T： 即应用系统峰值每分钟处理的业务交易数。
T：应用系统典型工作日业务交易峰值（完成80%交易）持续时间，以分钟为单位。
S：实际业务交易操作相对于标准TPC-C测试基准环境交易的复杂程度比例。
F：系统未来的业务交易量发展冗余预留，需要根据应用系统情况估算。
C：服务器CPU利用率估算值。实际应用经验表明，服务器的CPU利用率高于80%则表明CPU的利用率过高会产生系统瓶颈，而利用率处于75%时，是处于利用率最佳状态。此值一般设定为C=75%。
计算步骤：
步骤一：估计应用系统平均典型工作日处理的业务交易总量
可以通过以下方法估算：
1、估算典型工作日平均登录系统的用户数。
2、估算平均典型工作日每个用户执行的业务交易数。例如，如果平均每个用户执行五次查询、五次修改和五次保存操作，那么平均每个用户执行的事务数为15次。
3、根据1和2估算出应用系统平均每典型工作日处理的业务交易总量。
步骤二：估算应用系统每日峰值持续时间（单位为分钟）
估算应用系统典型工作日峰值持续的时间，指的是应用系统典型工作日每天繁忙的时间。例如，股票交易系统每天的繁忙时间为上午9：30至 11:30和下午13:00至15:00，那么它的峰值持续时间为3+2 = 5 小时=300分钟。
步骤三：估算应用系统峰值每分钟需要处理业务交易数
计算应用系统峰值每分钟需要处理业务交易数时，需要估算典型工作日高峰时间处理的业务交易数占每天平均处理的业务交易总数的比例。通常按照20-80的原则进行估算，即80%的业务交易在高峰时间进行，20%的在非高峰时间进行。
根据上述步骤，可以算出应用系统峰值每分钟需要处理业务交易数。
步骤四：估算应用系统事务复杂度
由于实际业务交易的复杂程度与TPC-C标准测试中的业务交易存在较大的差异，应设定一个合理的对应值，根据经验，简单事务的S值为2-5，一般复杂事务为6-12，较复杂事务为13-16，高度复杂事务为17-20。针对数据库服务器，S值建议设置为15。
步骤五：估算应用系统未来一段时间后预留量。
如果预计未来用户数翻番，预留量即为200%。
步骤六：将以上各参数值代入公式，计算出TPC-C值。
步骤七：根据计算出TPC-C值，选择等于或者大于TPC-C值的目标服务器。
9.1.2 方法二：未公布服务器TPC-C值估算法
适用范围：本方法适用于通过厂商已公布型号服务器的TPC-C值估算未公布服务器的TPC-C值。
原理介绍：厂家通常会在www.tpc.org上公布满配置的某一型号服务器的TPC-C值，对于非满配置的服务器需要进行估算，而TPC-C性能指标反映的是服务器的整体性能指标，包括：系统结构、处理器、缓存、内存、I/O等，因此不能简单从TPC-C值推算出CPU、内存的数值，需要综合考察设备的整体性能。为了简化计算，假设服务器的TPC-C值和CPU数和频率呈线性关系，因此可以根据满配置的服务器大概估算出非满配置的相同型号或同档次服务器的TPC-C值。
计算公式：
目标配置服务器的TPC-C值 ≈（同型号服务器满配置的服务器的TPC-C值÷CPU个数÷CPU主频频率）* 估算服务器的CPU个数*CPU主频频率
计算步骤：
步骤一：获取满配置同类型服务器的TPC-C值，可以在www.tpc.org查到最新的某些类型的服务器TPC-C值或者通过厂商获取该值。
步骤二：将满配置服务器型号的CPU个数和主频、目标配置的服务器的CPU个数和主频等代入公式。
步骤三：通过公式计算目标配置的服务器的TPC-C值。
9.1.3 方法三：Web服务器SPECweb2005估算法
适用范围：适用于为支持满足特定吞吐量和客户请求响应速率要求的WEB服务器的性能进行估算。
原理介绍：Web服务器通常需要衡量它可以支持满足特定吞吐量和客户请求响应速率要求的WEB服务器的最大并发连接数量，而SPECweb2005是由标准性能评估组织（SPEC）专门开发的的Web服务器基准测试。服务器厂商通常会提供每种型号服务器的SPECweb;。使用本方法估算不考虑网络因素，假设客户端和服务器位于同一局域网中，网络传输时间可以忽略。
计算公式：SPEC Web;= (总用户数 * 在线率 * 在线用户平均发起http请求数)/ (1 -- 冗余率)
参数解释：
总用户数：应用系统总的用户数。
在线率：应用系统使用高峰时用户的在线率。
在线用户平均发起http请求数：平均每个在线用户发起的http请求数量。
冗余率：需要预留的冗余率。
计算步骤：
步骤一：估算系统总的用户数。
步骤二：估算应用系统使用高峰时用户的在线率。
步骤三：估算平均每个用户发起的http请求数量。
步骤四：设置预留的冗余率。
步骤五：将步骤一、二、三、四的估算值代入公式，计算出SPECweb;。
步骤六：根据计算出SPECweb;，选择等于或者大于SPECweb;的目标服务器。
9.1.4 方法四：应用服务器SPECjbb2005估算法
使用范围：适用于估算Java类应用服务器所需达到的服务器性能。
原理解释：SPECjbb2005是评估服务器端Java性能的SPEC测试工具。SPECjbb2005通过模拟三层C/S系统(主要是中间层)来评估服务器端Java的性能。该测试软件运行JVM(Java虚拟机)、JIT (Just-In-Time)编译器、碎片收集、线程以及操作系统的其他任务，它同时也测量CPU、Cache、内存和 SMP的性能。
服务器上运行基于J2EE的中间应用软件平台，可以将其应用处理能力量化为Java处理能力性能值SPECjbb2005，同时充分考虑系统的冗余处理能力以及系统资源分配情况，即可估算出服务器的处理能力性能值。
公式：SPECjbb2005 =A×B/（1-C-D）
参数解释：&
A：每秒最多需要同时处理的业务交易量。
B：每笔业务交易需消耗的SPECjbb2005峰值，根据经验，每笔业务交易消耗一般为200个bops，或根据该笔业务交易的java语句数量进行计算，B=该笔业务交易的java语句数/5。
C：系统的冗余处理能力。
D：非Java应用所占用的系统资源百分比。
例如某系统业务交易峰值为1000笔/秒，系统冗余处理能力预留30% ，非Java应用所占用的系统资源百分比为20%，根据计算公式，服务器SPECjbb2005性能值为：-30%-20%)=400,000。
9.1.5 方法五：数据库服务器内存估算法
适用范围：适用于估算数据库服务器（应用服务器、Web服务器可参考）所需的内存。
原理介绍：数据库服务器相对其他服务器来说，因为涉及大量的数据处理，需要把数据载入内存，以加快处理速度，所以需要更多的内存。对于内存的估算一般有下述两种方法，建议采用下述两种方法分别估算出所需的内存，取其中最大的数值。
计算方法：
根据标准化设计，将数据库内存容量（单位为G）和CPU的核心的数量的比例按照4:1配置，一个CPU的核心对应4G内存。例如服务器配置两个4核CPU则建议配置32G内存。
原理介绍：数据库服务器的内存主要包括：操作系统占用内存、数据库系统占用内存、数据库并发网络连接占用内存等。按照经验，Windows平台内存占用率不超过55%、Unix（或Linux）平台内存占用率不超过80%时，不会影响系统的性能。
计算公式：
数据库服务器（Windows平台）内存 = （操作系统占用内存+数据库占用内存+数据库并发网络连接占用内存+其他软件占用内存）/ 55%
数据库服务器（Unix或Linux平台）内存 = （操作系统占用内存+数据库占用内存+数据库并发网络连接占用内存+其他软件占用内存）/ 60%（前置条件：操作系统占用内存+数据库占用内存+数据库并发网络连接占用内存+其他软件占用内存≤4G）
数据库服务器（Unix或Linux平台）内存 = （操作系统占用内存+数据库占用内存+数据库并发网络连接占用内存+其他软件占用内存）/ 80%（前置条件：操作系统占用内存+数据库占用内存+数据库并发网络连接占用内存+其他软件占用内存&4G）
参数解释：
操作系统占用内存：操作系统运行需要占用的内存。
数据库占用内存：数据库服务器运行需要占用的内存。
数据库并发网络连接占用内存：数据库客户端和数据库服务器之间连接时，数据库服务器需要花费的内存。
其他软件占用内存：数据库服务器中其他软件运行需要占用的内存。
计算步骤：
步骤一：估算操作系统所占用内存
操作系统所占用内存具体和操作系统类型和版本相关，一般为600M内存。
步骤二：估算数据库系统占用内存
数据库系统占用内存主要包括：数据库服务器软件占用的内存和数据库缓存。其中数据库缓存和数据库大小相关，根据经验，数据库服务器在缓存容量达到数据库经常访问数据总量（注：数据库总量不包括系统数据）的5%时性能较好。数据库总量可以根据5.2 节中数据库数据估算的方法计算。因此，数据库系统缓存=数据库经常访问数据总量*5%。
数据库服务器软件占用内存和所用的数据库管理软件及版本相关，按照经验，一般为200M内存。
步骤三：估算数据库并发网络连接占用内存
数据库并发网络连接数每个占用5M。假设有200个连接，即并发连接占用内存为200 * 5M = 1000M。
步骤四：估算其他软件占用内存
& & 先估算需要***的软件，再估算每种软件占用内存的总和。为了简化计算，可以先估计每种软件占用内存大小Mi，再估计***的软件数Ni，即其他软件占用内存= 。 &
步骤五：估算所需内存
根据上述公式，估算所需内存。
10 存储资源估算方法
申请存储资源时应根据下述方法估算所需存储资源的需求，存储需求主要包括数据库存储需求、普通文件存储需求和系统运行存储需求三类。
项目 数据库存储估算
普通文件存储估算 系统运行存储估算
所需参数 1、系统需存储的实体表数据清单（用E表示）
2、实体数据的索引表数据清单（用I表示）
3、评估每个实体表每条记录存储数据容量需求（用S表示） 1、日志文件（用L表示）
2、其他文件（用E表示） 1、操作系统（用OS表示）
2、应用软件（如Weblogic）（用App表示）
3、其他软件需求（超过100M以上）（用E表示）
初始估算 1、应用系统实体表数据容量估算：
E1：实体E1本期记录M1个，每个容量S1 MB，该视图表的索引每个容量I1MB。
2、其他类推。 1、日志文件大小估算L
2、其他文件大小估算
E 1、操作系统大小估算OS
2、应用软件大小估算 App
3、其他软件大小估算 E
初始容量需求汇总 容量= (S1+I1) * M1 +…+(Si+Ii) * Mi
容量=L + E 容量= OS + App +E
容量冗余比率
（建议按照未来2年的存储需求估算） 容量* （1+容量冗余比率）
=((S1+I1) * M1 +…+(Si+Ii) * Mi&
）*（1+冗余比率） 容量*（1+容量冗余比率）=（L + E）*（1+冗余比率）
容量*（1+容量冗余比率）=（OS + App +E）*（1+冗余比率）
磁盘Raid冗余比率
（Raid1：增加100%
Raid10:增加100%
Raid5：增加50%） 容量*（1+容量冗余比率）*(1+磁盘Raid冗余比率)
=((S1+I1) * M1 +…+(Si+Ii) * Mi&
）*（1+容量冗余比率）*(1+磁盘Raid冗余比率) 容量*（1+容量冗余比率）*(1+磁盘Raid冗余比率)=
（L + E）*（1+容量冗余比率）*(1+磁盘Raid冗余比率) 容量*（1+容量冗余比率）*(1+磁盘Raid冗余比率)=
（OS + App +E）*（1+容量冗余比率）*(1+磁盘Raid冗余比率)
汇总 （(S1+I1) * M1 +…+(Si+Ii) * Mi&
）*（1+容量冗余比率）*(1+磁盘Raid冗余比率) （L + E）*（1+容量冗余比率）*(1+磁盘Raid冗余比率)
（OS + App +E）*（1+容量冗余比率）*(1+磁盘Raid冗余比率)
1、TPC-C估算法实例
1）情景描述：
a. 某应用系统平均每天20，000个用户次登录系统；
b. 平均每个用户执行五个查询事务和五个更新事务；
c. 每天最忙时间从上午9：15到上午10：15时间段；
d. 未来一年，用户数估计要增加一倍。
2）计算步骤：
步骤一：估算应用系统峰值每分钟需要处理事务数
高峰时间段每分钟需要处理事务数 = 20，000 x （5+5）x 80% / 60 = 2666.67
步骤二：估算应用系统事务复杂度：本实例事务复杂度为15。
步骤三：估算应用系统未来一段时间后预留量：预留量为200%。
步骤四：将以上各参数值代入公式，计算出TPC-C值。
TPC-C.67* 15 * 200% / 75% = 106,666
2、未公布服务器TPC-C估算法实例
1）情景描述：
TPC组织的网站上发布了最新的IBM的p5-595的TPC-C值测试结果，如下表所示：
型号 & & & & &处理器类型 & & & & &处理器主频 & & 处理器数量 & TPC-C值
p5-595 & & & &POWER5+处理器 & & & 2.3GHz & & & &64路 & & & &4,033,378 tpmC
假设需要估算32路CPU的TPC-C值。
2）计算步骤：
步骤一：获取满配置的同类型服务器的TPC-C值：4，033，378。
步骤二：将满配置服务器型号的CPU个数和主频、目标配置的服务器的CPU个数和主频等代入公式。
步骤三：通过公式计算目标配置的服务器的TPC-C值。
估算服务器的TPC-C值=（4033378 ÷2.3÷64）*2.3 * 32 = 2，016，689。
3、Web服务器SPECweb2005估算法实例
1）情景描述：
a. 某个应用系统的总用户数：100,000。
b. 用户在典型工作日的在线率为：25%。
c. 在线用户平均发起http请求数为：4。
d. 系统的预留冗余率为：20%。
2）计算步骤：
SPECweb;=（100，000 * 25% * 4 ）/（1 - 20%）= 125，000。
4、存储资源估算实例
1）数据库存储
情景假设：
a. 某个应用系统，主要包括客户、产品、订购关系等三个实体表，建立了3个索引；
b. 预计一年内客户数为10000个，每个客户数据3MB；
c. 产品数为200个，每个产品数据5MB；
d. 订购关系数为50000个，每个数据1MB；
e. 三种索引，每个索引的大小为1MB；
f. 假设考虑30%的容量冗余比率；
g. 磁盘采用Raid10冗余。
计算步骤：
a. 分别估算每个实体表的数量和大小
客户数据大小： 10000 * 3MB
产品数据大小： 200 * 5MB
订购关系数据大小： 50000 * 1MB
索引数据大小： 10000 * 1MB + 200 * 1MB + 50000 * 1MB
b. 初步容量需求汇总
初步容量需求汇总= 10000 * (3MB + 1MB) + 200 * (5MB + 1MB) + 50000 * (1MB + 1MB)
= 40000MB + 1200MB + 100000MB = 141,200MB
c. 考虑容量冗余的容量需求
考虑容量冗余的容量需求= 141，200MB ÷ (1-30%) = 141,200MB ÷0.7 = 201,714MB
d. 考虑磁盘raid冗余的容量需求
考虑磁盘raid冗余的容量需求=201，714MB * 200% = 403,428MB
2）普通文件存储
情景假设：
a. 某个应用系统存在三种容量较大的文件：日志文件、交易数据记录、收费文件；
b. 预计一定时期内，日志文件的大小可能达到3G, 交易数据记录文件的大小可能达到2.5G，收费文件的大小可能达到2G；
c. 假设考虑30%的容量冗余比率；
d. 磁盘采用Raid10冗余。
计算步骤：
a. 初步容量需求汇总
初步容量需求汇总= 3G + 2.5G + 2G = 7.5G
e. 考虑容量冗余的容量需求
考虑容量冗余的容量需求 = 7.5G ÷ (1- 30%) = 10.7G
b. 考虑磁盘raid冗余的容量需求
考虑磁盘raid冗余的容量需求= 10.7G * 200% = 21.4G
3）系统运行存储
情景假设：
a. 服务器上***windows 2003server操作系统、WebLogic8.0中间件和防病毒软件。
b. 假设考虑30%的容量冗余比率；
c. 磁盘采用Raid10冗余。
估算步骤：
d. 估算操作系统需要的存储容量大小
Windows 2003 server操作系统需占用4.5G空间。
e. 估算应用软件需要的存储容量大小
WebLogic 8.0软件需占用1.5G空间。
f. 估算其他软件需要的存储容量大小
***一套防病毒软件需占用1G空间。
g. 初步容量需求汇总
初步容量需求汇总 = 4.5G + 1.5G + 1G = 7G
h. 考虑容量冗余的容量需求：
考虑容量冗余的容量需求= 7G÷ (1 -30%) = 10G
i. 考虑磁盘raid冗余的容量需求：
本文已收录于以下专栏：
相关文章推荐
开篇一: 服务器主板 
服务器主板概述 
　　对于服务器而言，稳定性才是首要，服务器必须承担长年累月高负荷的工作要求，而且不能像台式机一样随意的重起，为了提高起可靠性普遍的做法都是部件的冗余技术，...
服务器事务处理性能测评标准TPC-C简介TPC_C基准是联机事务处理工作量的一个衡量标准。它是一种读操作和更新事务操作剧烈交互执行的处理，它模拟了被复杂的联机事务处理应用环境创建的活动，它是通过把很多...
DBA notes 的 Fenng 老大发了一篇为 MySQL 选择更合适的硬件的文章,我转摘过来,并根据自己的使用习惯做了点评.以下部分,红色字体为我的话.
---------------...
本文节选自浅谈服务器性能测试的全生命周期----从测试、结果分析到优化策略
小白用户一个，前段时间自己选择云服务器时就面临了不知道选什么参数配置的问题，也不知道各个性能指标是怎样限制服务器性能的。觉得...
如何为 MySQL 选择更合适的服务器硬件
PHP5研究室 日 06:06 查看3233次 作者: esayr  【大
文章分类：WEB架构
DBA not...
5 Minute DBA - Database Server Hardware Selection」讲了一些帮资料库选择硬体的方式，其实是偏向MySQL…
简单的说，CPU超过8 CPU其实意义不大...
他的最新文章
讲师：姜飞俊
讲师：汪木铃
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)