WAS关键性能参数配置及异常分析
性能测试题库(优选.)
........................................................................................................................................................................................性能测试题库答案一、低难度类：1、理论类选择类1) 通过疲劳强度测试，最容易发现问题的问题是:BA．并发用户数B．内存泄露C．系统安全性D．功能错误2) 如下那些工具不属于压力测试工具:DA．LoadRunnerB．Logiscope（嵌入式测试工具）C．WAS(WebSphere Application Server(WAS)) (中间件服务器)D．Rational Robot(用于的G UI脚本、用于的V U以及V B脚本)3) 如下哪些测试场景不属于负载压力测试:AA．恢复测试B．疲劳强度测试C．大数据量测试D．并发性能测试4) LINUX 下，解压缩文件的命令为:BA. tar zxvf 文件名B. unzip 文件名C. CAT 文件名D. VI 文件名5) 对abcd 文件赋予所有者和组许可的读和执行权限，命令正确的是:BA. chmod 033 abcdB. chmod 550 abcdC. chmod 770 abcd........................................................................................................................................................................................D. chmod u+rx abcd6）在软件性能测试中，下列指标中哪个不是软件性能的指标DA）响应时间C）资源利用率D）并发进程数B）吞吐量7）下列关于软件性能测试的说法中，正确的是BA）性能测试的目的不是为了发现软件缺陷B）压力测试与负载测试的目的都是为了探测软件在满足预定性能需求的情况下所能负担的最大压力C）性能测试通常要对测试结果进行分析才能获得测试结论D）在性能下降曲线上，最大建议用户数通常处于性能轻微下降区与性能急剧下降区的交界处8）下列关于软件可靠性测试的说法中，错误的是AA）发现软件缺陷是软件可靠性测试的主要目的B）软件可靠性测试通常用于有可靠性要求的软件C）在一次软件可靠性测试中，执行的测试用例必须完全符合所定义的软件运行剖面D）可靠性测试通常要对测试结果进行分析才能获得测试结论问答类1) 什么是性能测试，其应用领域分别是什么？性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试，应用领域有四个：能力验证、能力规划、性能调优、缺陷发现。
WAS常见问题处理与系统维护建议
系统维护建议
健康检查 问题管理 补丁管理
Q&A
Page 3
<Document Title> | <Date>
IBM Confidential
© 2008 IBM Corporation
Global Technology Services
Page 8
Global Technology Services
Client Focus Commitment Collaboration
WAS的基本组件
Page 9
<Document Title> | <Date>
IBM Confidential
© 2008 IBM Corporation
Global Technology Services
Client Focus Commitment Collaboration
Java堆内存溢出 – 内存泄漏
正常情况下堆内存的大小应该是均值稳定的锯齿状图形
Page 19
<Document Title> | <Date>
IBM Confidential
堆内存耗尽
内存泄漏 内存使用量短时间内达到最大值（如很大的数据库查询结果集）
大对象分配
即为大对象 可添加JVM参数找出大对象：-Xdump:stack:events=allocation,filter=#5m
>64KB
堆内存碎片化（主要是V6.0及以前的版本）
pinned
Page 5
<Document Title> | <Date>
设备维保的技术参数和性能评价方法
设备维保的流程与内容
设备维保的流程
包括日常巡检、定期保养、故障修理 等步骤。
设备维保的内容
包括清洁、润滑、检查、调整、更换 磨损件等作业。
设备维保的常见问题与解决方案
设备维保的常见问题
如保养不及时、操作不当、维修技术 不过关等。
解决方案
加强设备管理制度建设、提高操作人 员素质、加强维修技术培训等。
设备安全性、稳定性、耐久性等
定期检查设备运行状况，评估设备故障率、维修次数等数据， 评估设备性能。
定期进行设备保养，更换磨损部件，调整设备参数等，确保设 备正常运行，提高设备使用寿命。
THANKS
感谢观看
02 技术参数分析
设备性能参数
设备性能参数是指设备的核心功能和性能指标，如机械设备 的转速、功率、精度等，电气设备的电压、电流、频率等。 这些参数决定了设备的基本性能和功能，是设备正常运行的 必要条件。
设备性能参数的测量和监控对于设备的维护和保养至关重要 ，通过对设备性能参数的监测和分析，可以及时发现设备的 异常和故障，采取相应的措施进行维修和保养，保证设备的 正常运行和使用寿命。
要点二
详细描述
根据设备环境适应性制定维保策略
设备的环境适应性对设备的运行和维护具有重要影响。在 制定维保策略时，需要考虑设备在不同环境条件下的适应 性，如温度、湿度、压力、腐蚀等，并根据设备的适应性 要求制定相应的维护和保养措施，确保设备在不同环境下 的正常运行和使用寿命。
05 案例分析
案例一：某工厂生产线设备的维保案例
维护和保养。
基于设备安全性能的维保策略
总结词
基于设备安全性能制定维保策略
详ቤተ መጻሕፍቲ ባይዱ描述
设备的安全性能是维保策略的重要考虑因素 。在制定维保策略时，需要评估设备的安全 性能，并针对可能存在的安全隐患制定相应 的预防措施和紧急处理方案，确保设备在运
无线网络优化与性能分析案例研究
无线网络优化与性能分析案例研究无线网络优化与性能分析是现代通信领域的重要课题之一。
在无线网络中，如何提高网络的性能和优化其运行是关键问题。
本文将通过分析一个实际案例来探讨无线网络优化与性能分析的相关内容。
案例背景：某高校校园内部署了无线网络，供学生和教职员工使用。
然而，近期网络的性能出现问题，许多用户反映连接速度慢、丢包率高等问题，给正常的使用带来了很大的困扰。
为了解决这一问题，校方决定进行无线网络的优化与性能分析。
问题分析：首先，我们需要对目前的无线网络进行一些初步的性能分析。
通过对网络设备的配置和性能参数的查看，可以了解当前的网络状况，包括无线信道的利用率、干扰情况、无线信号强度以及设备的负载情况等。
在对网络进行初步分析后，我们发现一些潜在的问题。
首先，由于高校校园内的用户密度较大，无线信道的利用率较高。
其次，因为无线信号的传播受到建筑物、树木等物理障碍物的影响，导致一些区域信号质量不佳。
最后，由于部分设备配置不当或老化，设备负载过高，无法满足用户的需求。
基于以上问题，我们需要采取相应的优化措施。
优化措施：针对以上问题，我们提出了以下的优化措施，希望能够改善无线网络的性能和用户体验。
1. 网络规划与信道优化：针对用户密度较大的问题，我们可以进行网络规划，将校园划分为不同的区域，并为每个区域选用不同的无线信道。
这样可以减少信道间的干扰，提高无线网络的整体性能。
同时，可以通过对信道的频谱分析来确定干扰源，并采取相应的措施来消除干扰。
2. 信号增强与覆盖优化：针对信号质量不佳的区域，可以采取一些技术手段来增强信号和优化覆盖。
比如，可以增加无线接入点的数量，提高信号覆盖范围；可以采用天线优化技术，改善信号的穿透能力等。
此外，对于一些特殊区域，如教室、图书馆等，可以考虑单独设置专用的无线接入点，以提高信号的专属性和稳定性。
3. 设备升级与负载均衡：针对设备配置不当或老化导致的负载过高问题，我们建议对相关设备进行升级或更换。
运行维护管理体系和制度规范
运行维护管理体系和制度规范目录1、总则32、编制方法33、运维工作职责34、运维服务管理体系54.1运维服务管理对象64.2运维系统功能框架64.3运维管理组织结构74。
3.1项目负责人84.3.2项目经理84。
3。
3技术主管94。
3.4服务台94.3。
5网络管理员104。
3。
5应用、数据库管理员104。
3。
7终端管理员114。
4运维服务流程114.4.1项目运维服务工作流程图124。
4.2服务台- 8 -3。
4.3事件管理- 9 -4。
4。
4工单管理- 9 -4。
4。
5问题管理- 9 -4。
4.6变更管理- 10 -4。
4。
7配置管理- 10 -4.4。
8知识库管理- 10 -4。
4.9统计及工作报告- 11 -5、运维服务内容- 11 -5。
1服务目标-11-5。
2资产统计服务-12-5。
3网络、安全系统运维服务-12-5。
4主机、存储系统运维服务-13-5.5数据库系统运维服务-15-5。
6中间件运维服务-16-5。
7终端、外设运维服务-17-6、应急服务响应措施- 20 -6。
1应急预案实施基本流程206.2突发事件应急策略207、服务管理制度规范217。
1服务时间217.2行为规范221、总则第一条为保障实验室系统软硬件设备的良好运行，使员工的运维工作制度化、流程化、规范化，特制订本制度。
第二条运维工作总体目标：立足根本促发展,开拓运维新局面。
在企业发展壮大时期,通过网络、桌面、系统等的运维，促进企业稳定可持续性发展。
第三条运维管理制度的适用范围：运维人员。
2、编制方法本实施细则包括运维服务全生命周期管理方法、管理标准/规范、管理模式、管理支撑工具、管理对象以及基于流程的管理方法。
本实施细则以ITIL/ISO20000为基础，以信息化项目的运维为目标，以管理支撑工具为手段，以流程化、规范化、标准化管理为方法，以全生命周期的PDCA循环为提升途径，体现了对运维服务全过程的体系化管理.3、运维部工作职责一、负责网站运维和技术支持(一）根据网站运营战略和目标,负责网站整体架构、栏目、应用系统等技术开发方案制定和组织开发,保障网站技术的稳定性和先进性。
IBM Websphere培训——JVM相关参数配置和问题诊断
1.Websphere JVM相关问题诊断：由JVM引起的Websphere问题主要有应用服务器宕机和性能下降，JVM相关问题的特征如下：(1).Websphere应用服务器停止响应：a.Websphere服务器宕机。
b.Websphere进程挂起。
c.JVM内存溢出。
(2).性能下降：JVM进程号(process Id)不停地改变。
2.诊断JVM相关问题所需文件：(1).核心文件(Core files)：a.进程快照或者系统的核心文件。
b.完整的JVM内存快照等。
注意：文件非常庞大，需要ISA(IBM Support Assistant)的日志分析工具解析。
(2).javacore文件：a.正在运行的java进程的快照。
b.Websphere应用服务器发生错误时自动生成的文件。
存储路径为：<WAS_install_root>/profiles/<profile>。
(3).JVM详细的垃圾回收器日志。
(4).JVM堆快照。
3.JVM垃圾回收器日志：(1).设置Websphere中JVM垃圾回收器步骤：在Websphere管理控制窗口点击：Servers->Applicationservers-><server_name>->Java and Process Management ->Process Definition->Java Virtual Machine, 勾选” Verbose Garbage Collection ”复选框，重启Websphere即可。
(2).JVM详细的垃圾回收器日志写在系统错误日志文件中(native_stderr)。
(3).在产品发布以后，推荐将Websphere的JVM垃圾回收器日志打开，它消耗资源非常的少。
4.JVM关于堆的相关参数设置：(1).JVM最大的堆内存大小(maximum heap, -Xmx)：设置合理的最大堆有助于JVM优化性能，最大堆越大，JVM垃圾回收器收集一次垃圾花费的时间越长；最大堆越小，JVM垃圾回收器运行很频繁。
WAS宕机常见问题及参考解决方案
WAS宕机问题总结起来有以下几类：一、线程挂起导致线程池满（Thread Hang）:Hangs refer to the JVM locking up or refusing to respond.A hang can occur when:1）Your application entered an wait leak2）Excessive Synchronization cause performance problems3）A deadlock has occurred收集日志：生成JAVA CORE分析工具：IBM Thread and Monitor Dump Analyzer1、线程等待泄漏(Wait Leaks)常见的情况就是，有很多线程使用wait()方法，等待被唤醒notify（）。
但是，存在某一个线程获取到锁并且进行业务处理完成后，忘记去唤醒等待执行的进程。
这样导致的等待泄漏，从而线程挂起。
When you use the wait/notify mechanism, you typically have one or more threads blocked in the wait() call, waiting to be notified. The notifying thread is supposed to call notify() or notifyAll() to signal that waiting threads can wake up and carry on processing.A problmatic situation could occur that the notify() call is invoked before the threads go into the wait() method. In this case, the waiting threads would not be notified anymore and become stuck.So, do not forget to notify the waiting theads in you application and maks sure that the Notify action is performed after all the waiting threads are started.应对策略：notify必须发生在所有wait之前。
VOLTE关键性能指标优化.
案例: EPC
现象描述:
UE2占用844199 PCI：69，RSRP=-97 SINR=7，收到主叫INVITE呼叫建立流程走到被叫上发180 ringing，网络层未下发Modify EPS Bearer Context Request，同时终端在做A3切换（目标小区417950 PCI:61），可能网络侧发送Modify EPS Bearer Context Request到源小区导致终端切换到 目标小区收不到。20s网络侧返回503 Service Unavailable，主叫call blocked 。
S1AP: INITIAL UE MESSAGE + EMM ATT_REQ + ESM PDN CONN_REQ
NAS Security Establishment (Authentication + NAS security start)
案例: 异常RRC连接释放
问题描述： 被叫UE占用PCI：61，收到来自主叫的BYE后,回BYE200,紧接着发生切换,1S后RRC连接释放. 问题原因： 1、为什么被叫收到BYE 后1S在没有回复去专载接收情况下，网络又下发RRC连接释放。
处理进展： 已抓取LOG，定位中
14
案例: IMS注册引起掉话
问题处理: 正常情况下，终端会在注册周期前完成注册，或者注册不应影响正在进行的本次通话，联系终端厂家,待终端厂家解决
15
案例: 异常去激活QCI9
现象描述:
UE1通话过程中接收来自网络数据业务寻呼，去激活QCI9 ，但是无BYE上报 ，还是在通话结束后上发BYE，不影响用户感知。
问题分析：发生这个问题是因为UE建立了两个承载,一个为ipv4承载给正常上网用的，另一个是ipv6承载，这个ipv6承载是无法上ipv6网(因为没有对接ipv6 骨 干网), UE得到的ipv6地址与其他UE有冲突触发UPCC删除这个多余的ipv6承载，这个不会影响正常业务(IPV4的承载还在)。另外不是所有的UE都会建两个承载 ，和UE的终端类型有关，当前大部分的终端都只是建一个ipv4承载。 刚也和测试人员陈斌(18850356626)电话确认，这种现象不影响正常上网。 核心网可以根据测试号只让ue建立ipv4承载,如果只是为了测试的话，可以按这个方案先规避。
解决问题的8个步骤（8DProcess）
解决问题的8个步骤（8DProcess）当碰到⼀个问题时，往往事发突然⽽不知所措，例如客诉、⽣产品质突然出现异常等等。
针对这样的事情，⼀些有经验的⼈研究了⼀套逻辑⽅法，把处理问题的步骤归纳成8个原则(8 Discipline)，使⼯程⼈员能清楚的知道⼀步步该作什么。
经过这样的步骤，问题的处理及解决通常较圆满，使⽤8D解决问题的⼯程⼈员亦会渐渐感觉⼯程实⼒不断增长，因此8D⽅法很快就在⼯业界中⼴泛流传，例如COMPAQ⼰把8D作为解决问题的标准程序。
以下就针对8D的每⼀步骤作⼀说明：8D的前置步骤: 当问题发⽣时，先保持冷静，并且尽你所能紧急补救，使损失降到最低。
例如先将客户⼿中可能有问题的零件换回，以防⽌其断线等事态之扩⼤，同时把事件发⽣的经过细节尽可能收集齐全。
D1-第⼀步骤: 建⽴解决问题⼩组若问题⽆法独⽴解决，通知你认为有关的⼈员组成团队。
团队的成员必需有能⼒执⾏，例如调整机器或懂得改变制程条件，或能指挥作筛选等。
D2-第⼆步骤: 描述问题向团队说明何时、何地、发⽣了什么事、严重程度、⽬前状态、如何紧急处理、以及展⽰照⽚和收集到的证物。
想象你是FBI的办案⼈员，将证物、细节描述越清楚，团队解决问题将越快。
D3-第三步骤: 执⾏暂时对策若真正原因还未找到，暂时⽤什么⽅法可以最快地防⽌问题？如全检、筛选、将⾃动改为⼿动、库存清查等。
暂时对策决定后，即⽴刻交由团队成员带回执⾏。
D4-第四步骤: 找出问题真正原因找问题真正原因时，最好不要盲⽬地动⼿改变⽬前的⽣产状态，先动动脑。
您第⼀件事是要先观察、分析、⽐较。
列出您所知道的所有⽣产条件(即鱼⾻图)，逐⼀观察，看看是否有些条件⾛样，还是最近有些什么异动?换了夹具吗?换了作业员?换了供应商?换了运输商?修过电源供应器?流程改过? 或⽐较良品与不良品的检查结果，看看那个数据有很⼤的差?，尺⼨?重量?电压值?CPK?耐电压?等等不良的发⽣，总是有原因，资料分析常常可以看出蛛丝马迹。
coredump配置、产生、分析以及分析示例
coredump配置、产⽣、分析以及分析⽰例关键词：coredump、core_pattern、coredump_filter等等。
应⽤程序在运⾏过程中由于各种异常或者bug导致退出，在满⾜⼀定条件下产⽣⼀个core⽂件。
通常core⽂件包含了程序运⾏时内存、寄存器状态、堆栈指针、内存管理信息以及函数调⽤堆栈信息。
core就是程序当前⼯作转改存储⽣成的⼀个⽂件，通过⼯具分析这个⽂件，可以定位到程序异常退出的时候对应的堆栈调⽤等信息，找出问题点并解决。
1. 配置coredump如果需要使⽤需要通过ulimit进⾏设置，可以通过ulimit -c查看当前系统是否⽀持coredump。
如果为0，则表⽰coredump被关闭。
通过ulimit -c unlimited可以打开coredump。
coredump⽂件默认存储位置与可执⾏⽂件在同⼀⽬录下，⽂件名为core。
可以通过/proc/sys/kernel/core_pattern进⾏设置。
%p 出Core进程的PID%u 出Core进程的UID%s 造成Core的signal号%t 出Core的时间，从1970-01-0100:00:00开始的秒数%e 出Core进程对应的可执⾏⽂件名通过echo "core-%e-%p-%s-%t" > /proc/sys/kernel/core_pattern。
在每个进程下都有coredump_filter节点/proc/<pid>/coredump_filter。
通过配置coredump_filter可以选择需在coredump的时候，将哪些内容dump到core⽂件中。
- (bit 0) anonymous private memory- (bit 1) anonymous shared memory- (bit 2) file-backed private memory- (bit 3) file-backed shared memory- (bit 4) ELF header pages in file-backed private memory areas (it is effective only if the bit 2is cleared)- (bit 5) hugetlb private memory- (bit 6) hugetlb shared memory- (bit 7) DAX private memory- (bit 8) DAX shared memorycoredump_filter的默认值是0x33，也即发⽣coredump时会将所有anonymous内存、ELF头页⾯、hugetlb private memory内容保存。
IBM WAS的几个性能分析工具
1.heapdump分析工具ha439.jar2.javacore分析工具jca437.jar3.native_stderr分析工具ga439.jar其中，在使用的时候，日志文件较大的话，要使用java -jar -Xmx参数增大最大内存值。
在分析native_stderr日志，即GC信息分析的时候工具可能出现日期时间数据不能解析的异常，这时你要试着替换检查一下日志文件中的日期时间格式，我记得是要增加或减少一个空格。
（以前遇到过这个问题，GOOGLE全球都没发现有人给个答案，结果自己把它试出来了）调用方式在cmd下运行命令：java -Xmx768m -jar ha439.jarjava -Xmx512m -jar jca437.jarWebsphere性能优化——面向切面分析Javacore一般情况下，我们会通过调整参数来提高系统性能，如线程池大小、连接池大小或者ORB 池等，也可以利用IHS实现静态文件分离，以上方式都是通过配置调整，利用并行或压力分离等方式实现对系统的优化。
我们还可以更换运算率更高的服务器，或者增加更多的物理服务器，通过硬件角度扩展达到性能调优的目的，但这种硬件扩容调优方式会使得项目的成本费用会大大增加，且优化成效还不一定能达到期待值。
当然，在以数据库操作为主的业务系统还可以调整数据库的参数，例如内存占用比率，增加命中，缓冲等的优化。
但以上这些优化方式都是从系统周边环境的角度进行考虑的，如果我们不了解我们的业务应用代码在JVM中是如何运行的，又或者各执行的请求是如何进行处理的，其处理的过程及处理步骤处于什么状态下，就盲目开展优化工作，就有了点瞎子过河——摸不着边的意思了。
因此，尽可能收集更多的信息，会让我们的优化工作事半功倍！除了自己实现线程请求监控记录外，我们还可以通过Javacore文件来进行线程转储。
通过采集和分析Javacore，了解JVM的运行情况，可以使我们更清晰地了解系统的整体运行情况，帮助我们判断系统是否运行正常，或是在繁忙时存在哪些隐患。
性能测试问题解决方法-19种情况
一、Error -27727: Step download timeout (120 seconds)has expired whendownloading resource(s). Set the “Resource Page Timeout is aWarning” Run-Time Setting to Yes/No to have this message as awarning/error, respectively处理方法：Run-Time Setting ------ Internet Protocol ------ Preferences------Option ------ Step download timeout(sec)改为32000A、应用服务参数设置太大导致服务器的瓶颈B、页面中图片太多C、在程序处理表的时候检查字段太大或多二、错误现象：Action.c(16): Error -27728: Step download timeout (120 seconds) has expired when downloading non-resource(s)。
错误分析：对于HTTP协议，默认的超时时间是120秒（可以在LoadRunner中修改），客户端发送一个请求到服务器端，如果超过120秒服务器端还没有返回结果，则出现超时错误。
解决办法：首先在运行环境中对超时进行设置，默认的超时时间可以设置长一些，再设置多次迭代运行，如果还有超时现象，需要在"Runtime Setting">"Internet Protocol：Preferences">"Advanced"区域中设置一个"winlnet replay instead of sockets"选项，再回放是否成功。
三、Action.c(7): Error -27791: Server “192.168.1.77″ has shut down the connection prematurely解决方案如下：1、应用服务器死掉。
WAS参数说明文档
历史日志文件最大数：5
连接池
资源> JDBC提供程序> (JDBC提供程序名) >数据源> (数据源名) >连接池属性
最小连接数：10
最大连接数：50
通过TPV监控连接池的大小变化曲线设置
最小：10
最大：100
语句高速缓存
资源> JDBC提供程序>
(JDBC提供程序名) >数据源>
(数据源名) >
选中
事务服务
服务器->应用程序服务器>(服务器名)>容器服务>事务服务
事务服务是一个服务器运行时组件，它可协调对多个资源管理器的更新以确保数据的原子更新。事务是由应用程序或部署应用程序的容器启动和结束。
总事务生存期超时=120秒
异步响应超时=30秒
客户机不活动超时=60秒
最大事务超时数=300秒
消息监听器服务线程池
聚焦周期：5秒
最小控制周期长度：59秒
最大队列长度：1000
内存超负荷保护：WAS堆大小的最大利用率：100%
控制周期长度：5分钟
最大连续重新启动次数：3
重新启动超时：5分钟
最小重新启动时间间隔：0分钟
控制周期长度：5分钟
最大连续重新启动次数：3
重新启动超时：5分钟
最小重新启动时间间隔：0分钟
பைடு நூலகம்资源JMS提供程序缺省消息传递JMS激活规范激活规范名
最大批次大小：无
最大并发端点数：无
根据实际情况分析
Web容器线程池
服务器>应用程序服务器>
(服务器名) >
线程池> WebContainer
WebSphere Application Server 常见问题及解答：开发与部署
WebSphere Application Server 常见问题及解答：开发与部署2009-08-17 09:501. WAS 产品包中的 Application Server Toolkit 可以为您的开发和运行提供哪些帮助？答：Application Server Toolkit（AST）为创建面向 WebSphere Application Server V6.1 的新应用程序提供了基本的支持。
其中包括用于创建新的 Web 应用程序、Web 服务、Portlet、EJB 组件的各种向导和工具，以及基于注释的编程支持、新的管理工具、用于编辑 WebSphere 特定绑定和扩展的工具，等等。
WAS V6.1包括了 J2EE 透视图和 Web 透视图、Eclipse 3.1 和 Eclipse Web Tools Platform（WTP） Version 1.0。
它本身是一个完整的 J2EE 开发环境，因此您可以使用它构造、调试并直接将新的应用程序部署到 WebSphere Application Server V6.1。
尽管完全能够开发 J2EE 应用程序，但 AST 只是 IBM Rational® 开发环境，如 Rational Software Architect 和 Rational Application Developer的子集。
图2中所示的层次结构能够很好的表明这几种工具组合的关系。
外层的工具提供的功能完全包含内层工具提供的功能。
图2 集成开发环境WAS V6.1 中的 AST 在 Eclipse Web Tools Platform 的基础上提供了下列关键特性：∙用于 WebSphere Application Server 的服务器工具，如调试和单元测试支持。
∙支持 WebSphere Application Server 特定扩展，如 SIP 和 Jython 工具。
中间件（WAS、WMQ）运维9个常见难点解析
中间件（WAS、WMQ）运维9个常见难点解析包括WAS、WMQ在安装、巡检、监控、优化过程中的常见难点。
安装1、was 负载均衡的机制的粘连性，was负载均衡异常？有⼀个case系统，部署在was集群环境，应⽤是集群环境，有的时候当⼀个节点异常的时，客户端访问该系统就会抛出异常，按正常情况，该会话应该不会断或者断了再连接⼀次就会到另⼀个节点，但是好多时候不管客户端如何连接，都不⾏，该正常的客户端⼀直是正常的，不正常重启机器也不正常。
当然其他新连接的节点也没啥问题，直到重启了故障节点的应⽤，原先不能正常访问的客户端才正常，就算当时清除浏览器缓存也不好使，哪位有这⽅⾯的经验可以多谈谈。
答：1，这是故障转移，was有内部机制可以做到1）内存到内存复制技术可以，缺点，因每台服务器共享session，所以占⽤内存⽐较⼤（如果server很少，可以考虑使⽤）。
2）存储到数据苦或者其他地⽅也可以实现。
推荐使⽤，但是实现较复杂2、如何⼤批量的完成WAS的安装和部署？有哪些⼯具和⽅法？如：⼏百台或上千台WAS服务器的安装和部署答：1，wsadmin 去写脚本是个好办法，配合虚拟化去做。
2，还有上千台的已经不适合去⽤商业软件了，建议去考虑下开源的软件，或者云平台了。
3、was安装低版本升级需要注意哪些⽅⾯？需要重新缴费吗？答：1，was 6 官⽅已经不再提供⽀持，除⾮额外买服务。
2，从2018年4⽉开始，将不再⽀持Java SE 6 与 WebSphere Application Server 配合使⽤，建议更新为 Java SE 7 或 83，WAS V7.0.x 和 V8.0.x 和 Portal Server V8.0.x 于 April 30, 2018 End Of Service低版本注意事项：1，规划好磁盘空间，内存和CPU2，规划好安装⽬录，尽量做到安装⽬录统⼀，规范。
3，了解好业务量⼤⼩，并发等等，⽅便你设计你的was部署⽅案。
KPI数据分析
1 概述网络性能KPI测试数据处理主要分为两个方面的内容：统计出KPI指标、统计出错误和异常发生的原因。
下面将分别就这两方面进行阐述：2 KPI指标统计2.1 何为KPI指标KPI即关键性能参数，主要有如下这些：➢呼叫/激活成功率：对应语音业务而言，称呼叫成功率，对于PS业务而言，称激活成功率。
➢RRC成功率；➢RB建立成功率；➢掉话率；➢切换成功率；➢网络时延：包括RRC时延、RB建立时延、MMC呼叫时延、MTC呼叫时延、PS 业务时延、切换时延；➢PS吞吐量；➢PS ping包时延，ping包成功率；2.2 KPI指标统计方式KPI统计有两种方式，可以用黄河的信令分析工具分析，也可以手动通过信令分析。
2.2.1 呼叫/激活成功率呼叫成功率有两种方式统计：路测统计：呼叫成功率＝呼通次数/总呼叫次数后台信令统计；呼叫成功率＝RRC成功率×ALERTING次数/（2×CM Service Request 次数）其中：RRC成功率统计方式将在后面介绍，ALERTING次数和CM Service Request次数通过信令统计，如下图所示（CM Service Request次数160次，Alerting次数306次）：激活成功率有两种方式统计：路测统计：激活成功率＝激活次数/总激活次数后台信令统计；激活成功率＝RRC成功率×Active PDP Accept次数/Active PDP Request 次数，如下图所示（Active PDP Accept和Active PDP Request次数分别为253，259）：2.2.2 RRC成功率RRC成功率是通过后台信令统计的：RRC成功率＝RRCConnectionSetupComplete总次数/（RRCConnectionRequest总次数－RRCConnectionRequest重传次数）首先通过信令跟踪工具中“信令数据统计”功能得到RRCConnectionRequest和RRCConnectionSetupComplete的总次数，如下图所示（RRCConnectionRequest和RRCConnectionSetupComplete的总次数分别为：270和267）：然后，找出RRCConnectionRequest重传次数，方法如下：1、过滤，在信令跟踪工具页面点击右键，选择“显示过滤”：2、在过滤窗口勾选“进行数据过滤”，然后在下拉菜单中选择“消息名称”，“＝”，在文字筐填入“rrcconnectionrequest”,点击“或条件”；用同样的方法添加“rrcconnectionsetupcomplete”,如下图所示，最后点确定。
网络巡检_精品文档
网络巡检简介网络巡检是一项关键的任务，用于保证网络的正常运行和安全性。
它旨在及时发现和解决网络中的问题，从而提高网络的稳定性和可靠性。
本文介绍了网络巡检的基本原理、方法和步骤，以帮助用户有效进行网络巡检。
原理网络巡检是通过检查网络设备、配置和性能参数，以及分析网络流量和日志来识别网络中的异常情况和潜在问题。
它可以帮助我们发现设备故障、配置错误、网络拥塞、安全漏洞等问题，并提供解决方案来修复这些问题。
方法下面是进行网络巡检的常用方法：1. 设备巡检首先，对网络中的各种设备进行巡检。
这包括路由器、交换机、防火墙、服务器等。
检查设备的硬件状态、固件版本、配置文件等。
确保设备正常工作并且没有任何故障。
2. 配置检查对网络设备的配置进行检查。
确保设备的配置文件与最佳实践相符合。
检查设备的接口配置、路由配置、ACL配置等。
查找潜在的配置错误，并提供修复建议。
3. 性能监测监测网络设备的性能参数，如CPU利用率、内存利用率、带宽利用率等。
通过分析这些性能参数，可以发现设备的性能瓶颈和资源短缺问题。
根据分析结果，提供性能优化建议。
4. 流量分析对网络流量进行分析。
使用流量分析工具，收集网络流量数据，并进行分析。
通过分析流量模式和流量趋势，可以发现网络中的异常行为、网络拥塞等问题。
根据分析结果，提供网络优化建议。
5. 安全检查进行网络安全检查，以发现网络中的安全漏洞和潜在的攻击。
检查设备的安全配置、访问控制列表、漏洞补丁等。
提供安全加固方案，确保网络的安全性。
步骤进行网络巡检时，可以按照以下步骤进行：1.确定巡检的范围和目标：确定需要巡检的网络范围和要达到的目标。
2.收集信息：收集网络设备的信息，包括设备类型、配置文件、日志等。
3.设备巡检：逐个检查网络设备的状态、配置和性能参数。
4.配置检查：对网络设备的配置进行检查，查找配置错误和不规范配置。
5.性能监测：监测网络设备的性能参数，分析性能数据，提供优化建议。
6.流量分析：收集并分析网络流量数据，发现网络拥塞和异常行为。
设备维保的设备性能指标与数据分析
04
实际案例分析
案例一：某工厂设备性能指标优化
总结词
通过优化设备性能指标，提高设备运行效率，降低故障率。
详细描述
该工厂在设备维保过程中，通过对设备性能指标的监测和分析，发现了一些潜在的问题和瓶颈。针对这些问题， 他们采取了相应的优化措施，如更换磨损部件、调整设备参数等，从而提高了设备的运行效率和稳定性，降低了 故障率。
利用算法对数据进行分类、聚类 、预测等，发现隐藏的模式和规 律。
数据分析结果的应用
故障诊断
通过分析设备运行数据，识别异常模式，判断设备是 否存在故障。
性能评估
根据数据分析结果，评估设备的性能指标，为设备的 优化和改进提供依据。
预测维护
利用机器学习算法预测设备的维护需求，提前制定维 护计划，降低停机风险。
数据分析对设备性能指标的优化作用
发现潜在问题
通过数据分析，可以发现设备性能指标的异常变化，从而及时发现潜在的故障或 问题。这有助于提前采取措施，避免设备损坏或生产中断。
提高设备运行效率
通过对设备性能指标进行深入分析，可以了解设备的运行状况和瓶颈，从而优化 设备的配置和运行参数。这有助于提高设备的运行效率，降低能耗和生产成本。
03
设备性能指标与数据分析的关系
设备性能指标对数据分析的影响
设备性能指标是数据分析的基础
设备性能指标的准确性和完整性直接影响到数据分析的结果。如果设备性能指 标存在误差或缺失，数据分析将无法准确反映设备的实际情况。
设备性能指标的动态变化
设备性能指标不是一成不变的，随着设备的运行和使用，其性能会发生变化。 因此，数据分析需要实时监测设备性能指标的变化，以便及时发现潜在问题并 进行维护。
随着设备维保的普及和重视，相关标准和规范将 进一步完善。标准化和规范化将有助于提高设备 维保的质量和效率，促进产业的健康发展。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
WAS关键性能参数配置及异常分析目录WAS关键性能参数配置及异常分析 (1)1.WAS性能关键参数配置 (3)1.1 JVM（Java虚拟机） (3)1.2 GC（详细垃圾回收） (3)1.3 Web Container (5)1.4 Data Source数据源 (6)1.4.1安装数据源驱动 (6)1.4.2配置全局数据源变量 (6)1.4.3配置数据源驱动 (6)1.4.4配置数据源 (7)1.4.5 Database连接池的参数配置 (10)1.5 其它关键参数 (11)1.5.1 EJB分发共享内存参数 (11)2.WAS性能分析工具 (11)2.1 WAS性能监控配置 (11)2.2 WAS性能监控 (11)3.WAS异常分析 (11)3.1 关键日志文件 (11)3.1 javacore、heapdump分析 (13)3.1.1 javacore的分析 (13)3.1.2 heapdump的分析 (19)1.WAS性能关键参数配置1.1 JVM（Java虚拟机）Heapsize（-Xms和-Xmx）：heapsize的大小依赖于系统平台和具体的应用等多种因素。
最大heapsize需要小于机器的物理内存，一般来说，默认最小heapsize为256m。
例如NG 设置的JVM为-Xms 512m，-Xmx 2048m。
如果在WAS应用服务器未设置JVM参数或者设置JVM参数不合理，会有可能告成应用服务器处理效率低或者造成OutOfMemoryError的情况。
备注：2m代表是2m的程序对象1.2 GC（详细垃圾回收）GC（Garbage Collection）：当需要分配的内存空间不再使用的时候，JVM将调用垃圾回收机制来回收内存空间。
一般来说，良好的GC状态需要保证相邻两次垃圾回收的平均间隔时间应当是单次垃圾回收所需时间的至少5-6倍。
GC的调优是通过在模拟压力的情况下不断调整最大最小heapsize来实现的，并不是heapsize设置越大越好。
通过在WAS应用服务器配置详细垃圾回收，从而可以使WAS在运行时生成native_stderr.log，native_stderr.log日志帮助分析JVM在进行GC垃圾回收时的数据，包括回收时间（频率）、长存区（tenured）在收回前、收回中、收回后的对比。
在实际的应用中可通过native_stderr.log来发现WAS JVM的性能问题并做出相应的JVM参数调整。
回收前一次：回收最新一次前后两次GC运行对比，可看行回收间隔为7S，一次GC运行时间不到1S，JVM的设置在较理想的状态值。
例如出现OOM的情况，可通过WAS产生的javacore及heapdump进行分析定位，并结合GC产生的native_stderr.log进行分析确认：GC耗时超过21S ，GC内存回收前的可用内存为0，GC内存回收后的可用内存为0%，可用JVM内存已耗尽，说明系统使用存在内存泄露（OOM）现象。
1.3Web ContainerWeb容器J2EE标准的实现，为serverlet和jsp提供运行环境。
例如，当一个HTTP请求通过要访问一个web组件（通常是一个serverlet或者是jsp），通常是将这个请求转发给web container处理完毕后再返回到web server。
Web Container的调优是通过对Web Container传输链中各个通道（TCP、HTTP、WebContainer）的参数调整进行的。
这些参数包括诸如ThreadPool的最大最小值，buffer 大小，timeout时间的大小，keep-alive的值等等。
一般配置WebContainer即可，需根据业务的实际使用情况进行值的配置，主要业务在WAS 达到的应用连接数，其它值为默认值即可：1.4 Data Source数据源1.4.1安装数据源驱动拷贝驱动JAR包到/usr/websphere/AppServer/lib目录，如：cp ojdbc6.jar /usr/websphere/AppServer/lib1.4.2配置全局数据源变量登陆控制台：https://WAS IP:9043/ibm/console/logon.jsp（1）“环境”—> “WebSphere变量”，选择作用域为：集群=所有域（2）增加全局变量：ORACLE_JDBC_DRIVER_PATH“新建”—>名称：ORACLE_JDBC_DRIVER_PATH值：/usr/websphere/AppServer/lib备注：NG未用到全局变量。
1.4.3配置数据源驱动增加ORACLE驱动：资源—>JDBC—>JDBC提供程序1.4.4配置数据源根据系统规划需求，按规划配置数据源。
（1）登陆控制台：https://WAS IP:9043/ibm/console/logon.jsp；（2）资源->JDBC->数据源新增数据源（“名称和JDNI名称”与规划的ID和VALUE对应）；备注：建议数据库地址不直接使用IP而用主机名代替，方便后续维护（3）J2C认证数据配置登陆账号信息；备注：修改完数据源需要重启动WAS服务（重启动应用也不能生效）1.4.5 Database连接池的参数配置在各自的数据源可配置该数据源的连接池大小配置，选择资源->JDBC->数据源->连接池，可配置连接池最小、最大连接数及连接超时时限等。
1.5 其它关键参数1.5.1 EJB分发共享内存参数用root用户登录命令行修改每个WebSphere安装路径的$WasIntallPath/AppServer/deploytool/itp/ejbdeploy.sh内容，根据主机资源情况将EJB 分发共享内存上限从默认256M修改为更大的值。
“$JAVA_CMD \-Xbootclasspath/a:$ejbd_bootpath \-Xms256m –Xmx256m”2.WAS性能分析工具2.1 WAS性能监控配置后续补写2.2 WAS性能监控后续补写3.WAS异常分析3.1 关键日志文件（1）SystemOut.log、SystemErr.log、was_server/logs/ffdc目录的日志查看最新WAS异常时段的SystemOut.log、SystemErr.log日志，搜索Error、Exception、Thread、OutOfMemory等相关关键字进行分析定位异常情况。
查看保留ffdc目录的日志文件，ffdc工具试图在发生非正常的情况时，自动获取并保留关键信息，其中包含堆栈跟踪、异常发生时的环境等相关信息。
可结合SystemOut.log、SystemErr.log等相关日志进行异常的定位。
NGBOSS的SystemOut.log、SystemErr.log日志存放位置：/waslogs目录（2）native_stderr.log、native_stdout.lognative_stderr.log日志可查看出JVM垃圾回收的记录及每次GC的间隔时间及运行时间，如下图所示：红色标识分别为：GC运行时间点、垃圾回收前内存情况、垃圾回收后内存情况、GC运行时间长。
从结果可看出JVM中已无内存可再回收，JVM处于OOM的状态。
可以看出java/lang/OutOfMemoryError：(3) 收集Web server服务器日志收集IHS日志（access_log、error_log）及插件Plug-in（plugin-cfg.xml and http_plugin.log）的日志及配置文件，查看是否出现异常信息。
例如http_plugin.log，可能提示一个连接无法正常发送到相关WAS Server，不过尝试连接其它WAS Server，这种情况可能是无法连接的Server处理较繁忙的状态或者网络中断。
3.1 javacore、heapdump分析java程序在遇到致命异常时，为了能够保留java应用发生致命错误前的运行状态，jvm 在无法工作前产生两个文件，分别为javacore及heapdump文件。
3.1.1 javacore的分析Javacore文件是一个java进程的快照，javacore文件中可以显示当时运行这个java 进程的所有线程的运行情况。
➢我们可以利用javacore来分析和判断一些故障，如：（1）100% CPU Usage （2）Crash或OOM（3）Hang/Performance ➢Javacore目录的设置在环境条目分别填入：➢Javacore的文件名Javacore文件的命名是根据系统的计算得来的，如javacore24802.1026159146.txt，而且是唯一的。
下列是根据操作系统的不同产生的名字不同：NG现AIX环境下产生的javacore文件：javacore.20130128.180057.13041766.0024➢Javecore的产生Javacore的产生有两种方式，一种是自动产生，一种是通过kill -3 PID进行生成。
自动产生Javacore，一般都是出现OOM的情况。
➢Javacore的分析（1）直接打开Javacore文件查看直接打开后，可以看到关键信息，可以看到每一个线程的执行栈，以stacktrace的方式显示。
通过对javacore的分析可以得到应用是否“卡”在某一点上，即在某一点运行的时间太长。
例如：可看出有java/lang/OutOfMemoryError的异常信息。
（2）运用javacore分析工具下载javacore运行工具jca:运行java –Xmx1024m –jar jca.jar:可看线程运行情况：请求线程可分为以下几种状态：死锁，Deadlock（重点关注）执行中，Runnable（重点关注）等待资源，Waiting on condition（重点关注）等待监控器检查资源，Waiting on monitor暂停，Suspended对象等待中，Object.wait()阻塞，Blocked（重点关注）停止，ParkedDeadlock：死锁线程，一般指多个线程调用间，进入相互资源占用，导致一直等待无法释放的情况。
Runnable：一般指该线程正在执行状态中，该线程占用了资源，正在处理某个请求，有可能正在传递SQL到数据库执行，有可能在对某个文件操作，有可能进行数据类型等转换。
Waiting on condition：等待资源，如果堆栈信息明确是应用代码，则证明该线程正在等待资源，一般是大量读取某资源，且该资源采用了资源锁的情况下，线程进入等待状态，等待资源的读取。