EAS常见系统性能问题处理指引# 检查Apusic License是否过期 1 Linux、AIX、HP-UX、Windows 在启动EAS的过程中或者从Apusic的启动日志中查看Apusic License输出信息。 如果是没有License限制的状态，可以看到类似如下输出内容： IP granted to 192.168.1.1 No time limits No connection limits 如果没有申请正式License，可以看到如下内容： Licensed from 2006-07-26 to 2088-09-13 Connections limited to 10 如果License和IP地址不匹配，Apusic将无法启动， ERROR [con.err] IP not granted for 192.168.1.1 如果License文件格式错误，例如把EAS License文件当成Apusic License了，则会看到如下输出信息： ERROR [con.err] Server cannot start without a valid license 解决办法：
1. 更换正确的License文件、购买并申请合法的License文件。
1.6 数据库常见性能问题 1.6.1 磁盘空间满
和应用服务器一样，磁盘空间满在数据库服务器上也是一种常见问题。当数据库磁盘空间满时，将出现数据库停止响应，无法连接，EAS功能报错等，错误信息可能包括无法扩展存储空间，无法创建连接等。
21 / 31
EAS常见系统性能问题处理指引可能原因包括：系统日志写满磁盘，如数据库运行日志以及事务日志，系统中的某些服务日志等。由于Linux和Unix系统存储划分大都有配额管理，如果配额分配不足，日志清理不及时，比较容易导致空间满的问题。如果数据库运行在归档模式，如果归档策略设置不当，导致日志清理不及时，容易发生磁盘空间间满的情况。
诊断和解决方法：同应用服务器。
1.6.2 CPU持续高消耗
CPU出现短暂的高消耗是正常的，一个服务请求需要一个CPU来处理，碰到一些耗时的操作，会出现一段时间某个CPU 100%的情况。但如果所有CPU的使用率都居高不下，伴随着系统性能的快速下降，以及个别CPU长时间100%，都是不正常的。
应用服务器某个CPU出现持续100%的情况，可能存在程序上的问题，导致CPU消耗一直很高，另外内存参数设置过低或者内存存在泄漏，可能引发频繁GC，也会出现CPU利用率偏高的情况。数据库服务器出现某个CPU持续100%的情况，可能碰到执行计划效率过低的情况。
诊断及解决方法：
1. 参考应用服务器常见性能问题中[CPU持续高消耗]章节。
2. 使用数据提供的监控工具跟踪分析，比如SQL Server Profiler、DB2 活动监控器、Oracle
EM等。
1.6.3 换页空间使用率高
换页空间使用率过高通常意味着内存资源吃紧，可能会导致频繁的换页操作降低系统运行性能，如果换页空间使用率超过60％，并且有增加趋势，可能引起应用以及操作系统故障。
诊断和解决方法：同应用服务器。
22 / 31
EAS常见系统性能问题处理指引
1.6.4 IO等待率高
由于应用服务器主要处理业务逻辑，除了向磁盘写一些日志外，没有其它IO操作，通常不会有IO等待问题，除非内存紧张导致频繁换页而产生较高的IO等待。数据库服务器会处理大量的数据，比较容易发生高IO等待的情况，比如存在大量的表扫描，或者存储设备的IO吞吐能力有限等。 诊断方法：
# 检查IO等待情况 1 Linux、AIX、利用vmstat可以诊断是否存在较高的IO等待情况。请参见[CPU持续高HP-UX 消耗]章节的描述。 还可以使用iostat，sar等操作系统命令等进行诊断，请查看相关命令的文档1。 2 Windows 使用性能监视器监控PhysicalDisk中的%Disk Time，Avg. Disk Queue Length， Disk Read Bytes/sec，Disk Write Bytes/sec。 3 SQL Server、使用数据提供的监控工具跟踪分析，比如SQL Server Profiler、DB2 活动DB2、Oracle 监控器、Oracle EM等。
解决办法：
1. 检查存储设备是否存在瓶颈或者故障并排除。 2. 检查操作系统、数据库参数配置是否不当并调整。 3. 专家协助分析。
1.6.5 数据库碎片化严重
无论是文件系统还是数据库系统，随着时间的推移，或多或少都会存在碎片化的趋势，如果碎片化程度不高，通常不需要处理。从已经处理的案例来看，数据库碎片化问题最容易发生在使用Oracle 10g的环境中，主要原因是Oracle 10g默认会打开回收站（Recycle Bin）选项， 1
取决于操作系统类型以及是否安装了相关组件，不一定可以使用这些命令。
23 / 31
EAS常见系统性能问题处理指引删除的对象会放到这个回收站中而不是真正删除，而EAS会使用特有的临时表（利用固定表
实现，表名为ZT或者VT开头的就是）来满足业务上的处理需求，这类表会被比较频繁的创建和删除，如果EAS临时表和数据表共用同一个表空间，则会导致碎片化的趋势加剧，从而引发性能问题，严重的情况下，会导致EAS性能大幅度衰减。 诊断方法：
# 如何判断数据库的碎片化程度 1 Oracle 进入sqlplus，执行如下SQL。 SQL> select tablespace_name,sqrt(max(blocks)/sum(blocks))* (100/sqrt(sqrt(count(blocks)))) FSFI from dba_free_space group by tablespace_name order by 1; TABLESPACE_NAME FSFI ----------------------------------------------------- ---------- EAS_D_ABC_STANDARD 66.2830849 EAS_D_ABC_TEMP3 64.8341444 EXAMPLE 67.3910029 SYSAUX 10.9872698 SYSTEM 81.2139268 UNDOTBS1 48.4495682 USERS 100 FSFI列即代表自由空间碎片索引（Free Space Fragmentation Index），其值越小，反映表空间的碎片化程度越高，如果低于10%，则应该进行表空间整理以消除碎片。如果这个SQL执行需要时间很长才能出来，同样反映表空间碎片化比较严重，见过执行10几分钟才能输出结果的案例。 解决办法：
1. 为EAS临时表创建专门的表空间，EAS管理控制台里数据中心管理中的存储管理功能可
以自动完成此工作，完成后请反部署再部署一下数据中心（集群环境需要在每个实例中做此反部署、部署动作）。
2. 通过逻辑备份和恢复（exp/imp或者expdp/impdp）来消除碎片，需要停机操作。 3. Oracle 10g以上版本有表空间重组（reorg）功能，可以在线重组，做之前请先做备份。
24 / 31
EAS常见系统性能问题处理指引
1.6.6 数据库阻塞和死锁
首先要明确阻塞和死锁是两个不同的概念，阻塞指的是一个事务在等待另外事务释放锁定的资源才能继续运行，而占用资源的事务可能需要执行较长时间才能完成，导致第一个事务出现等待，等的时间长了，就会形成阻塞，如果出现大面积的阻塞，对性能会产生严重影响。如果第二个事务继续运行的过程中发现其所需要的资源又被第一个事务所占用，就会形成相互等待的情况，这就是死锁，一旦发生死锁，就必须牺牲一个事务，否则大家都无法继续运行，通常数据库会自动检测死锁并牺牲其中一个事务。从这一点来看阻塞比死锁造成影响可能会更大。
SQL Server和DB2都有读锁，如果有许多长时间的事务在执行，可能会占用大量的资源而造成其它事务等待，形成阻塞，直到长事务执行结束。Oracle数据库没有读锁，其采用了特有的机制来保证读一致性而不会阻塞其它事务，所以Oracle数据库出现阻塞的几率会更小一些。 诊断方法：
# 如何判断数据库出现了阻塞 1 通用 如果出现如下现象，基本可以判断是发生了阻塞。 应用服务器、数据库服务器CPU和IO都不忙，应用服务器个别CPU可能出现持续100%占用的情况。 EAS某些功能一点击就会灰屏，但其它功能又正常。 2 Oracle Oracle 9i可以用Enterprise Manager的性能视图和锁视图查看所占用的情况来分析，如果发现有锁长时间不释放、大量锁定，并且有大量的enqueue等待事件，则说明发生了阻塞。 Oracle 10g可以利用基于Web的Enterprise Manager来分析阻塞，从顶级活动、阻塞会话、实例锁等多个功能来判断是否发生了阻塞。 3 DB2 通过DB2的相关工具或命令收集死锁以及锁定待日志，DB2快照等。 4 SQL Server SQL Enterprise Manager中的 管理 | 当前活动 | 锁/进程ID中查看当前的活动会话，如果发生阻塞会有明显的指示。 详细的跟踪分析方法，请参考EAS数据库跟踪分析相关系列文档。 解决办法：
1. 找到引起阻塞的会话或者进程，强行中止其运行。
25 / 31