HISS性能管理服务简介V02(方案)

HISS北京SI部2009年

9月HISS系统性能诊断服务——SPDS说明资料(SystemPerformanceDiagnoseService)硬件：服务器:IBM磁盘阵列：220SSCSI盘阵软件：MicrosoftSQLserver行业内成熟的软件,单机运行问题：

系统上线两年后，用户反映这个系统的响应时间越来越慢，希望信息中心可以提升系统的性能。这样的升级改造令人心痛

第四次改造更换光纤盘阵

第三次改造

升级盘阵Fireware

第二次改造优化软件

第一次改造升级服务器规格。。。客户的忍耐已达极限！问题仍未解决！花费30万在预算内3个月过去了，业务部门反映系统没什么改变，该慢还是慢！找软件商重新开发软件历时10个月属于非模块开发，软件商收不到钱，开发效果可想而知，整体效果不明显升级盘阵的系统版本和补丁没有实质的效果！更换级别更高的光纤盘阵大半年过去了，慢的情况又发生了。。。一般系统优化的方式及弊端应用性能趋势图系统运行速度没有问题感觉有点慢速度越来越慢慢到无法忍受数据量增加趋势应用负载压力优化改造方案软件修改升级主机CPU,内存？采购更高速的盘阵？数据库调优更换更高速的硬盘？更换更大的服务器？加大盘阵上的缓存？优化改造面临的困扰改造后改善成效不如预期改造前系统瓶颈定位不易无法预测改善效果优化过程耗时费力有效的升级优化改造的步骤系统性能监控系统性能日志采集分析性能数据负载细化定位发现系统瓶颈负载告警分析性能负载跟踪性能负载对比性能趋势预测优化改造建议升级方案评估优化系统评测SPDS（SystemPerformanceDiagnoseService）

—

— 为您提供优质的系统性能诊断服务What：性能诊断管什么?

——提供必要的改造依据Why：为什么需要性能管理?

——为系统正常运行提供有力保证When：什么时候开始实施性能诊断?

——最好在系统初建时就开始跟踪Who：由谁来执行性能诊断?

——具有专业性能分析的人员（HISS）How：如何进行性能诊断?

——按照标准流程进行谁来保证升级的成功如何进行瓶颈定位升级改造后，还是慢！如何预测方案的有效性？多久可以改造完成￥￥￥???什么是性能诊断服务（SPDS）系统管理现状多数系统处于亚健康状态，且不知情系统犹如人的身体，需要定期做诊断检查。多数客户不了解系统健康状况，忽略或无法定位隐患/风险，直至发生重大故障，给业务造成不可挽回的损失；故障排除仓促无依据可循对于故障排除仅凭工程师经验；无量化的数据作为故障定位的有力证据；IT重复性投资情况比较严重对于系统改造，大多数客户由于缺少改造依据，大都凭借厂商的直观建议，没有进行系统的分析，多数改造不尽人意，所以产生重复性投资，造成资源/资金的过度浪费；性能分析缺乏必要的手段虽然对于操作系统、数据库、一些应用软件都有相应的监控类软件，但只能做到故障报警，无法将所有环节/因素串联起来，且缺乏有力的量化数据作为性能分析的依据；系统管理的现状除了升级改造时的困惑，目前IT管理还存在以下问题：HISSSPDS的必要性帮助IT部门把握系统运维全局帮助运维人员向上级进行预算申请提供申请预算的详细依据；为系统改造和故障对应提供有力的依据随时掌握系统的性能状况对于维护系统的正常运行，SPDS能为客户做到：性能模型的真实写照；分析报告的有力说明；长期性能分析数据；定期性能分析报告；日常运维时段：及时发现性能隐患、提早处理性能问题出现缓慢时段：准确定位性能瓶颈、有效提升应用速度系统改造时段：应用需求量化统计、申请预算最佳依据1234●依据各类操作系统自带的性能日志进行分析，无需安装任何软件SPDS服务方式●客户将性能日志以邮件或其它形式发送给HISS即可，不需要做其它工作●我们根据性能日志，制作出性能模型图（所有性能分析的依据）●根据性能模型图和与客户的沟通，为客户提供全面的系统性能诊断/分析服务，按服务层次/深度，提交各种分析报告SPDS服务方式说明SPDS服务方式说明客户“零风险”——无需安装任何软件；无需宕机；无需人员现场支持；无需业务中断；多平台支持——支持AIX、HPUnix、Solaris、Linux、ScoUnix、MSWindows等多种操作系统应用无关性——通过建立性能检测模型，分析底层数据，如：I/O、CPU、内存、数据库表空间等，可间接反应应用系统性能，与应用系统本身是什么软件无关潜在风险诊断——根据性能模型，分析系统的隐藏风险，即隐患，杜绝故障的产生，保证系统运行的健康性核心瓶颈定位——依据对系统性能的量化分析，对造成系统运行缓慢或发生故障的核心瓶颈进行准确的定位优化方案的制定——依据对隐患以及瓶颈的长期跟踪分析，对不同时间段、不同业务流程、不同性能现象，提供各种适合的改造方案。节省成本/显著增强优化效果SPDS的优势HISS系统性能诊断服务优势SPDS优势分析避免升级后效果不彰的结果，再方案的设计和实施前，必须有正确的方法进行升级成效的预测运行缓慢来自应用需求和资源负载的供需不平衡的所产生的问题，是需求量太大，还是供给量太低的原因所致，需要量化评估

只要确认性能改善目标，就可制定有效优化改造的步骤和方法，达到事半功倍的效果数据量的增长，是造成系统缓慢的主因。如何评估数据增长趋势和缓慢的关系，是有效解决性能问题的首要条件依据系统性能日志，由HISS制作系统性能模型，根据对性能模型的分析，准确定位真正的瓶颈和隐患预测升级方案改善成效制定性能改善目标应用性能变化趋势统计分析量化应用性能需求，评估现有资源负载建立性能模型，定位瓶颈隐患Step1Step2Step3Step4Step5随着服务层次不断加深SPDS性能分析层次展示SPDS性能分析层次展示前期服务正式服务（持续）服务介绍；需求调查；计划制定；手顺提交；性能管理2+7测试服务阶段前期服务服务方案制定正式服务前期沟通问题查找问题分析检测报告提交瓶颈评估改善建议针对客户存在的问题，HISS提供有针对性地解决方案改善措施8SPDS服务流程系统信息收集系统信息收集提供收集命令提供收集命令持续性数据收集签订服务合同提供收集命令进入性能管理持续服务视合同要求提供HISS的承诺！我们承诺——只基于操作系统层面获取性能日志信息，无需安装任何软件；不涉及客户公司内部任何资料及内部信息；不涉及客户公司任何应用系统及数据；无需宕机或业务中断，不影响业务正常运行；日志收集动作平均占用系统资源不到0.1%，不影响业务正常运行；如需要，可与客户签订保密协议；系统构架：一台IBMP590（12个双核CPU，24G内存）小型机和IBMDS4300盘阵，光纤直连，光纤盘阵；3年前上线，刚上线的时候就发生慢的现象，客户严重抱怨！序号业务流程处理时间耗时1数据入库

01:40–03:50130min.2数据转换

03:50–05:30100min3数据统计准备

05:30–06:4070min4数据统计

06:40:-11:50310min5任务查询

08:30–17:00改善目标：希望降低50%系统的整体负载，以提升用户端的响应时间；为了避免影响到业务单位，后台的数据统计，必须在8:00之前完成；考虑未来数据的增长趋势和因为每天从上级来的数据有可能在03:00才会到达，所以阶段性目标就是4小时内要完成所有的数据统计。如果以2007年12月21号的应用日志为例，共610分钟的统计时间必须在240分钟内完成，性能必须提升2.5倍。

610分钟时间过长国内某金融行业公司市场行情分析和风险控制系统SPDS案例分析一（1/2）存储性能分配不平均Raid划分不合理数据库表分配不合理应用的并发量不够瓶颈P590CPU性能P590内存性能没问题调整数据库结构；重新配置应用软件；重新部署存储性能；升级后模型2008-03-19优化后模型2008-04-15优化后模型2008-05-15优化后模型2008-06-15业务调整后模型监控(2008-12-10)业务增加后模型监控(2009-06-09)CPU升级后性能评估(2009-06-26)优化后的性能评估(2009-02-13)厂商的建议改造方案P590硬件提升更换存储设备改为SAN结构数据库结构调整应用软件配置变更存储性能调整经过性能分析后的改造方案存储性能分配不平均Raid划分不合理数据库表分配不合理应用的并发量不够P590硬件提升存储设配升级改为SAN结构无需购买任何硬件真正瓶颈投资：150万以上投资：不到80万不解决问题有效解决核心瓶颈SPDS案例分析一（2/2）SPDS案例分析二（1/2）服务器名Performance/LoadModelsDB_Server2msLoad

IOPS

DataFlow

dkFree

mCPU

Disk_C

Disk_DGW_Server2msLoad

IOPS

DataFlow

dkFree

mCPU

Disk_C

Disk_DBackup_ServermsLoad

IOPS

DataFlow

dkFree

mCPU

Disk_C

Disk_DOBSServermsLoad

IOPS

DataFlow

dkFree

mCPU

Disk_C

Disk_DACSServermsLoad

IOPS

DataFlow

dkFree

mCPU

Disk_C

Disk_DNIC_1NIC_2BAT_Server1msLoad

IOPS

DataFlow

dkFree

mCPU

Disk_C

Disk_DDB_Server1msLoad

IOPS

DataFlow

dkFree

mCPU

Disk_C

Disk_D

Disk_DGW_Server1msLoad

IOPS

DataFlow

dkFree

mCPUDisk_C

Disk_DRP_Server1msLoad

IOPS

DataFlow

dkFree

mCPUDisk_C

Disk_DNIC_1NIC_2RP_Server2msLoad

IOPS

DataFlow

dkFree

mCPUDisk_C

Disk_DNIC_1NIC_2某日资汽车制造公司e-CRM营销系统总共由10台PCServer、1台存储构成应用系统名称:e-CRB营销系统系统正式上线时间：2005年（4年）慢的现象描述上线1年后，有慢的现象，但不在意，在2008年就更严重进行过修改软件、调整数据库、数据归档和增加服务器的CPU和内存，及增加web服务器的缓冲区，以避免性能的问题。经销商的界面，在慢的时间段有时在1-3分钟没有响应。SPDS案例分析二（2/2）周三周六周五周一周日周二其中经过分析，锁定DB_Server1的Disk负