服务器监控及性能优化-田博辉
服务器监控与性能分析
服务器监控与性能分析对于企业和组织来说，服务器是一个至关重要的基础设施。
一个稳定、高效的服务器能够保障系统的正常运行，提高工作效率，保护用户数据安全。
然而，服务器也面临着各种潜在的问题，如硬件故障、网络异常等，这些问题可能导致系统崩溃，给工作带来不便甚至严重损失。
因此，对服务器进行监控和性能分析显得尤为重要。
一、服务器监控1. 背景介绍服务器监控是指对服务器的硬件和软件运行状态进行实时监测和记录，并及时报警和处理异常情况的过程。
通过服务器监控系统，管理员可以实时了解服务器的运行状况，及时采取措施预防或解决问题。
2. 监控指标服务器监控通常包括以下指标：- CPU使用率：监测CPU的运行情况，及时发现负载过高或过低的情况。
- 内存使用率：监测服务器内存的使用情况，防止内存泄露或内存不足。
- 硬盘使用率：监测服务器硬盘的使用情况，及时清理和扩容硬盘，避免存储问题。
- 网络流量：监测服务器的网络带宽使用情况，防止网络拥堵。
- 响应时间：监测服务器对请求的响应时间，确保系统快速响应用户需求。
3. 监控工具目前市场上有很多优秀的服务器监控工具，如Zabbix、Nagios等。
这些工具可以通过安装代理在服务器上收集数据，并提供友好的界面用于数据展示和告警设置。
管理员可以根据实际需求选择适合的监控工具。
二、服务器性能分析1. 背景介绍服务器性能分析是指对服务器运行性能进行定量和定性的评估和分析。
通过性能分析，管理员可以了解服务器的瓶颈所在，找出系统优化的方向，提高服务器的响应速度和负载能力。
2. 分析指标服务器性能分析通常包括以下指标：- 响应时间：评估服务器对请求的响应速度，尽量缩短用户等待时间。
- 事务处理能力：评估服务器处理并发请求的能力，提高系统的并发性能。
- 平均负载：评估服务器处理能力与实际负载情况的对比，及时调整硬件资源配置。
- 磁盘I/O：评估服务器磁盘的读写速度，减少磁盘访问时间。
- 网络延迟：评估服务器与客户端之间的网络延迟，优化网络连接速度。
OBIEE11G监控和优化性能
This guide explains how to monitor and optimize performance of Oracle Business Intelligence. It describes how to monitor service levels, set performance parameters, and configure query cache. For more detailed information about these and other tasks, see the Oracle BI EE documentation on Oracle Technology Network. 1. Start Fusion Middleware Control and go to the Business Intelligence Overview page. 2. Display the Metrics tab of the Capacity Management page. 3. On the Metrics tab, you can view metrics that are related to current responsiveness, load, and reliability. 4. To find out more about the following metrics, click the Help button: Request Processing Time (ms) SOA Request Processing Time (ms) Average Query Time (seconds) Active Sessions Requests (per minute) SOA Requests (per minute) Presentation Services Requests (per second) Server Queries (per second) Failed Queries Errors Reported (in the last hour) Understanding service levels typically involves monitoring process state and viewing system metrics. Viewing Common Performance Metrics Using Fusion Middleware Control 1. Start Fusion Middleware Control and in the tree navigator,expand the Business Intelligence folder and right-click the coreapplication node. 2. Select Monitoring , then select Performance . The Performance Summary page is displayed with a selection of metrics relating to this installation. Viewing All Oracle Business Intelligence Metrics Using Fusion Middleware Control 3. To customize the metrics that are displayed on the Performance Summary page, click Show Metric Palette . Then expand the metric category, and select or deselect individual metrics. The metrics that you select are displayed on the Performance Summary page. For information about a particular metric, right-click the metric and select Help . Monitoring Service LevelsViewing Metrics for Java Components Using the Oracle WebLogic Server Administration Console 1. Start Fusion Middleware Control and go to the Business IntelligenceOverview page. 2. Display the Performance tab of the Capacity Management page. 3. Click Lock and Edit Configuration . 4. Select Disallow RPD Updates to prevent updates to the repository file.5. Click Apply , then click Activate Changes .6. Return to the Business Intelligence Overview page and click Restart .3. Click Servers . The Summary of Servers page is displayed.4. Click the server name (for example, bi_server1).5. Click the Monitoring tab. 1. Start the Oracle WebLogic Server Administration Console.2. Expand the Environment node in the Domain Structure window.Setting Performance Parameters Using Fusion Middleware Control Disallowing RPD Updates Setting the User Session Log-Off Period 1. Start Fusion Middleware Control and go to the Business Intelligence Overview page. 2. Display the Performance tab of the Capacity Management page. 3. Click Lock and Edit Configuration . 4. Specify the expiry time. 5. Click Apply , then click Activate Changes . 6. Return to the Business Intelligence Overview page and click Restart .You can configure the Oracle BI Server to maintain a local, disk-based cache of query result sets (query cache). The query cache enables the Oracle BI Server to satisfy many subsequent query requests without having to access back-end data sources, such as Oracle. The query cache enables the Oracle BI Server to satisfy many subsequent query requests without accessing back-end data sources, thereby increasing query performance. As updates occur on the back-end databases, the query cache entries can become stale. Therefore, you must periodically remove entries from the query cache. For more information, see Oracle Fusion Middleware System Administrator’s Guide for Oracle Business Intelligence Enterprise Edition . Setting the Maximum Number of Rows Processed to Render a Table Note the following when setting this value: This specification applies to tables, not to pivot tables. The default value is 65000. The minimum value is 50. If the user exceeds the maximum value, then the server returns an error message when the table view is rendered. The maximum value is at least 16 bits, which varies by platform. The system is likely to consume all its memory before approaching a number larger than this value. 1. Start Fusion Middleware Control and go to the Business Intelligence Overview page. 2. Display the Performance tab of the Capacity Management page. 3. Click Lock and Edit Configuration . 4. Specify the maximum number of rows to be processed to render a table view. Enter an integer value greater than 50. 5. Click Apply , then click Activate Changes . 6. Return to the Business Intelligence Overview page and click Restart . Understanding the Oracle BI Server Cache 2. Display the Performance tab of the Capacity Management page. 3. Click Lock and Edit Configuration .4. Specify the maximum number of rows to download and maximum number of rows per page to include.5. Click Apply , then click Activate Changes .6. Return to the Business Intelligence Overview page andclick Restart .Configuring Query Cache Using Fusion Middleware Control2. Display the Performance tab of the Capacity Management page.3. Click Lock and Edit Configuration .4. Confirm that Cache enabled is selected. If Cache enabled is not selected, select it now.5. Specify the size of the query cache and the number of entries it can contain.6. Click Apply , then click Activate Changes .7. Return to the Business Intelligence Overview page and click Restart . Setting Global Cache Parameters 1. Start Fusion Middleware Control and go to the BusinessIntelligence Overview page 2. Display the Performance tab of the Capacity Management page. 3. Click Lock and Edit Configuration . 4. Specify the global cache path and the global cache size.5. Click Apply , then click Activate Changes .6. Return to the Business Intelligence Overview page and click Restart . Understanding the Global Cache In a clustered environment, Oracle BI Servers can be configured to access a shared cache called the global cache . This global cache resides on a shared file system storage device. It stores purging events, seeding events (often generated by agents), and result sets that are associated with seeding events. The seeding and purging events are sorted by time and stored on the shared storage as a logical event queue. Individual Oracle BI Server nodes push to and pull from the logical event queue. Each Oracle BI Server still maintains its own local query cache for regular queries.。
改善网络服务器响应速度的几点建议
改善网络服务器响应速度的几点建议刘彦平【摘要】目前，应网络为平台的信息应用是普遍存在的，不论是园区网内的信息应用，还是internet之上的信息应用，几乎都是C/S工作模式。
网络上的信息应用无不关注服务响应速度问题，如何改善网站及其通信环境的时间性能是找出改善网络服务速度的出路。
本文提出了相应的一些方法并进行了讨论。
【期刊名称】《电子商务》【年(卷),期】2013(000)010【总页数】2页(P56-57)【关键词】电子商务;数据流特征;时间特性;优化服务器性能;改善通信环境;负载均衡技术【作者】刘彦平【作者单位】首都经济贸易大学信息学院【正文语种】中文开展电子商务的企业的网络应用属于客户端-企业边缘应用，网络应用中的核心元素是WEB服务器（网站），该服务器是企业网络向外部网络发布信息和提供网络信息服务窗口，同时又是外部网络用户获取企业信息使用网络信息服务的门户。
Web服务器的性能表现直接影响着企业网络的功能质量，保证其优质的性能对企业的电子商务的功能表现至关重要，因此，在建设网站中需要认真做好网站性能设计。
一、电子商务网站的数据流特征电子商务应用是网络中客户端-服务器边缘应用，通过企业网络的边缘服务器为企业和企业的公共服务器之间交换数据，为企业的客户提供网络服务，实现企业在网上开展企业经营活动。
这些应用的关键节点就是web网站，在企业网和企业边缘之间，最核心的通信问题就是安全和可用性。
那些在企业边缘的信息应用对企业网的数据流量来说很可能是不可或缺的；因此，这些数据流量出现问题就有可能为企业带来不可估量的损失。
那些通过电子商务应用来为合作伙伴提供支持的企业，也常常将他们的电子商务器部署在企业网的边缘，而这些服务器与位于网络中的数据中心的数据服务器进行通信与至关重要。
因此，要求这些网络的通信资源和服务器要有高质量性能。
电子商务应用的网络架构和网络数据流量特点如图1，图中的反映的是数据流动走向。
在web应用中，网络外部用户通过浏览器向企业网的web站点发出浏览请求，web 网站通过访问企业网中的数据中心生成网页向外部用户提供网页，以提供网络服务。
中国电信股份有限公司重庆分公司_企业报告(业主版)
一、采购需求
1.1 总体指标
近 1 年(2022-03~2023-02)：
项目数(个)
661
同比增长：59.3%
项目总金额(万元)
(不含费率与未公示金额)
￥1126.44
同比增长：-100.0%
平均金额(万元)
￥40.23
同比增长：-100.0%
平均节支率
13.0%
同比增长：420.0%
*平均节支率是指，项目节支金额与预算金额的比值的平均值。（节支金额=项目预算金额-中标金额）
*按近 1 年项目金额排序，最多展示前 10 记录。
（2）广告业（50）
重点项目
项目名称
中标单位
中标金额（万元） 公告时间
TOP1
023 年一季度自营渠道用户活跃 中森（重庆）传媒有
提升活动项目中选结果公示
限公司
\
2023-01-19
TOP2
2022 年下半年线上宣传设计制作 重 庆 凡 可 广 告 传 媒
目标单位： 中国电信股份有限公司重庆分公司
报告时间：
2023-02-18
报告解读：本报告数据来源于各政府采购、公共资源交易中心、企事业单位等网站公开的招标采购 项目信息，基于招标采购大数据挖掘分析整理。报告从目标单位的采购需求、采购效率、采购供应 商、代理机构、信用风险 5 个维度对其招标采购行为分析，为目标单位招标采购管理、采购效率 监测和风险预警提供决策参考；帮助目标单位相关方包括但不限于供应商、中介机构等快速了解目 标单位的采购需求、采购效率、采购竞争和风险水平，以辅助其做出与目标单位相关的决策。 报告声明：本数据报告基于公开数据整理，各数据指标不代表任何权威观点，报告仅供参考！
Windows NT网络性能的分析和优化
Windows NT网络性能的分析和优化
郭毅
【期刊名称】《河北工业科技》
【年(卷),期】1999(016)004
【摘要】利用网络监视工具对Windows NT网络进行分析,针对不同的服务器类型和不同的网络流量在CPU、内存、硬盘、网络的方向进行优化.
【总页数】5页(P64-68)
【作者】郭毅
【作者单位】河北省科学院自动化研究所,河北石家庄,050081
【正文语种】中文
【中图分类】TP393
【相关文献】
1.Windows NT/2000安全性能分析 [J], 龚平
2.Windows NT请求式拨号网络的优化及实现 [J], 丁建立;冼伟经;王卫亚
3.Windows NT Server性能监控及优化 [J], 祁亮
4.Windows NT Server性能监控及优化 [J], 祁亮
5.对Windows NT核心的实时性能的分析与测试 [J], 路明;王平;齐智平
因版权原因，仅展示原文概要，查看原文内容请购买。
服务器监控管理
服务器监控管理
刘雄辉
【期刊名称】《网管员世界》
【年(卷),期】2007(000)023
【摘要】服务器是当今电脑计算体系中的楱心部分。
无论是运行关键任务的应用程序，还是诸如E-mail、文件、打印和数据库服务等核心IT服务，服务器的可用性和性能是决定这些业务能否顺利运行的重要因素。
但异构分布式环境的内在复杂性又使得服务器管理充满了必要性和挑战性，计算机系统的安全稳定运行已成为各项业务正常开展的前提和基础之一。
【总页数】3页(P75-77)
【作者】刘雄辉
【作者单位】福建
【正文语种】中文
【中图分类】TP311.138
【相关文献】
1.服务器监控系统实现方案 [J], 徐波;王建英
2.基于SSM+SpringBoot技术实现服务器监控的研究 [J], 张嘉豪;赵亮;翁铭隆;张华俊;李文欣
3.企业级服务器监控及数据化运维系统的研究 [J], 孔祥文;沈辰楠;张重阳;任仕辉
4.企业级服务器监控及数据化运维系统的研究 [J], 孔祥文;沈辰楠;张重阳;任仕辉
5.“慧眼”实现远程管理——联想万全慧眼服务器监控技术 [J], 周涛
因版权原因，仅展示原文概要，查看原文内容请购买。
提高SQL Server数据库访问速度的方法
提高SQL Server数据库访问速度的方法
张涛;田瑜辉
【期刊名称】《计算机时代》
【年(卷),期】2007(000)009
【摘要】当SQL Server数据库处理10万条以上的数据记录并且并发用户超过100人时,其执行速度迅速下降.文章以学校成绩录入与管理系统为例介绍了几种提高数据库访问速度的方法.
【总页数】2页(P65-66)
【作者】张涛;田瑜辉
【作者单位】黑龙江大学现代教育技术中心,黑龙江,哈尔滨,150080;黑龙江大学教务处
【正文语种】中文
【中图分类】TP3
【相关文献】
1.如何提高SQL SERVER数据库的课堂教学质量 [J], 杨柯
2.浅谈如何提高SQL server的访问速度 [J], 邓碧琴
3.提高SQL Server数据库安全性的几点思考 [J], 王桃群
4.提高《SQL Server数据库与应用》课程教学质量的探讨 [J], 彭文惠;吴小刚
5.浅析SQL Server数据库的性能优化方法 [J], 陈素芳
因版权原因，仅展示原文概要，查看原文内容请购买。
基于时延的动态非连续接收周期调整机制_黄波
第39卷第10期Vol .39,No .102009年10月JOU RNAL OF UNIVERSI TY OF SCIENCE AND TECHNOLOGY OF CH I NAOct .2009文章编号:0253-2778(2009)10-1107-07 收稿日期:2009-05-11;修回日期:2009-05-26基金项目:中国高技术研究发展(863)计划(2009AA01Z262)和国家自然科学基金(60971125)资助.作者简介:黄波,男,1985年生,硕士生.研究方向:宽带移动无线新技术研究.E -m ail :yellow huangbo @gmail .com 通讯作者:田辉,博士/教授.E -mail :tianh ui @bupt .edu .cn基于时延的动态非连续接收周期调整机制黄 波,田 辉,徐海博(北京邮电大学泛网无线通信教育部重点实验室,无线新技术研究所,北京100876)摘要:针对LTE 系统的下行非连续接收(DRX )机制,提出了一种基于业务时延要求的动态非连续接收周期配置算法.首先网络侧按照正常的非连续接收机制对终端侧进行节能配置,然后利用实时的时延大小对非连续接收周期进行动态控制.数值分析表明,业务时延与网络负载有密切的关系,用户DRX 周期配置需要与网络当前负载相结合;仿真结果表明,基于时延的动态周期调整机制,能够即时的适应网络状况以及自身需求的变化,与固定非连续接收周期相比,在用户满意度以及节能性上都有更好的表现.关键词:非连续接收(DRX );时延要求;动态周期中图分类号:TN929.5 文献标识码:AA delay based dynamic discontinuous reception cycle adjusting schemeH UANG Bo ,TIAN H ui ,XU Hai -bo(Key Laborator y of Un iver s a l Wireless Comm unica tions ,Ministr y o f Ed ucation ,Wireless Technolog y Innovation Institute ,Beijin g Univer sity o f Posts and Telecommunications ,Beijing 100876,China )Abstract :A no vel dy namic config ura tion scheme for discontinuous reception (DRX )cy cle based o n the delay requirement of service is proposed fo r the LT E dow nlink sy stem .First ,the eNB config ures the UEs w ith the po we r saving mechanism acco rding to the DRX specifications .T hen ,the delay paramete rs are used to control the DRX cy cle dy namically .Numerical analy sis show s that ,there is a close relationship be tw een service delay and netwo rk load .Therefo re ,the co nfig uration of the DRX cy cle should be co mbined w ith the current netw o rk load .Simulatio n results show that the delay based dy namic cy cle adjusting mechanism can adapt to the current netw o rk situatio n as w ell as their ow n requirements .Compared w ith the DRX mechanism w ith a fixed cy cle ,the perfo rmance of the proposed scheme has a g reat improvement in te rm s of user satisfactio n and po wer efficiency .Key words :discontinuo us receptio n (DRX );delay requirement ;dy namic cycle0 引言随着社会的不断进步,绿色环保、节能减排的思想不断深入人心.在个人通信不断发展普及的今天,在提供更高频谱利用率、更高速率、更丰富多媒体业务的同时,终端功耗问题显得尤为严重[1].为了最大程度支持终端移动性,保证优良的用户业务体验,需要在保证用户服务质量的前提下,尽可能的延长终端续航时间.无论是3G UM TS (universal m obile telecom munications system s )系统还是LTE (longterm evo lution)系统,都对节能机制进行了标准化工作[2],从一定程度上说明了节能的重要性.同样,在广泛关注的802.16e协议里,终端的功率节省机制也成为了一个重要组成部分.非连续接收机制(DRX)作为从无线通信系统链路层优化能量效率的一项重要方法被大多数的无线通信系统所采纳.其基本思想是允许终端在没有数据传输的时刻关闭无线收发单元进入休眠模式,以降低额外能量开销.在2G系统中,终端就已经采用了这种方式以增加待机时间.在GSM系统中,移动台每隔几帧(大约相当于八分之一秒的时间段)醒来一次,其他时间一直处于睡眠状态以关闭接收器降低功耗.然而GSM作为以语音为主体的系统,其呼叫接入时延要求很低而接入建立后的时延要求很高,其业务特征明显,因此非连续接收机制较为简单.在UM TS系统[3]中,终端的DRX机制划分为三个阶段:激活阶段、去激活阶段与休眠阶段.在数据传输时期,终端处于激活阶段,一直保持收发机开启以接收下行数据.当下行数据发送完毕,终端进入去激活状态并启动去激活计时器,仍旧保持收发机的开启状态,在去激活计时器溢出之前若有新的下行数据到达则终端重新进入激活阶段,否则进入休眠阶段.休眠阶段由周期的唤醒时期以及睡眠时期组成.睡眠时期的终端关闭收发机进行节能,而在睡眠时期的末尾进入唤醒时期,监听下行信道信息.文献[4]和文献[5]对UM TS的DRX机制进行了仿真和分析;文献[6]提出了一种基于两比特信令开销的UM TS系统DRX周期自适应的变化机制;文献[7]定义了能量参数与时延参数,通过这两个参数的计算实现UM TS系统DRX周期与去激活计时器动态配置,优化节能与时延性能.在IEEE802.16e系统[8]当中,配置了DRX的终端有两种操作模式:激活模式与睡眠模式.激活模式下的终端保持收发机开启持续接收下行数据.睡眠模式下的终端每隔一段时间唤醒一次监听下行信道,若有数据到达则进入激活模式,否则重复睡眠模式.在该系统当中的唤醒间隔时间可以有多种配置方案以适应不同的业务需求.文献[9]权衡了IEEE802.16e 系统的节能性与QoS(Quality of Service),提出了一种最小唤醒帧数的DRX策略;文献[10]基于业务模型为IEEE802.16e系统实现了自适应DRX配置.文献[12]证明了LTE系统有着比上述两类系统更为节能的DRX机制.LTE系统的终端被划分为3个基本进程:周期睡眠进程、去激活进程与重传进程.周期睡眠进程是指终端每隔一个固定的周期唤醒一次打开无线收发单元以监听下行信道信息,该周期定义为DRX周期,由DRX周期计时器进行控制,一个终端可以配置1～2个周期;唤醒后打开无线收发单元的持续时间称为开启时间,由开启时间计时器(on duratio n timer)进行控制.去激活进程是指终端一旦接收到新的下行数据,则开启或重启该去激活进程,去激活进程的长度由去激活计时器(inactivity timer)进行控制.重传进程是指终端接收到下行出错数据后,经过一个往返时延计时器的长度,再次开启收发器接收重传数据的过程,接收到重传数据的时刻则停止该进程,开启无线收发单元等待接收重传数据的最长时间由重传计时器(retransmissio n time r)进行控制.在上述的进程中,一旦出现开启时间计时器、去激活计时器或者重传计时器在运行,则都要保证无线收发单元处于开启状态.文献[12]对LTE的DRX机制进行了深入的分析,并建立了仿真模型;文献[13]提出了一种灵活的DRX构架,在该构架下的终端能够达到几乎最好的节能效果.本文通过分析LTE系统非连续接收机制的业务时延与用户数量的关系,提出了一种动态的非连续接收周期调整机制.仿真表明,该机制能够在高度节能的同时保证良好的用户体验.1 LTE系统非连续接收机制分析迄今为止,在DRX机制的节能性以及其QoS 保证方面已有部分建模分析.其分析参数集中在配置有DRX机制的用户的能量利用率、吞吐量以及唤醒时延而忽略了网络负载对用户的确切的包时延的影响.本节基于LTE的DRX机制,详细分析了多用户条件下,业务时延与用户数量之间的关系.如图1所示,配置有DRX机制的终端通信过程可由一个四状态的马尔可夫链来表示.A状态:用户处于周期性的唤醒与睡眠状态,网络侧对应于该用户的缓存为空;B状态:用户处于周期性的唤醒与睡眠状态,网络侧对应于该用户的缓存有数据待发送;C状态:去激活计时器控制用户处于激活状态,等待接收下行数据,并且网络侧对应于该用户的缓存不为空;1108中国科学技术大学学报第39卷D状态:去激活计时器控制用户处于激活状态,等待接收下行数据,并且网络侧对应于该用户的缓存为空,即该组下行数据已经发送完毕.图中的P X,Y,X,Y∈{A,B,C,D}表示本时刻处于X状态,经过一个TTI的下一时刻处于Y状态的转移概率.图1 马尔可夫DRX分析模型Fig.1 Markov chain for DRX analysis若用户的业务到达率为λ,DRX周期为T C,开启时间计时器长度为T O,去激活计时器长度为T I,每次业务的数据需要调度k次发送完毕,k为一随机变量,其均值为K.在业务量不大的情况下,即下一次业务包到达时刻一定在本次业务包发送完毕后,并且采用等概率调度模型,则各状态转移概率可以按下述分析求得.由于业务到达率λ为从A到B的转移概率,因此P A,B=λ,P A,A=1-λ(1) B状态的用户,虽然有下行数据包待发送,由于未受调度,仍然处于周期性的睡眠与唤醒过程中.若受到调度,则进入C状态.受到调度有如下需求:B 状态的用户处于唤醒时期,并且在唤醒期间受到调度.B状态用户处于唤醒时期的概率为T OT C,唤醒后受到调度的概率为1N,N表示处于激活状态并且有下行数据等待调度的用户总数.待调度用户总数N是一个随机变量,其均值N为处于C状态的所有用户数以及B状态用户中处于唤醒期间的用户数之和,即N=1+(n-1)P C+T OT CP B(2)式中P B与P C分别表示用户处于B状态与C状态的概率,n表示系统用户总数.故B状态中的用户唤醒后受到调度的概率为1 N =11+(n-1)P C+T OT CP B(3) 因此有P B,C=T OT C×1N=T OT C×11+(n-1)P C+T OT CP B(4) B状态的用户,若下一时刻仍处于B状态,有下述可能:①本时刻处于睡眠状态,不可能受到调度,其概率为T C-T OT C;②本时刻处于唤醒状态,但是未能收到调度,即该时刻调度的是其他的用户,其概率为 1-1N=T OT C×(n-1)P C+T OT CP B1+(n-1)P C+T OT CP B(5) 因此有P B,B=T C-T OT C+T OT C×(n-1)P C+T OT CP B1+(n-1)P C+T OT CP B(6) C状态的用户处于激活状态,若下一时刻处于D状态,则要求本时刻受到调度,并且调度后缓存为空.受到调度的概率仍为1N,而缓存调度后为空的概率为1k.因此有P C,D=1k×11+(n-1)P C+T OT CP B(7) C状态的用户下一时刻处于B状态,则要求本时刻未受调度并且本时刻后去激活计时器溢出.未受调度的概率为1-1N,去激活计时器溢出的概率为1T I,因此有P C,B=1T I×(n-1)P C+T OT CP B1+(n-1)P C+T OT CP B(8) C状态的用户下一时刻仍处于C状态,则要求本时刻受到调度但是缓存并未空,或者本时刻未受调度并且去激活计时器未溢出,因此有 P C,C=T I-1T I×(n-1)P C+T OT CP B1+(n-1)P C+T OT CP B+ k-1k×11+(n-1)P C+T OT CP B(9) D状态的用户,去激活计时器溢出则回到A状态,未溢出则停留在D状态,因此有P D,A=1T I,P D,D=T I-1T I(10) 至此式(1)、(4)、(6)、(7)、(8)、(9)和(10)已经列出1109第10期基于时延的动态非连续接收周期调整机制了所有状态转移概率的值,马尔可夫过程完全确定.下面分析时延(以调度周期为计量单位)与DRX 参数以及网络负载之间的关系.用户时延在此状态图中可以表示为用户自业务发起时刻(状态A 至B )到业务结束(状态C 至D )的时延.这一过程中,用户必将经历状态B 、C 到D .总时延D 就可以由D B ,C +D C ,D 来表示,即用户由状态B 转移到状态C 的时延与用户由状态C 转移到状态D 的时延.首先分析用户由刚进入B 状态至转移到C 状态的平均时延D B ,C .转移到C 状态的时间点一定是用户处于开启时间计时器运行期间.由于业务的到来与DRX 进程不相关,则业务到来时刻与第一次唤醒时刻的平均间隔为T C /2.其B 状态第一次唤醒受到调度进入C 状态的概率P Y 1以及其第一次唤醒未受到调度继续停留在B 状态的概率P N 1可以由下述式子表示:P Y 1=1-(n -1)P C +T O T CP B 1+(n -1)P C +T OT CP BT O (11)P N 1=1-P Y 1=(n -1)P C +T OT CP B1+(n -1)P C +T OT CP BT O (12)故第i 次唤醒进入C 状态的概率为P Yi =P (i -1)N 1×P Y 1=P (i -1)N 1-P iN 1(13)第i 次唤醒进入C 状态的时延为d i =(2i -1)T C /2(14)由此可以计算出B 状态至C 状态的平均时延:D B ,C =∑∞i =1di×P Yi = ∑∞i =1(2i -1)T C 2×(P (i -1)N 1-P i N 1)= T C 2+T C ×P N 11-P N 1(15) 下面研究用户由第一次进入C 状态至完成下行数据传输进入D 状态的平均时延D C ,D .由于C 状态进入D 状态有可能不止经过一次调度,因此首先需要得出C 状态下的平均调度间隔Δt s ,即从该次调度结束到下次受到调度所经历的时间的期望值.Δt s =∑∞i =1i ×(n -1)P C +T O T CP B 1+(n -1)P C +T O T CP Bi -1× 1+(n -1)P C +TOT CP B (16) 从C 状态到D 状态,需要经过k 次调度,由此带来的时延为D CD1=k Δt s = K + K (n -1)P C +T OT CP B (17)C 状态的终端还有可能再次回到B 状态,从而产生第二次的D B ,C 时延,并且这次D B ,C 时延由于起始时刻确定在开启时间计时器溢出时刻,导致有T C /2的时延扩展,此时的平均B 至C 状态转移时延变为D ′B ,C =T C +T C ×P N 11-P N 1=T C1-P N 1(18) 根据图1所示,C 状态在某个TTI 回到B 状态的概率为P C ,B ,那么在k Δt s 个T TI 内回到B 状态的概率为P back =∑k Δtsi =1(1-P C ,B)i ×P C ,B =1-(1-P C ,B )k Δts(19) 由于出现两次从C 状态回到B 状态,即用户在有数据尚未发送情况下连续两次出现去激活计时器溢出现象概率极低,因而忽略不计.因此,由C 状态回到B 状态所带来的时延开销可以如下表示:D CD2=P back ×D ′B ,C =[1-(1-P C ,B )k Δt s ]T C1-P N 1(20) 因此有D C ,D =D CD1+D CD2= K + K (n -1)·P C +T O T C P B +[1-(1-P C ,B )k Δts ]T C 1-P N 1(21) 于是,业务的平均时延D 可以由DRX 配置参数、业务到达率、用户数目唯一地表征,即D =D B ,C +D C ,D =T C 2+T C ×P N 11-P N 1+ K + K (n -1)P C +TOT C P B + [1-(1-P C ,B )k Δts ]T C 1-P N 1(22)),当用户数n 增加,则有以下分析:N 1←t s ←C ,B ←×P N 11-P N 1←-1)P C +TOT CP B ←(1-P C ,B )k Δts ]T C 1-P N 1← D ←(23)1110中国科学技术大学学报第39卷 可见,用户数量的增加,在配置了DRX 机制后,会对业务时延带来进一步的影响.而缩短用户的T C 可以减小时延,因此,对用户DRX 周期T C 的配置不能仅仅根据业务的时延要求,还应考虑实时的网络状况.2 动态非连续接收周期调整机制介绍本文所提的动态非连续接收周期调整机制是基于LT E 系统[11]的.在LTE 的DRX 机制当中存在若干需要权衡的因素[12].出于节能性考虑,则需要配置长的DRX 周期计时器、短的开启持续时间计时器与短的去激活计时器.而出于调度的灵活性、资源利用率以及业务Qo S 考虑,则需要配置短的DRX 周期计时器、长的开启持续时间计时器与长的去激活计时器;因为过长的DRX 周期会影响业务的接入时延,过短的开启持续时间计时器会影响业务的一次接入资源竞争成功率,导致有下行数据尚未受到调度之前终端再次进入睡眠状态,过短的去激活计时器会影响已接入业务的时延抖动.针对上述问题,本文提出了一种由时延参数控制的动态非连续接收机制,以解决增加DRX 周期、提高节能性与延长业务接入时延之间的矛盾.其基本出发点包括:(Ⅰ)不同的业务运行在不同的终端上有不同的时延要求,在满足时延要求的前提下,应尽可能地增加终端的DRX 周期以实现节能最大化.(Ⅱ)时延要求高的业务终端配置较短的DRX 周期,时延要求低的业务终端配置较长的DRX 周期.(Ⅲ)由本文第二部分分析可知,时延的大小还与网络当前的负载有关,网络负载越大则时延会相应增大,因此网络内的终端的DRX 周期都应该减小以增加激活时间的比例,减少时延,给予网络侧更多的调度选择,增大全网的吞吐量,保证业务的QoS .鉴于上述分析,终端DRX 周期需要进行动态配置,根据短期内统计的接收包的时延,确定DRX 周期长短的调整方法.具体执行过程可由如图2所图2 动态非连续接收周期调整机制Fig .2 Dynamic DRX cycle adjusting mechanism示的马尔可夫状态转移过程表示.Step 1 由RRC 层为终端配置DRX 功能.初始化过程中,不配置开启持续时间计时器的启动偏移时间(o n dura tion starting offset )[11],取而代之,在其配置空间添加一个0～C m -1之间的随机值t 1,其中C m 为最大DRX 周期的长度.若当前的DRX 周期为C ,则实际的开启持续时间计时器的启动偏移时间为t offset =C ×t 1C m.以此保证启动偏移时间处于(0,DRX Cy cle )范围内.Step 2 每隔一段固定的时间Δt ,统计该时间段内的所有数据包的时延,对比于该业务用户的时延期望值,分为三种可能:N :该用户前段时间包的时延过大,不能满足业务的时延期望需求;N ormal :该用户前段时间包的时延能够满足业务的时延期望需求;Y :该用户前段时间包的时延较小,完全满足业务的时延期望需求;Step 3 状态i ,i =2,3,…,9中的用户,若处于N 条件下,其DRX 周期在这次统计结束后自动减半,进入状态i -1;状态i ,i =1,2,…,9中的用户,若处于Normal 条件下,其DRX 周期保持不变,继续停留在状态i ;状态i ,i =1,2,…,8中的用户,若处于Y 条件下,其DRX 周期在这次统计结束后增加一倍,进入状态i +1.其中状态1中的用户处于N 条件下与状态9中的用户处于Y 条件下,其DRX 周期不发生变化,仍停留原状态.Step 4 每次统计结束后,清除原有的统计信息.使得该段时间内的业务数据时延表现不影响后一段时间内的统计结果.3 仿真分析为了比较动态DRX 周期配置方案与固定DRX 周期配置方案的性能优劣,本文对这两种算法在LTE 系统下的表现进行了系统级仿真.仿真参数如表1所示.为了比较两个算法的能量消耗,需要建立能量消耗模型.文献[14]给出了LTE 非连续接收系统的能量消耗参考值(图3).其中终端被划分为三种状态:(Ⅰ)深度节能状态:指终端处于较长DRX 周期的睡眠状态.该状态下,终端的空口功耗为0mW /TTI ;(Ⅱ)轻度节能状态:指终端处于较短DRX 周期的睡眠状态.该状态下,终端的空口功耗为11mW /TTI ;1111第10期基于时延的动态非连续接收周期调整机制表1 系统仿真参数Ta b .1 System level simulation parameters小区拓扑正六边形小区,19小区一簇,3扇区站间距500m 传输时间间隔(T TI )1m s路径损耗L =128.1+37.6log 10(R ),R 单位km 阴影衰落均值为0,标准差为8dB 信道模型T U6:基站用户间最小距离35m 运动速率3m /sOFDM 描述10M Hz 总带宽,15kH z 子载波间隔.12个子载波组成一个资源块,共180kH z .666个子载波中有601个用于传送数据,组成50个资源块业务模型H TT P 基站功率46dBm 噪声功率-174dBm /Hz图3 能量消耗模型Fig .3 Po wer consumption model(Ⅲ)激活状态:指终端无线收发单元开启的状态.该状态下,若无数据传输,则终端空口功耗为255.5mW /TT I ,否则为500mW /T TI ;补充说明,终端在这三种状态之间的转换也需要消耗能量与时间.其中,从深度节能状态转换至轻度节能状态,需消耗1ms 与22mW /T TI 的能量;从轻度节能状态转换至激活状态需消耗1m s 与39mW /T TI 的能量.同样的,仿真还需要比较两个算法对终端业务时延保证的表现.由于终端对时延的需求是不一致的,终端的平均时延低并不能反映终端的时延得到了保证,因而如果用所有终端发送数据的平均时延来定义时延表现是不合适的.类似于文献[15]中所述,本文定义一个终端时延不满意度:W u nsat =avr (∑iL i )(24)其中,L i 为时延要求不满足期望值的包的大小.这里需要一个期望值以区别于QoS 时延保证值,同时期望值应低于保证值,是用户能得到良好体验的一个时延值.对所有这类包的大小进行求和,包括时延远远超过期望值、达不到QoS 保证值的丢弃的包的大小,然后求其时间平均值,作为终端时延不满意度.即不满意度最终反映的是平均每个用户在每秒内无法达到期望值的传输比特数.图4示出了在不同的DRX 周期配置方式下终端平均功耗的表现.从图4中可以看出,随着DRX 周期的增长,终端的平均功耗在下降.而根据图2以及表2所规定的状态转移条件的动态周期调整机制,D -DRX1的终端空口平均功耗介于512～1024的周期配置之间,D -DRX2的终端空口平均功耗介于256～512的周期配置之间.图5示出了在不同的DRX 周期配置方式下的终端的平均不满意度.随着DRX 周期的增长,终端的平均不满意度在上升,其中D -DRX1配置方式的终端平均不满意度介于256～512的周期配置之间,D -DRX2配置方式的终端平均不满意度介于64～128之间.由此可以得出,D -DRX1动态配置方案在功耗低于固定DRX 周期512配置下,得到了不满意度低于固定DRX 周期512配置的表现;D -DRX2动态配置方案在功耗低于固定DRX 周期256配置下,得到了不满意度低于1112中国科学技术大学学报第39卷固定DRX周期128配置的表现.因此,在平均功耗与终端不满意度的表现上,D-DRX1完全优于周期为512的固定DRX配置机制,D-DRX2完全优于周期为256与128的固定DRX配置机制.同样的,对于其他周期的固定DRX配置机制,通过对状态转移条件的设定,都可以有更优的动态周期配置机制相对应,这里不再赘述.另外,本方案还具有以下两方面的优势:①通过不满意度的计算调整,可以对不同等级的用户实现不同等级的Q oS保证;②通过对条件N的定义方式,可以改变对终端的时延保障程度(N条件能容忍的不满意度上限值越低则终端功耗增加而不满意度下降),增加了网络的灵活性.表2 周期动态配置参数Tab.2 Configuration parameters of dynamic cycleD-DRX1D-DRX2N W unsa t>70W unsat>60 Normal0<W unsa t≤700<W unsat≤60 Y W unsa t=0W unsat=04 结论本文提出了一种基于业务时延要求的动态非连续接收周期配置算法.这种配置机制针对LTE系统提出,具有良好的后向兼容性.灵活的配置机制能够满足不同用户的即时需求,并且不受网络负载变化的影响.在节能性方面,该配置方法保持了LTE非连续接收机制中高度节能的特性,能够有效降低终端空口平均功率.DRX机制仍然还存在节能性与吞吐量等需要权衡的方面,这是今后的研究方向.致谢 本项目的研究得到DoCo Mo北京研究所的资助,在此表示感谢.参考文献(References)[1]戴凌龙.T D-SCD M A终端的低功耗研究及设计[J].电子技术应用,2007,33(3):97-99[2]3G PP.T echnical Specification G roup Serv ice andSystem A spects;3G P P System to W ir eless Lo cal A r eaN etwo rk(W L AN)Inte rwo rking;Sy stem Description: 3G PP T S23.234[S].3G PP,2004.[3]3G PP.3r d Genera tion Pa rtne rship Pro ject;T echnicalSpecification G roup Radio Access Netwo rk;U E Proceduresin Idle M ode and Pr ocedures fo r Cell Reselection inConnected M ode:3G PP T S25.304[S].3G PP,2002.[4]Yang S R,Lin Y B.M o deling UM T S Disco ntinuo usReceptio n M echanism[J].IEEE T ransactions onW ir eless Co mmunicatio ns,2005,4(1):312-319. [5]Yang S R,Yan S Y,H ung H N.M o deling U M T SP ow er Saving with Bursty Packet Data T raffic[J].I EEE T ranscatio ns on M obile Computing,2007,6(12):1398-1409.[6]Yang S,Yoo M,Shin Y.An A daptive Disco ntinuo usReceptio n M echanism Based o n Ex tended PagingI ndicato r for Po wer Saving in U M TS[C]//P ro ceeding s o f2006IEEE64th V ehicular T echnologyCo nfere nce.N ew Yo rk:IEEE,2006:831-835.[7]Yang S R.Dy namic P ow er Saving M echanism fo r3GUM T S Sy stem[J].M obile Ne two rks andA pplications,2007,12(1):5-14.[8]P ar t16:A ir interface fo r fixed and mo bile bro adbandw ireless access systems-Amendme nt for phy sical andmedium access contro l lay ers for combined fix ed andmo bile o per ation in licensed bands:IEEE802.16e/D5-2004[S].New Yo rk:I EEE,2004.[9]Liu Z,A lmhana J,M cG o rman R.A T r affic M odelingBased Po we r Sav ing M echanism fo r M obile Device s inW ir eless Sy stems[C]//P roceedings o f the6th annua lcommunication networks and services research conference.Los Alamito s,CA:IEEE Computer Soc,2008:107-114.[10]Lin C Y,Chao H L.Energy-Saving Scheduling inI EEE802.16e N etwo rks[C]//P roceeding s of33rdI EEE co nfe rence o n Lo cal Compute r N etw orks.NewYo rk:IEEE,2008:130-135.[11]3GP P.T echnical Specificatio n G ro up Radio A cce ssN etw or k;Evo lv ed U niver sal T er restria l Radio A cce ss(E-U T RA);M edium Access Co ntro l(M A C)pro toco lspecificatio n:3G PP T S36.321[S].3G PP,2008. [12]Zho u L,Xu H B,T ian H,et al.P erfo rmance A nalysiso f P ow er Saving M echanism with A djustable D RXCy cles in3G PP LT E[C]//P ro ceedings o f I EEE68thV ehicular Technolo gy Co nfere nce.N ew Yo rk:IEEE,2008:1-5.[13]K olding T,Wigar d J,Dalsgaar d L.Balancing P ow erSaving and Sing le U ser Experience w ith Disco ntinuo usReceptio n in L T E[C]//P roceedings of2008I EEEI nter na tional Symposium on Wirele ss CommunicationSy stem s.New Y ork:IEEE,2008:713-717.[14]N okia.DRX parameter s in E-U T RA N:3G PP R2-071285[R].3G PP,2007.[15]Xing B,Venkatasubramanian N.Multi-Constraint DynamicA ccess Selection in A lway sB est Connected Netwo rks[C]//P roceeding s of2nd Annual International Conference onM obile and Ubiquitous Systems:Networking and Services.Los Alamitos,CA:IEEE Computer Soc,2005:56-64.1113第10期基于时延的动态非连续接收周期调整机制。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
存档数据库操作优化
---尽量保证不回档 设计存读档缓冲，减少直接对数据操作 增加存档频率，设定重要存档节点 控制存档数据大小，可压缩 数据表设计合理 按战区分存档库
关键点 存档
压缩 数据 合理
缓存 存档
存档 正确
表结构
MMO服务器常用的优化手段
内存优化
单个对象的内存占用尽量少，比如使用标记位 频繁申请释放的对象使用对象池，消息，道具，子弹，NPC等 碎内存控制，长时间运行后会积累 重写new delete，用于统计和分析效率点和泄露 根据功能分多进程
高性能的设计是一种意识，而不单单是功能上的实现
架构上设计的高效和可扩展性是基础
与其他互联网产品的互通性思考
利用流程规避风险
细化设计文档，设定承载，内存，网络，IO，数据库操作频率等，帮助思考 过程监督，主要是数据结构上的选用是否合理，算法是否高效 定期利用工具诊断效率问题（Gprof Kprof gprof2dot.py等） 真实的外网测试环境，内外网络差异造成
除非必要，否则不必须全信任并等待 开辟专门的线程或者服务等用于第三方API调用，并设置长度 第三方调用、超时、失败要统计
保证自身系统受第三方影响降到最低
MMБайду номын сангаас服务器常用的优化手段
和业务上配合的优化
在线、存留的要求前期的新手村多出生点 虚假繁荣点的设定 活动修改,错峰进行
方案配合
流程 优化
与其他互联网产品的互通性思考
房间 数目
激活对 象数量
游戏内分析系统设计与实现
游戏内分析系统设计与实现
MMO服务器常用的优化手段
写在之前 对于在运行系统，优化可能牵一发而动全身，
尽快利用各种手段解决问题，保证项目运行。
MMO服务器常用的优化手段
逻辑帧速率优化（尽量控制150ms）
----找到最耗时的函数，内嵌检测，运行超时LOG 对象数量过多，大量道具，NPC等 数学计算过多，位置计算，子弹碰撞，伤害计算等 异常聚集，不可控的玩家行为
存档 状态
NPC 数量
服务器系统健康监控体系
各种开源工具、内嵌API、心跳等多种检测方式 硬件信息 汇总 监控服务 软件信息 阀值判定 各类报警
记录日志
健康监控体系报警，然后呢？ ---分析
游戏内分析系统设计与实现
数学 计算 帧速率 网络包 数目 网络连 接数目 线程 状态 数据库 状态 存档 状态 聚集 状态 监测和分析 是基于业务的 在线玩 家数量 NPC 数量
同帧 合并
重点 压缩 控制 同步
流畅
MMO服务器常用的优化手段
网络链接优化
创建链接开销大，使用网络连接池解决 开服、积分墙刷广告，从设计上支持动态增加网关服务器解决 撞库等异常的网络攻击，及时彻底释放，封IP解决
创建销毁 的开销
极限情况 的控制
安全处理 的手段
MMO服务器常用的优化手段
线程操作优化
灵活的可控制的开关系统和配置文件
随时指定某模块开放或关闭
随时控制物品的产生 随时控制任务ID的完成和接取 随时控制活动的开放和关闭 控制重新加载配置
多重开关和配置文件 会对产品的灵活控制 有很大的主动性
Q&A
THANK YOU
E-mail :tianbohui@
各个指标信息
运营系统记录汇总绘图
服务器系统健康监控体系
硬件监控项 CPU使用率
内网网卡使用率
内存使用率
外网网卡使用率
硬盘使用率
磁盘IO
服务器系统健康监控体系
服务器系统健康监控体系
软件监控项
帧速率 网络包 数目 网络连 接数目
房间 数目 激活对 象数量 道具 数量
线程 状态
数据库 状态
在线玩 家数量
----尽量减少锁的时间 尽可能的少调用锁 减小锁粒度 线程数控制，线程间切换开销 利用析构自解锁，防止死锁
游戏服务器的线程处理 一次交换收到的 消息到处理线程
写比读要频繁 分成读写锁 一次交换到写线 程批次写入 不频繁操作， 注意锁定时间
网络 数据库 存读档 内部LOG 系统 游戏场景 。。。
MMO服务器常用的优化手段
服务器监控及性能优化
田博辉
2016.8
目录
MMO游戏的常用架构 服务器系统及应用健康监控体系 游戏内常用的效率分析及对应的优化手段 与其他互联网产品的互通性思考 Q&A 环节
MMO游戏的常用架构
架构和业务是相互促进的
运营系统架构
游戏内监控体系
监控信息汇总到CMS 每个服务器定时汇报自身
大量 对象
• 分批计算 • 设置激活 • 同帧合并 • 减少聚集
同步
跨线程访问，不合理的线程粒度
锁操 作 数据 结构
• 减小粒度
• 减少锁时间
MMO服务器常用的优化手段
大量的网络包优化
----找到发送最多的包，流量统计，LOG记录 同步的消息在同逻辑帧合并发送，减少投递次数 大量的网络IO重点优化包 MMO的大量包产生在同步，控制范围 使用内存池，大量小内存的申请释放消耗很大 异常来回发送等逻辑BUG
架构细化
算法优化
真实测试
与其他互联网产品的互通性思考
服务器要有强大的LOG系统
可以实时设定等级LOG记录等级
分模块分功能的统计分析功能 峰值、均值、执行次数等统计 特殊性指定记录 ，某特定行为等 事件 统计 数据 流动 玩家 操作 系统信息 逻辑 LOG
论系统LOG的重要性
与其他互联网产品的互通性思考
控制申请 次数大小
使用 内存池
统计 内存使用
MMO服务器常用的优化手段
LOG系统优化
计算极限，各个相关设计写入读取频率和数量
大量LOG写入，分批次持续写入 LOG系统分级，控制写入阀值 统计系统同步，时间点选择
强大的LOG 系统是分析 问题的基础
决策
MMO服务器常用的优化手段
调用第三方API的优化 ---不是说第三方API不靠谱，只是考虑全面尽量少受影响