金蝶K3产品性能稳定性优化指导手册

1、.金蝶k/3产品性能稳定性优化指导手册；金蝶软件（中国）有限公司研发中心k/3设计部解释说明：本手册针对k/3v10.2 10.3sp版本编写，对k/3其他版本也有较好的试用性。1. 问题处理指引作为服务人员或实施人员，遇到客户的性能或稳定性问题时，请您不要着急。第一步：引导客户了解具体问题；第二步：核对问题并将问题的表象（参考完全版2.1；3.1；4.1）转换为问题的本质第三步：判断问题的根源，迅速定位、分析和解决问题。一般问题的处理步骤如下： 目录索引：2、数据库常见性能问题处理 22.1 数据库服务器硬件问题 2q2.1.1 数据库服务器cpu居高不下，持续100%以上 2

2、q2.1.2 数据库服务器cpu长期保持在40%以上 2q2.1.3 数据库服务器cpu耗用很低，但是系统整体性能很差，查询某些功能很慢 3q2.1.4 数据库耗用内存很大，是否是内存不够呢？内存应该如何配置？ 3q2.1.5 数据库服务器配置应该注意什么？ 32.2 数据库维护策略问题 3q2.2.1 k/3帐套数据库的维护策略 3q2.2.2 k/3帐套的事务日志文件过大或增长过快，导致系统运行缓慢 3q2.2.3 数据库优化需要注意什么，可以从哪些方面入手？ 4q2.2.4 k3帐套的数据文件大小不正常 42.3 数据库性能相关的其他一些问题 4q2.3.1 k/310.2以前版本使用数

3、据授权后f7、单据查看、序时簿查看、选单关联等速度很慢 4q2.3.2 供应链系统整体运行速度非常慢 43. 中间层性能和稳定性问题 53.1 中间层非com+性能优化 53.2 中间层com+问题 53.2.1 com+问题常见处理和优化方案 53.2.1.1 重装msdtc 53.2.1.2 配置线程 53.2.1.3 进程池配置（for win2003） 63.2.1.4 desktop heap设置 63.2.1.5 应用程序回收参数设置 73.2.1.6 msdtc超时设置 73.2.1.7 空闲等待时间设置 73.2.1.8 确保中间层组件编译参数的正确 73.2.1.9 更新服务

4、器环境 83.2.2 com+问题常用分析方法 83.2.2.1 排除法 83.2.2.2 信息收集综合分析法 84. 客户端性能问题 9q4.1 系统突然出现“调用程序忙，切换到”，“正在调用中间层”等提示 9q4.2 升级版本后某些客户端的速度比以往使用k/3慢一点 9q4.3 某些局部功能速度太慢 9q4.4 客户端出现automation 错误 10q4.5 如何查看具体哪个组件存在性能问题 10q4.6 关于趋势防火墙与k/3的冲突 10q4.7 少使用严重影响k/3系统性能的系统选项 11q4.8 建议客户端关闭消息功能或将刷新时间减小 112、数据库常见性能问题处理 2.1 数据

5、库服务器硬件问题q2.1.1 数据库服务器cpu居高不下，持续100%以上 当发现数据库服务器的cpu很长一段时间都是100%占用，首先确认是否为很少使用的计算功能或者是大数据量查询，还是日常业务功能；若为前者，建议适当安排系统空闲时间,尽量不要在业务高峰期运行；若为后者，请通过sql事件探查器跟踪执行时间较长的sql，对sql进行优化（参考完全版2.3 数据库表结构不合理），如果仍然不能解决，请将耗时比较长的sql发回研发中心进行分析和定位。q2.1.2 数据库服务器cpu长期保持在40%以上数据库服务器cpu长期保持在40%以上，系统的运行速度时快时慢，这表示cpu的负荷已经很重，建议升级

6、硬件，例如增加cpu个数。q2.1.3 数据库服务器cpu耗用很低，但是系统整体性能很差，查询某些功能很慢这种情况很可能是数据库发生阻塞，请参见完全版5.3 数据库阻塞监测工具得到阻塞情况。对执行结果进行分析并寻求解决方法，如果不能解决，请把结果保存为文件反馈到研发中心，研发人员会根据此结果进行处理。q2.1.4 数据库耗用内存很大，如果内存不够，应该如何配置？ 数据库服务器的内存只上升，不下降，不是我们的软件问题，而是sql server使用内存的策略造成，是正常现象，我们可以简单判断数据库服务器内存是否够用，在任务管理器中选择查看-显示内核时间，会显示一条红线，如果红线很高，证明大量的磁盘

7、读写操作，说明内存可能不够，需要大量的内存切换。我们的实施人员应该在实施准备阶段对用户未来的业务有一个估计，对用户数据量的估计可以作为配置服务器硬件的一个依据。数据量对数据库服务器的内存配置有直接的影响，从经验的数字来说最好是物理内存要大于账套的数据文件，如果账套数据文件小于1g，应该配置至少1g内存，如果账套数据文件大于1g,物理内存应该和数据文件大小相当，例如账套数据文件为2.4g,那么应该配置至少2-3g内存。配置3g内存需要启动3gb开关，参见完全版2.1.1.2。q2.1.5 数据库服务器配置应该注意什么？数据库服务器配置内容 建议使用配置操作系统 win2000 advanced

8、server或win2003sqlserver版本 sql server 2000 企业版sp3数据库服务器和中间层服务器部署 分别在两台机器上部署cpu配置 主频2g或以上内存配置 ecc内存2g或以上磁盘系统配置 scsi磁盘系统网卡配置 100m服务器专用网卡特别说明：sql server必需至少打sp3的补丁程序。2.2 数据库维护策略问题对于任何一个数据库系统，日常的维护是必要的，在日常的系统维护中分支机构应该引导客户的系统管理员做维护，防性能问题于未然。q2.2.1 k/3帐套数据库的维护策略1、数据库属性中故障还原模型使用“简单”模式（选择简单模式后数据库将不能做增量备份），取消

9、“自动收缩日志”选项。2、通过sql server企业管理器做一个收缩计划，在没有业务运行的时候定期收缩数据库，具体参见完全版2.1.2.2 定期收缩数据库。3、选择“账套管理” “数据库” “优化帐套”或在sql server企业管理器中做维护计划,使用企业管理器中管理数据库维护计划新建维护计划向导，在第三步，选择重新组织数据和索引页定时优化帐套。q2.2.2 k/3帐套的事务日志文件过大或增长过快，导致系统运行缓慢1、参照q2.2.1 k/3帐套数据库的维护策略设置好数据库维护策略。 2、数据库分离附加（采用日志分离的方式减少日志文件的大小：首先在sql server企业管理器分离数据库,

10、 然后删除此数据库的日志文件（*.ldf）,最后再重新附加数据库）3、检查二次开发的触发器和存储过程是否存在批量更新数据库不严谨造成日志文件增大（关键）。 4、执行“检查表的使用空间情况.sql”（具体sql文件见完全版2.2.1.1），核对一下是否有的表占用的空间过大没有释放，可以优化一下此表的索引结构，保存此表后可以把过多的空间释放出来。q2.2.3 数据库优化需要注意什么，可以从哪些方面入手？1、对二次开发的表注意建立索引，不要使用或少使用触发器和游标。2、通过使用sql server事件探查器和查询分析器，分析执行时间长的sql, 对于经常出现where子句中的字段为其建立索引，还有就

11、是观察表是否主要用于查询（select）的表，则索引可以尽量多建。3、对数据库中一些数据量较大的表（如t_voucher,t_voucherentry,t_balance,icstockbill,icstockbillentry等）可以在sql server中制作一个作业在系统空闲时定时进行重建索引，例如dbcc dbreindex（icstockbill）；dbcc dbreindex（icstockbillentry）2个sql进行出入库单据表的专门索引优化。q2.2.4 k/3帐套的数据文件大小不正常sql server的数据文件变得不正常，大小和客户的数据量从经验上很不相符，这种异常会

12、很大地影响系统性能，还有可能引发错误。1、参照q2.2.3 数据库优化需要注意什么，可以从哪些方面入手？优化数据库表结构。2、该问题主要是由于有些表没有建立聚集索引而引发，需要运行工具来分析检查然后建立索引。工具见完全版2.2.1.2 k3帐套的数据文件大小不正常。2.3 数据库性能相关的其他一些问题q2.3.1 k/310.2以前版本使用数据授权后f7、单据查看、序时簿查看、选单关联等速度很慢请参考完全版2.2.2.1 k/3数据授权导致f7、单据查看、序时簿查看、选单关联速度很慢做相应处理。q2.3.2 供应链系统整体运行速度非常慢1、参照q2.2.1 k/3帐套数据库的维护策略设置好数据

13、库维护策略。 2、对于查询比较慢的单据可以把sql跟踪出来，然后用查询分析器运行索引优化向导。序时簿相关关联表增加索引。3、对表icstockbill,icstockbillentry在sql server中制作一个作业在系统空闲时定时进行重建索引dbcc dbreindex（icstockbill）；dbcc breindex（icstockbillentry）。4、单据查询时，建议用户设置过滤条件进行查询，以提高查询效率，尽可能避免大数据量导致性能下降。修改序时簿的过滤条件，取消关联标志，钩稽标志等的显示，因为这里会耗时过多，特别是涉及到多单据的关联字段，尽量在序时簿里把不重要的字段可以不

14、显示。5、检查表t_locktable是否存在主键，如果没有，请设置finterid做为主键。6、执行“检查表的使用空间情况.sql”，核对一下是否有的表占用的空间过大没有释放，可以优化一下此表的索引结构，保存此表后可以把过多的空间释放出来，具体见2.2.3.2系统整体运行速度非常慢。7、考虑结转新账套。 8、考虑增加服务器配置。3. 中间层性能和稳定性问题3.1 中间层非com+性能优化1、若没有管理驾驶舱模块，请将中间层服务器上的apache tomcat服务停止。 2、若没有使用人力资源系统，请将中间层服务器上的hrjobprocess服务停止。方法同上。3、若没有使用远程传输系统（im

15、ts），请将中间层服务器上的kingdee imts service服务和kingdee imts event server停止，方法同上。4、域服务器、中间层服务器、数据库服务器分开部署。3.2 中间层com+问题3.2.1 com+问题常见处理和优化方案遇到相关中间层com+问题时，你可以尝试下面的解决方案看能否解决问题。3.2.1.1 重装msdtc方法：运行msdtc uninstall，然后重启，运行msdtc install重新安装说明：如果在日志中发现msdtc服务自动停止的情况，或者你的机器是克隆并出现事务无法提交，那么可以尝试重新安装msdtc。注意: 该操作需要重启电脑！3

16、.2.1.2 配置线程 方法：修改注册表，见完全版3.2.1.2 配置线程hkey_local_machinesoftwaremicrosoftcom3stathreadpoolvalue name: emulatemtsbehaviordata type: reg_dwordvalue data: 0x64让单个com+ vb组件同时服务最多100个线程，以提高处理并发请求的数量。说明：windows启动的每个进程，所允许的sta线程数，一般为7+cpu个数，默认最大为10*cpu个数，当并发用户较多时，在一个进程池内组件的线程数量超过此数值时，组件的调用会发生阻塞，也容易导致组件崩溃，这也

17、是产生“com+ 4689错误: 运行时环境检测到其内部状态存在不一致。这说明进程中存在潜在的不稳定性，可能是由于 com+ 应用程序中运行自定义组件、com+ 应用程序使用的组件或其他因素引起的。d:srv03rtmcomcomplussrccomsvcsthreadsstathreadpool.cpp（1223）中的错误，hr = 8000ffff: cstathreadpool: unable to get bind thread.”的原因。由于vb组件对多线程支持较差，所以需要通过修改注册表，增加最大线程数，来解决此问题。注意：改完注册表需要重启机器才能生效。3.2.1.3 进程池配置

18、（for win2003）方法：选择“管理工具-组件服务-计算机-我的电脑-com+应用程序”下某个应用程序包，单击右键，选“属性”菜单，进入界面后选“共用与回收”标签页，更改“池大小”。根据目前中间层服务器的配置情况和软件的实际情况，对于大多数组件建议设置为1，对于ebok3等应用极其频繁的组件可根据其线程数增大进程池数目。例如对于像ebosystem、ebopublic这样应用比较频繁的组件设置为2，对于ebok3应用极其频繁的组件设置为3-5。说明：windows允许为每个com+包的组件开辟多个进程池，这样就可以将该组件的线程分散到不同的进程池中，有利于系统调度，减少进程的阻塞，提高系

19、统服务性能。注意：在资源cpu、memoey许可的情况下，理论上进程池数量越大越好，但其受系统核心的desktop heap的限制，进程数不能无限加大，如果过大，可能导致desktop heap不足，引发组件创建失败错误。为了发挥最佳性能，必须根据com+组件应用的情况，合理设置每个com+包的进程数。3.2.1.4 desktop heap设置方法：扩大desktop heap以增加创建apartment的个数。a）hkey_local_machinesystemcurrentcontrolsetcontrolsession managermemory managementsessionvi

20、ewsize缺省是48m, 是系统范围的desktop heap 的大小,将sessionviewsize改成96m来增加整个系统范围内的desktop heap的大小。b）hkey_local_machinesystemcurrentcontrolsetcontrolsessionmanagersubsystemswindow的值:%systemroot%system32csrss.exeobjectdirectory=windows sharedsection=1024,3072,512 . . . . . .1024, 3072, 512 是default setting, 将512改成

21、4096, 以增加可创建窗口的数量。说明：每个系统desktop对象都有heap 与之对应，desktop对象使用heap（堆）存储菜单、字符串和窗体等。系统从核心缓存（48m）中分配desktop heap。一个windows操作系统可以有多个desktop heap。因为在非交互式工作站下，scm为一个用户账号的每一个服务进程创建一个新的desktop，较大的desktop heap值将减少此系统可以服务的用户账号数量。全部的desktop heap 必须适应于48m系统范围的缓存。当发生组件创建失败/超出内存的错误时，可以适当加大这些键值，如将sharedsection=1024,307

22、2,512的三个数字改为2048,3072, 2048。3.2.1.5 应用程序回收参数设置方法：选择“管理工具-组件服务-计算机-我的电脑-com+应用程序”下某个应用程序包，单击右键，选“属性”菜单，进入界面后选“共用与回收”标签页，设置应用程序回收使用默认。说明：应用程序回收中的参数意义：生存时间限制表示组件从创建到销毁的时间，默认为0，即按照组件自身的生命周期存活；内存限制表示com+占用的最大内存数，一旦实际占用达到此限制，系统会自动销毁一些组件，在确认使用情况的前提下，可以根据机器配置设置此值；过期超时表示在组件销毁时因为尚在激活状态或其他原因，不能立即销毁情况下等待的最大时间，默

23、认为15分钟；调用限制/激活限制表示允许的最大调用/激活进程数，建议使用默认值0。注意：合理设置lifetime limit的值对解决数据库的死锁有一定帮助，但其值不要设置太短，否则会导致com+ runtime频繁关闭和启动dllhost进程，增加系统的资源压力。3.2.1.6 msdtc超时设置方法：选择“管理工具-组件服务-计算机-我的电脑”，单击右键，选“属性”菜单，进入界面后选“选项”标签页，设置事务超时。设置时可以根据目前的事务性能日志例如在118s左右，因此可以设置为120s。说明：msdtc超时时间表示分布式事务的提交时间，与数据库访问事务有密切关系，优先级低于数据库的超时设置

24、,分布式事务如超过此时间将中止。此时间需要根据事务的平均耗时来设置，设置过大容易导致数据库产生死锁，过小会使一些耗时较长的事务不能提交，使一些长事务被频繁的kill,导致客户端业务不能正常完成。增大transaction timeout值可以减少保存数据引起过多的失败操作。3.2.1.7 空闲等待时间设置方法：选择“管理工具-组件服务-计算机-我的电脑-com+应用程序”下某个应用程序包，单击右键，选“属性”菜单，进入界面后选“高级”标签页，设置空闲等待时间。此参数与上述回收参数设置的生存时间限制参数综合作用，协调处理组件的销毁工作；需要根据客户用户数量与频繁调用状况来决定。说明：空闲等待时间

25、表示一个进程在空闲状态时的等待时间，超过此时间则会进行销毁，此时间需根据组件调用情况合理设置，设置过长将导致组件进程不能及时释放，设置过短将导致组件频繁销毁创建。注意：该参数不能设置太大，以尽量减少空闲进程对系统资源的占有。3.2.1.8 确保中间层组件编译参数的正确方法：使用工具完全版5.8 vbcheckw2k进行检查，对没有选中unattended execution和remained in memory选项进行编译的中间层组件重新编译（主要指二次开发组件）。说明：如果中间层没有选中unattended execution和remained in memory选项进行编译，运行com+组

26、件会导致com+的不稳定，甚至导致内存泄露，因而对中间层组件要求编译时参照下面要求进行编译：general页面1.unattended execution 必选2.upgrade activex controls 必选3.retained in memory 必选4.threading mode :选apartment threaded3.2.1.9 更新服务器环境方法：此部分主要是更新com+应用服务器的环境，保证服务器的稳定，主要包括1、服务器端使用最新的vb运行时文件。安装最新的vb sp6 runtime,将msvbvm60.dll从版本96.90升级到版本97.82。2、升级操作系统

27、到最新的service pack，win2000请打sp4，win2003请打sp1。3、升级mdac到最高版本。3.2.2 com+问题常用分析方法3.2.2.1 排除法com+挂起、死琐和异常问题一般可以从数据库,系统环境和组件本身出发进行分析，通过逐个排除来定位问题具体在数据库、系统环境还是组件本身。1、对数据库我们可以通过sp_lock和select * from sysprocesses 查看是否有死琐,通过 kill spid结束死琐；2、对于系统环境和组件本身，我们可以创建一个简单的测试组件进行测试，如果简单的组件也出问题，该问题很可能是由于环境导致的，否则，是代码导致的。3、对

28、于环境问题，我们可以通过方法3.2.1.2 配置线程修改diihost的max thread来看是否是由于线程限制引起，如果是我们可以更改加大diihost的max thread，同时了解系统是否克隆，系统的事务处理是否出问题，如果是可以通过3.2.1.1的方法重新安装msdtc看问题能否解决，甚至我们可以尝试重新安装操作系统来解决。同时，还可以检查下面一些因素:防毒程序，注册表，用户权限，网络连接情况。我们还可以通过一些工具，比如filemon来检视问题发生时候文件访问情况，看看有没有什么异常。4、对于代码问题，我们可以通过记录log文件来跟踪死锁发生在什么方法上，看是在哪一行发生了错误，错

29、误代码是什么，然后尽可能简化该方法来找到问题的根源。how to create error handlers in visual basic com components 5、如果问题不是每次都发生，我们需要在问题发生后抓dump文件，也就是相关进程的内存镜像来分析，分析方法见完全版3.2.3 com+分类分析和处理方法。3.2.2.2 信息收集综合分析法发生com+问题后，如果我们很难确定发生问题的原因，我们可以收集下面的信息，然后综合收集的信息综合分析，看问题的根源是在哪一部分。1、根据日志收集com+错误信息，根据com+错误信息分析和处理问题2、根据应用程序id，定位到具体的com+组

30、件和类上，查看相关的组件和类运行是否正常，是否能正确被创建和实例化。3、收集desktop heap内存消耗情况，如果消耗太大可以参照3.2.1.4 desktop heap设置处理。收集方法见完全版3.2.2.2 信息收集综合分析法。4、收集进程池数，线程数，看设置是否合理。5、收集事务并发数量，最长事务执行时间。6、收集站点并发数量。7、检查vb组件编译设置，见3.2.1.8。8、收集内存/cpu信息，看是否存在性能或内存泄露问题。9、收集数据库大小，索引信息，表的大小，看是否数据库存在瓶颈。10、设置debugbreakonfailfast为y，收集相关信息，然后设置为n当com+发生异

31、常时会弹出提示，这是可以抓一个完整的com+dump文件进行问题的分析和处理，dump分析见完全版3.2.3 com+分类分析和处理方法。how to obtain a userdump when com+ failfasts 11、com+ catalog dump，见完全版3.2.3 com+分类分析和处理方法。12、参照3.2.1.9确保环境的正确。13、通过性能日志查看系统性能情况。14、抓dump文件分析，见完全版3.2.3 com+分类分析和处理方法。4. 客户端性能问题q4.1 系统突然出现“调用程序忙，切换到”，“正在调用中间层”等提示（1）首先有可能网络中断或者不稳定，这种情

32、况，一般客户端报告明显的网络错误；（2）如果网络畅通，有可能是网络中ip地址和计算机名称的不匹配。确保在hosts文件中记录的ip地址和计算机名称相匹配，保证地址解析的正确性。如果不匹配就会造成在客户端报一个“定义的应用程序和对象错误”等的错误。（3）如果客户端提示“调用程序忙，切换到”，“正在调用中间层”等提示，需要分析是数据库还是中间层存瓶颈，对数据库第一种原因是服务器硬件资源不足，注意观察数据库服务器的cpu表现，如果cpu资源长期达到40%以上，这表明cpu资源已经严重不足，如果cpu达到100%,则是某一个功能独占了数据库服务器cpu资源；第二种原因是数据库阻塞，此时数据库数服务器c

33、pu耗用很低，但是整体性能很差。对中间层可以查看com+是否出现问题，参见中间层问题部分进行处理。（4）如果是中间层com+出现问题，请参考完全版第3章中间层com+问题进行处理。q4.2 升级版本后某些客户端的速度比以往使用k/3慢一点大多数是客户端的硬件配置可能偏低，而且使用了win98操作系统，建议客户适当升级客户端的硬件配置，使用win 2000 professional操作系统，或者建议客户把使用频繁的k/3客户端作较好的配置，在不增加硬件的情况下对已有的pc做调剂。同时，告诉客户k/3系统之所以可能比他们以前用的小系统慢，是因为功能的复杂性，如提供了并发控制的网络控制和严密的授权逻辑。重要的是能够满足客户的日常业务。硬件配置建议客户端cpu主频2g或以上，内存至少256兆（推荐512兆）q4.3 某些局部功能速度太慢此部分主要是指下面典型案例存在性能问题：； 计算类期末结账，mrp运算,凭证生成，成本计算； 查询类报表（物料收发汇总表），序时簿； 日常票据处理业务1、寻求技术