金蝶K3产品性能稳定性案例集 - 图文

金蝶K/3产品性能稳定性案例集

金蝶K/3产品性能稳定性案例集

?金蝶软件(中国)有限公司K/3产品事业部.设计部解释

目的

本案例集是我们在处理K/3系统应用过程中遇到性能问题的解决方法与方案总结,旨在帮助技术支持人员、分支机构实施服务人员以及客户更快速解决相关性能问题；同时也指导我们的实施服务人员和客户在实施中如何预防和避免将来可能发生的性能稳定性问题。

适合对象

本案例集的主要阅读对象是K/3系统研发人员、技术支持人员、实施人员、客户服务人员和公司授权的有一定技术能力的客户系统管理员。 导读

本案例集首先是按照网络、数据库、中间层、客户端层次来介绍实际遇到的通用案例,包括问题的描述,分析以及解决方案，接着以K/3产品发展的主线分版本来列举对应的案例以及处理方案，请您根据您的需要选择相应的章节阅读。

注意:由于此案例集可能牵涉一些K/3在技术方面的细节，为了防止有些人用意不良，断章取义来攻击K/3产品和公司，请注意保密。

金蝶K/3产品性能稳定性案例集

目录

1. 性能案例总体分析步骤 ............................................... 1 2. 总体通用性能问题案例 ............................................... 3

2.1 网络与Citrix性能问题案例 .................................................................................. 3

2.1.1 通用案例1—-网络架构问题 ..................................................................... 3 2.1.2 通用案例2—-病毒导致网络问题 ............................................................. 3 2.1.3 通用案例3—-Citrix服务端内存问题 ....................................................... 3 2.1.4 通用案例4—-应用Citrix打印问题 .......................................................... 4 2.2 数据库性能问题案例 ............................................................................................. 6

2.2.1 通用案例1—-数据库日志文件过大 ......................................................... 6 2.2.2 通用案例2—-数据文件大小不正常 ......................................................... 6 2.2.3 通用案例3—-Tempdb日志过大 ............................................................... 7 2.2.4 通用案例4—-数据库服务器硬件问题 ..................................................... 7 2.2.5 通用案例5—-系统整体运行速度非常慢 ................................................. 9 2.3中间层COM+性能问题案例 ................................................................................ 10

2.3.1 通用案例1—-COM+挂起 ........................................................................ 10 2.3.2 通用案例2—-COM+配置/环境的问题 ................................................... 12 2.3.3 通用案例3—- CPU100% ......................................................................... 23 2.3.4 通用案例4—-COM+性能问题 ................................................................ 23 2.3.5 通用案例5—-COM+安全性的问题 ........................................................ 24 2.3.6 通用案例6—-COM+其他的问题 ............................................................ 25 2.4 客户端性能问题案例 ........................................................................................... 28

2.4.1 通用案例1—-客户端突然出现全面的死机现象 ................................... 28 2.4.2 通用案例2—-客户端出现“新事务不能登记到指定的事务处理器中” .............................................................................................................................. 29 2.4.3 通用案例3—-USER组用户权限问题 .................................................... 32

3.各历史版本性能问题案例 ............................................. 33

3.1. K/3V9.1性能问题案例 ......................................................................................... 33

3.1.1在打开往来对帐时速度非常慢,服务器CPU占用100%. ....................... 33 3.2. K/3V10.0性能问题案例 ....................................................................................... 33

3.2.1 K/3数据授权导致F7、单据查看、序时簿查看、选单关联速度很慢(工业类型账套) ......................................................................................................... 33 3.2.2出入库单据丟失 ........................................................................................ 34 3.2.3应收冲应付的单据生成凭证时导致数据库服务器死锁 ......................... 34 3.3. K/3V10.1性能问题案例 ....................................................................................... 34

3.3.1 K/3数据授权导致F7、单据查看、序时簿查看、选单关联速度很慢(工业类型账套) ......................................................................................................... 35 3.3.2凭证录入性能问题 .................................................................................... 36 3.3.3报表查询时数据库服务器CPU占用100%............................................. 36 3.3.4进行匹配内部往来机构时速度特别慢 ..................................................... 36 3.3.5采购订单执行情况汇总表和采购订单执行情况明细表查询慢 ............. 36 3.3.6采购收货单序时簿查询慢、销售发票序时簿慢的问题（商业类型账套） .............................................................................................................................. 37

金蝶K/3产品性能稳定性案例集

3.3.7销售发票生成凭证慢的问题（商业类型账套） ..................................... 37 3.4. K/3V10.2性能问题案例 ....................................................................................... 37

3.4.7物料需求计划性能优化 ............................................................................ 42 3.4.8员工异动、入职、工资导入性能慢 ......................................................... 42 3.5. K/3V10.3性能问题案例 ....................................................................................... 42

3.5.1 单据上下查功能 ....................................................................................... 42 3.5.2启用折扣管理后性能不理想 .................................................................... 43 3.6. K/3V10.4性能问题案例 ....................................................................................... 43

3.6.1 信用管理不能启用 ................................................................................... 43 3.6.2 进出口、应收应付某些BOS单据加载、保存、F7多选返回时速度很慢 .......................................................................................................................... 43

金蝶K/3产品性能稳定性案例集

1. 性能案例总体分析步骤

作为服务人员或实施人员，遇到客户的性能或稳定性问题时，请您不要着急, 可参考如下步骤:

第一步：引导客户了解具体问题； 第二步：收集用户计算机信息；

自动收集服务器的事件日志，系统配置环境，操作系统版本等信息。对与中间层服务器使用MPSRPT_Alliance_X86.EXE，对于数据库服务器使用MPSRPT_SQL.exe

工具位置：

MPSRPT_Alliance_X86.exe：

http://www.microsoft.com/downloads/details.aspx?familyid=cebf3c7c-7ca5-408f-88b7-f9c79b7306c0&displaylang=en； MPSRPT_SQL.exe：

http://download.microsoft.com/download/b/b/1/bb139fcb-4aac-4fe5-a579-30b0bd915706

如果现场问题需要总部支持的话，请使用上面的工具收集计算机的信息。

MPSRPT_SQL.exe 运行后：将会生成CAB文件，CAB会被生成在%systemroot%\\MPSReports\\SQLServer\\\\Cab目录。通常名字为%COMPUTERNAME%_SQL_MPSReports_XXXXXXXXXX_X.CAB。 (%systemroot%为Windows系统目录，比如C:\\Windows or C:\\Winnt)

第三步：判断是否网络问题，网络是否丢包等；由于病毒也是导致网络不稳定的一个

原因，所以需要确定是否存在病毒；

建议:网络推荐至少百兆网，全交换更好，推荐采用域结构，域服务器不要跟K/3服务器装在一起。关于客户端和中间层不在同一域的问题，最好是配置客户端和中间层在同一域中，如果无法配置在同一域中。可以修改组件服务中COM+组件的安全验证选项，如下图所示。降低身份验证级别，能够在一定程度上改善调用中间层组件的性能。

1

金蝶K/3产品性能稳定性案例集

附丢包率判断方法：

丢包率 通过客户端192.168.1.205,对中间层192.168.1.2,做如下操作: (1) ping 192.168.1.2 –n 1000 –l 2000 (2) pathping 192.168.1.2 (1)time<1ms,sent=1000,received=999,lost=1(0%loss),Min=0ms,Max=9ms,Average=0ms (2)for 25 second statistics中, Pct=Lost/Sent=0% 即:无丢包,丢包率0%. 第四步：检查用户操作系统，如果是WINDOWS2003是否安装SP1,SQL2000是否打上SP4,

请参照文档：

第五步：定期维护和优化帐套，具体参见《金蝶K/3产品性能稳定性优化指导手册》。 第六步：数据库表结构不合理，常见有：

? 二次开发的表没有索引,造成性能隐患；

? 不恰当的触发器和游标的使用，大数据表缺少聚集索引。

第七步：寻找合适的补丁。

第八步：与K/3开发部沟通，获得解决方案。

2

金蝶K/3产品性能稳定性案例集

2. 总体通用性能问题案例

本章主要对目前K/3系统在实际运行过程中遇到的一些通用性能案例进行介绍分析, 具体内容按照网络、数据库、中间层、客户端层次结构来组织。 2.1 网络与Citrix性能问题案例

2.1.1 通用案例1—-网络架构问题 1、问题描述：

使用某一台交换机的所有使用K/3的机器（该交换机为第三级），出现客户端挂起的情况，K/3系统使用不稳定。 2、问题分析：

1) 将出现问题的客户端机器的网线拔掉，过5-10秒再重新插入后，系统挂起现象

解决，K/3可以正常使用；

2) 通过PING xxx.xxx.xxx.xxx –l 1024 –n 100 后，发现统计信息中存在丢包的

现象；

3) 接到另外一台交换机（该交换机为第一级）上后，发现K/3系统使用稳定，但总

体性能下降，分析原因为网线的距离过长，从而导致了数据传输上的损失 3、解决方法：

重新部署网络架构

2.1.2 通用案例2—-病毒导致网络问题 1、问题描述：

所有机器使用K/3同一个功能时，快的时候6-7秒，慢的时候要1分多钟（已经排除数据量和查询数据范围的问题）。 2、问题分析：

客户端网络使用光纤接入，使用PING xxx.xxx.xxx.xxx –l 1024 –n 100检查，发现都存在丢包的现象，但如果整个网络只存在一台计算机时，系统使用正常。怀疑是病毒原因。使用杀毒软件进行杀毒后，发现有多台客户端有病毒。由于感染病毒后会疯狂发包，导致路由器NAT连接很快占满，从而导致性能问题。 3、解决方法：

丢包掉线可能原因：

1) 局域网中的某台或者多台机器感染了病毒，在疯狂发包，导致路由器NAT连接很

快占满。

建议方案：试着断开某台交换机，进行逐一排查，进行隔离杀毒，找到该台机器，将其隔离。

2) 可能是交换机长时间没有重启其内存已用光，导致交换数据速度缓慢，或受网络

风暴影响导致阻塞或交换机的某一个或几个接口模块损坏，或交换机故障引发的网络内暴。

建议方案：关闭局域网内所有交换机4-5分钟后，重新接通电源，观察网络是否 恢复正常。

2.1.3 通用案例3—-Citrix服务端内存问题

3

金蝶K/3产品性能稳定性案例集

1、问题描述：

某集团在培训练习过程中（同时登陆的有40台机器,使用的CITRIX 登陆），发现系统使用速度非常慢，在一段时间不操作机器的情况下，K/3客户端会报错误，后自动退出。

服务器配置为：CPU 为Xeon 5160 双核3.0G,内存为1GB，Citrix服务端耗用内存2GB多。 2、问题分析：

一般去除操作系统和Citrix服务器的的消耗，每个Citrix K/3客户端大概耗用50兆左右内存。因此对于30个客户端的并发，可能需要30*50 + 500(操作系统和Citrix服务器的消耗) = 2000 (M)的内存。如果内存不足时，操作系统将会自动进行换页处理，这时需要空余的磁盘空间作为交换文件，但也会极大影响程序的性能。 3、解决方法：

增加服务器内存(建议加到4GB) 。

2.1.4 通用案例4—-应用Citrix打印问题 1、问题描述：

某客户在应用CITRIX进行K/3应用的过程中存在下面问题： 问题一：打印的单据打印到了别的客户端的打印机上

问题二：HP 1020,1000 等USB打印机在CITRIX 模式不能正常打印，但在微软终端模式下一切正常

问题三：在服务器和客户端都设好缺省纸张，但在打印时仍然报纸张错误。 2、问题分析：

问题一：Citrix在每台客户端打印机前面都会加//clinet_name/Printer_name来区分各不同的打印机，所以实际上这些打印机是分得清楚的，即使是相同型号的打印机，由于使用了这种长串识别，也是不可能完全相同的。目前碰到最多的串打问题，是客户自己在使用时分不清楚哪台是自己的打印机，所以会打错。解决该问题的最佳方法，就是将客户端用户降为Users组成员，这样他将无法看到其它客户端连接上来的打印机，也就不会发生串打了。

问题二：经跟踪分析与打印机的启用双向支持有关，需要进行相关的设置，见解决方法。

问题三：在Citrix里可以设置延用客户端打印机设置，即在客户端本地设置的打印机属性，连接Citrix服务器后，打印时可以延用该属性设置。在K/3V10.2以后的版本，K/3已经实现按用户来记录不同的打印设置，该问题可以得到解决。 3、解决方法：

问题一：Citrix串打问题。将客户端用户设为USER用户，运行Regedt32在权限管理中对下面注册表项赋予USER组完全控制的权限:

HKEY_LOCAL_MACHINE\\SOFTWARE HKEY_CLASSES_ROOT\\AppID

HKEY_CLASSES_ROOT\\KdSvrmgr.clsAct

对于Win2003， 可以直接使用Regedit进行权限授予，对于Win2000及以前，必须使用Regedt32.

问题二：USB打印机问题。在CITRIX模式下HP1020打印机打印不正常，主要表现是映射正常，打印数据文件也能正常传输到客户端，但在客户端的打印任务管理器始终不打印，端口也正常映射到USB口。但在WINDOWS终端模式下打印正常，在CITRIX

4

金蝶K/3产品性能稳定性案例集

终端GUI与WEB模式都不能打印。

在服务器上安装HP1020打印驱动，如下图配置：

在客户端按上设置即可，重新登陆.

问题三：缺省纸张的问题。

1) 必须使用本地打印驱动，即在服务器上安装客户端打印机的驱动，而不是使用通

用驱动打印。Management Console—>Printer Management—>Properties—>Drivers—>Native Drivers only(如无特殊打印机最好选择此项)，缺省为： Use universal driver onlyif native driver unavailab

5

金蝶K/3产品性能稳定性案例集

2) 启用设置套打格式。

3) 纸张的设置可在客户端的打印机上设置。请检查以下设置：Management Console

——>Printer Management——>Properties——>Printers——>inherit client printer's setting for keeping printered documents是否勾选？选择该项，可延用客户端的打印设置。

2.2 数据库性能问题案例

2.2.1 通用案例1—-数据库日志文件过大 1、问题描述：

客户数据库的LOG文件非常大，达到680M（实体文件是2.6G左右），做过数据库压缩、数据库剥离，重新建了日志文件后速度变快，如此反复了两次，现在又慢了下来。导致客户端运行速度非常慢，严重时连一个客户端都进不去。

2、问题分析：

该问题是由于没有把数据库的故障还原设置为简单，导致数据库LOG文件很大，影响数据库性能，可以对数据库做一些优化设置来处理。

3、解决方法：

1) 把数据库的故障还原设置为“简单”(注意:该故障还原模式下数据库不能进行事

务日志备份)。 2) 数据库分离附加〔采用日志分离的方式减少日志文件的大小：首先在“SQL SERVER

企业管理器”分离数据库, 然后删除此数据库的日志文件(*.ldf),最后再重新附加数据库〕。

3) 数据库收缩（在数据库服务器进行数据库实体收缩）。

4) 检查二次开发的触发器和存储过程是否存在批量更新数据库不严谨造成日志文

件增大（关键）。

5) 执行下面附件的SQL，核对一下是否有的表占用的空间过大没有释放，可以优化

一下此表的索引结构，保存此表后可以把过多的空间释放出来。

2.2.2 通用案例2—-数据文件大小不正常 1、问题描述：

SQL Server的数据文件变得不正常，大小和客户的数据量从经验上很不相符，这种异常会很大地影响系统性能，还有可能引发错误。 2、问题分析：

该问题主要是由于有些表没有建立聚集索引引发，需要运行工具来分析检查。 3、解决方法：

运行下面工具：

6

金蝶K/3产品性能稳定性案例集

它可以生成一个EXCEL表格K/3DATA.xls，记载了数据库中所有表的使用空间大小，重点关注Reserved, Unused列，如果发现与记录数应有的数据量有很大的差异，可以看看这些表是否有聚集索引，如果没有,则建立聚集索引，收缩数据库，数据库的数据文件会缩小很多。注意:此工具需要在安装有K/3客户端的机器上运行。

2.2.3 通用案例3—-Tempdb日志过大 1、问题描述：

Tempdb数据库文件出现大幅度增长，甚至达到3-4GB，从而导致K/3整体功能下

降

2、问题分析：

SQL Server 2000对于TempDB的处理是采用SQL Server Cache Buffer Manager来管理，而不再是象SQL Server 7.0一样可以使用TempDB In RAM的，这样，在高并发情况下，由于SQL Server的后台进程不能及时调度，造成TempDB的容量迅速增大（由初始的8MB增长到性能测试时的800MB），从而导致 Cache Hit Ration迅速下降造成对TempDB的 Pages Reads/Sec和Pages Writes/Sec狂飙造成的。

TEMPDB增长的同时也会导致内存使用的增长，由于内存以及物理空间的资源使用，从而导致系统的整体性能下降。

3、解决方法：

收缩TEMPDB数据库，可以采用下面几种方式，最好做一个定期执行计划 方法一

? 重启SQL SERVER服务

? ALTER DATABASE tempdb MODIFY FILE (NAME = 'tempdev', SIZE = 需

要收缩的大小)

? ALTER DATABASE tempdb MODIFY FILE (NAME = 'templog', SIZE =需

要收缩的大小)

方法二

? sp_spaceused @updateusage=true

? dbcc shrinkdatabase (tempdb, '百分比') 方法三

? dbcc shrinkfile (tempdev, '需要收缩的大小') ? dbcc shrinkfile (templog, '需要收缩的大小')

4、建议

1) 将tempdb 数据库文件的初始大小设置为合理的大小，以避免当需要更多空间时

文件自动扩展。如果tempdb 数据库扩展得过于频繁，性能会受不良影响。 2) 如果需要使用数据库文件按百分比增长，将文件增长增量百分比设置为合理的大

小，以避免 tempdb 数据库文件按太小的值增长。如果文件增长幅度与写入 tempdb 数据库的数据量相比太小，则 tempdb 数据库可能需要始终扩展，因而将妨害性能。

3) 最好设置数据库文件的增长方式为按指定的字节数方式，建议设置为200MB。 4) 将 tempdb 数据库放在快速 I/O 子系统上以确保好的性能。在多个磁盘上条带

化 tempdb 数据库以获得更好的性能。使用文件组将 tempdb 数据库放在除用户数据库所使用的磁盘之外的磁盘上。

2.2.4 通用案例4—-数据库服务器硬件问题

7

金蝶K/3产品性能稳定性案例集

1、问题描述：

物流的出入库单据都不能保存。 2、问题分析：

根据现场描述的情况，进行同样的操作，发现业务能正常处理，怀疑数据库服务器存在问题，让现场提供数据库服务器的事件日志和数据库日志，发现存在下面的错误信息。

事件日志： Envet id:17055 Envet id:17052

错误: 823，严重度: 24，状态: 2

I/O error (bad page ID) detected during read at offset

0x0000000224a000 in file 'E:\\DataBase\\AIS20050529165714_Data.mdf'. Event id:19011

SuperSocket 信息: ConnectionListen(Shared-Memory (LPC)) : Error 5。 事件 ID ( 4194 )的描述(在资源( COM+ )中)无法找到。本地计算机可能没有必要的注册信息或消息 DLL 文件来从远程计算机显示消息。您可能可以使用 /AUXSOURCE= 标识来检索词描述；查看帮助和支持以了解详细信息。下列信息是事件的一部分:

组件 Prog ID: 服务器应用程序 ID: {DAE39E2A-3C8D-49DC-9BFB-1611078F4940}服务器应用程序名称: eboK/3

该错误的严重性已导致进程终止。 异常: C0000005 地址: 0x6A388318 调用堆栈: ,

MSVBVM60!__vbaVarDup + 0x6C4E OLEAUT32!DispCallFunc + 0x15D

MSVBVM60!BASIC_CLASS_Invoke + 0x259 MSVBVM60!BASIC_CLASS_Invoke + 0x52

OLEAUT32!UserEXCEPINFO_free_local + 0x57D

Envet id :4193 Source:msdtc

资源管理器执行了恢复操作并调用了 ReenlistmentComplete，说明恢复过程已完成。 但至少一个通过资源管理器登记的事务的状态仍然是“不确定”

数据库：

2006-03-17 08:53:28.64 spid16 表错误: 对象 ID 1384001053，索引 ID 0，页 (1:41775)。测试（IS_ON (BUF_IOERR, bp->bstat) && bp

2006-03-17 08:53:28.64 spid16 表错误: 对象 ID 1384001053，索引 ID 0，页 (1:41775)。测试（IS_ON (BUF_IOERR, bp->bstat) && bp

2006-03-17 08:53:28.65 spid16 表错误: IAM 页 (1:41775)（对象 ID 1384001053，索引 ID 0）超出了此数据库的范围。 使用DBCC CHECKDB出现下面信息：

2006-03-17 12:57:55.95 spid15 表错误: 分配页 (0:67108864) 的

8

金蝶K/3产品性能稳定性案例集

IAM_PAGE 页首结构值无效。类型为 0。请检查该页上的类型、对象 ID 和页 ID。 3、解决方法：

根据上面的日志，查看微软网站相应的说明，由于使用DBCC CHECKDB存在无法修复的情况，这种情况可以排除是数据系统本身的原因，因为在硬件系统方面。建议客户将服务给硬件提供商检查，检查后发现导致该问题的原因在于硬盘系统存在问题。 微软网站关于错误的说明文档见：

http://support.microsoft.com/default.aspx?scid=kb;en-us;828339

http://support.microsoft.com/kb/q221926/

2.2.5 通用案例5—-系统整体运行速度非常慢 1、问题描述：

客户反馈，当前网速为10M，整体系统运行速度非常慢，例如审核一张单据，从查到该单据，到审核完毕，时间在5分钟左右才可以完成，中间仍会经常断掉，需要重新登陆，已经制约了部分业务的进行。 2、问题分析：

1) K/3系统数据全部都在一个数据库中，长期以来，积累了大量的数据，包括：仓

存管理业务数据、作业成本数据、财务数据等等信息，都在里面长期存放，目前数据库已有8G（包括日志文件）；

2) 网速目前为10M，可能对此有部分影响，但已满足系统运行要求；

3) 作业成本的数据表设计是否存在性能问题，账套一直在无限地增加数据量，这里

讨论是一种加速度的增加，即每年账套数据量增加呈递增状。 3、解决方法：

1) 请事先备份好数据（如果数据是完全备份，不是增量备份和日志备份），再把数

据库属性在企业管理器里的故障还原设置为“简单”； 2) 执行【BACKUP LOG 数据库名 with nolog】 截断日志； 3) 打开“企业管理器”点击右键－>所有任务－>收缩数据库；

4) 在中间层优化账套（打开“账套管理”－>数据库－>优化账套）,或者通过建立

索引维护计划进行优化账套；

5) 用户操作建议:单据查询时，设置精确的过滤条件，以提高查询效率，尽可能避

免由于大数据量的读取IO操作导致性能下降；修改序时簿的过滤条件，取消关联标志，钩稽标志等的显示，因为这块耗时过多，特别是涉及到多单据的关联字段；尽量在序时簿里把不重要的字段隐藏不显示。；

6) 检查表t_locktable是否存在主键，如果没有，请设置FinterID做为主键； 7) 执行下面附件的SQL，核对一下是否有的表占用的空间过大没有释放，可以优化

一下该类表的索引结构，把过多的空间释放出来；

8) 对于查询比较慢的单据可以把SQL跟踪出来，然后用查询分析器运行索引优化向

导，序时簿相关关联表增加索引； 9) 考虑结转新账套；

10) 增加数据库服务器硬件配置。

9

金蝶K/3产品性能稳定性案例集

2.3中间层COM+性能问题案例

2.3.1 通用案例1—-COM+挂起

2.3.1.1 K/3在WIN2KSRV客户端+WIN2KSRV服务器运行环境下MTS事务不能提交,出现挂起 1、问题描述：

K/3在WIN2KSRV客户端+WIN2KSRV服务器运行环境下MTS事务不能提交,出现组件挂起。COM+中组件的调用时间不断增加，客户端提示“正在调用中间层”。

组件服务图如下所示：

客户端提示：

2、应用环境：

WIN2KSRV客户端+WIN2KSRV服务器

3、问题分析：

问题出现后，首先通过各种测试对问题进行排查和分析，包括：

1) 通过sp_lock以及use master select * from sysprocesses查询，发现数据库

并没有出现阻塞；

2) COM+中有事务的组件出现挂起，调用时间不断增加； 3) 编写程序通过连接串连接数据库没有问题；

10

金蝶K/3产品性能稳定性案例集

4) 中间层组件能够被成功创建；

5) 编写程序直接通过中间层组件取数没有问题；

6) 通过中间层创建中间层调用时出现\正在调用中间层\，发生挂起，测试代码说明

如下：

对问题进行排查后发现通过中间层创建中间层调用时出现挂起，但其他环境应用并没有此问题，因而初步确定应该是环境问题，通过尝试修改DIIHOST的MAX THREAD依然没有效果。

进一步了解后得知机器是克隆的，由于MSDTC协调器都有一个GUID唯一标识，但是克隆机器也把GUID同时克隆了，这样在网络中找到两个同一标识的MSDTC服务器，从而导致出现问题，引起事务提交没有反映，出现挂起现象。通过咨询微软专家建议不要使用克隆机器应用于生产环境中，建议完全安装服务器进行测试。可以使用DTCPING.exe进行排查，来检查GUID是否一样。 工具地址：

http://www.microsoft.com/downloads/thankyou.aspx?familyId=5e325025-4dcd-4658-a549-1d549ac17644&displayLang=en

4、解决方案：

重新安装MSDTC

1) 卸载：运行msdtc –uninstall，重启； 2) 安装：msdtc –install，问题解决。

注意：请不要使用克隆的机器做为服务器，客隆机器若出现COM+挂起可以尝试重装MSDTC来解

决。

2.3.1.2 K/3运行有时出现COM+组件挂起的异常问题 1、问题描述：

K/3运行有时出现COM+组件挂起的异常问题（整个包或某个组件挂起，需要关闭启动或重新安装才正常）

2、问题分析：

一般产生COM+挂起的原因有：

1) com+进程出现UI；即组件弹出UI对话框，需要人为“确定”才能继续。

2) 出现进程外等待；包括数据库被锁定（可以查数据库锁定情况）或等待其他进程

（一个DLLHOST调用另外一个DLLHOST）。 3) 出现死锁；如A等待B，B等待C，C等待A（例如一个进程打开数据库进行UPDATE，

此时DTC会锁定相应的表,同时另一个进程访问同一个表,出现死锁）。

3、解决方案：

按COM+挂起的处理方法通过抓dump文件(每隔3-5分钟抓一个,连续抓几个)进行分析,看问题是在环境还是在自己的组件中.从dump文件具体分析是哪一个函数哪个SQL出问题,如果多个dump文件都发现问题在某个函数上,可以确认问题是该函数引起。同时建议：

11

金蝶K/3产品性能稳定性案例集

1) 中间层服务器安装VB6sp6 Runtime,sp6改正了在中间层服务器出现消息或打印

命令会造成COM+组件死锁等的问题,同时防止COM+组件的内存泄露；

2) 定时地更新微软COM+的Service Pack,微软每个月会更新COM+ hotfixes,解决出

现的COM+问题,是一个COM+的问题和解决方案库,这些Service Pack一般会包含在微软的安全性补丁中,可以从微软获取；

3) Vc组件中不要定义全局的t-bstr类变量，否则会造成死锁。

注意：中间层服务器安装最新的VB RUNTIME，同时定时更新微软的Service Pack。

2.3.1.3客户端在日常处理中，偶发性出现“组件正在调用中间层?”的提示 1、问题描述：

客户端在日常处理中，偶发性出现“组件正在调用中间层?”的提示，出现该提示后，客户端K/3无响应，无法做任何操作。而且一台客户端出现该问题后，其他客户端也相继会出现该问题，最后只有重启COM＋服务，问题才能解决。该问题一天偶尔出现一次，有时几天出现一次。有时一个用户使用，也会出现该问题。

2、问题分析：

出现该问题时：

1) 客户端，用户无法操作，做任何操作，都提示“组件正在调用中间层?”，等候

一会，仍然无法使用。

2) 中间层，所有组件运行无异常（没有耗时特别长的组件） 3) 数据库，无堵塞，无死锁，无耗时很长的SQL。 4) 重启中间层后，问题可以解决。 分析：

“组件正在调用中间层?”的提示，表示系统出现了挂起。根据问题的初步分析，估计和COM＋有关，并且和使用Win2003系统有关系。分别抓取了客户端KdMain的Dump文件，和中间层eboK/3的Dump文件，然后和微软工程师联系，将Dump文件发给他们。客户端Dump表明，客户端出现了挂起，同时中间层Dump表明，Rpc调用出现挂起。该现象属于微软已经确认的一个BUG，需要安装微软已经发出的补丁解决，或安装Win2003Sp1。

3、解决方案：

在K/3中间层安装了Win2003Sp1后，问题解决。(注意:安装Win2003SP1后，需要进行相关的COM＋安全设置，才能正常使用，需要修改的选项：COM＋设置中，增加了 “远程激活”和“远程启动”权限，Everyone的该权限默认会被取消，必须选上)

2.3.2 通用案例2—-COM+配置/环境的问题

2.3.2.1 COM+ System Application 服务意外地终止 1、问题描述：

表现为客户端挂起，用户无法操作，有的时候会提示“组件正在调用中间层?”，

有的时候没有任何信息，必须手工杀掉进程才能继续使用。 查看中间层的组件服务，表现正常。

2、问题分析：

出现这个问题后，查看中间层服务器上的系统事件日志，事件日志,有下面的信

息:

12

金蝶K/3产品性能稳定性案例集

7031 Service Control Manager COM+ System Application 服务意外地终止，这种情况已经出现了 1 次。以下的修正操作将在 1000 毫秒内运行: 重新启动服务。

7034 Service Control Manager 服务 COM+ System Application 意外停止。这发生了 3 次。

7032 Service Control Manager 在 COM+ System Application 服务意外终止后，“服务控制管理器”试着进行修正操作(重新启动服务)，但这个操作失败，错误是:

服务的范例已在运行中。 原因:

1) “有些系统文件被损坏”； 2) “文件权限问题”；

3) 组件服务中的程序有BUG； 4) 微软操作系统的BUG等。 相关事件号的描述可以查阅微软网站。

3、解决方案：

如果出现这样的问题，可以确定是中间层的COM+服务已经崩溃，此时只能重新安装操作系统解决。

注：文件的破坏很多时候可能是由于病毒引起的，所以定期更新病毒库和杀毒非常重要。

2.3.2.2 K/3V10.2登录时提示“路径/文件访问错误”

K/3V10.2，如果登陆出现“路径/文件访问错误”错误，请修改COM+包的kdsvrmgr的标识为交互式用户。如下图：

此外，如果是帐套管理无法登陆，也是该问题。

13

金蝶K/3产品性能稳定性案例集

2.3.2.3 K/3系统在Win2003环境的设置指南

Windows Server 2003是迄今为止微软最强大的Windows 服务器操作系统，它在运行效率、可靠性、安全性方面均有了巨大的进步与提高，针对Web Services、网络应用、企业级高端计算等方面有更强大的功能支持。

为了支持该优秀平台，K/3系统在Win2003环境下进行了大量的测试，除了证明K/3系统完全支持Win2003，还验证了该Win2003的强大特性，K/3系统在该环境下运行性能更加稳定，更加充分发挥三层结构的优势。

K/3V10.2版本前，在WIN2003装K/3系统需要启用网络DTC访问，网络COM+访问，IIS等环境并进行一些简单配置，安装后也需要对COM+，IIS等进行一些配置才能运行K/3系统，相关配置请参考下面文档说明：

注意：Windows Server 2003 SP1/SP2的相关设置与未装SP1/SP2的2003不一样，2003 SP1/SP2的用户请参阅下一节《Win2003系统安装SP1后K/3系统不能使用的解决方法》

2.3.2.4 Win2003系统安装SP1后K/3系统不能使用的解决方法

微软推出Win2003操作系统以来，其良好的性能及稳定性获得大量用户的好评，但如此庞大的一个系统无可避免会在安全性上有漏洞，微软及时推出相应的SP1。SP1 通过提供诸如安全配置向导之类的新安全工具增强了安全基础结构，它有助于确保服务器的基于角色的操作的安全、通过数据执行保护提高纵深防御能力并通过后安装安全更新向导提供安全可靠的第一次引导方案。

但SP1的相关安全设置也导致了K/3在应用上出现错误，需要对其进行相应的配置，相关配置请参考下面文档进行：

注意：K/3V10.2以前版本在WIN2003操作系统上安装时没有自动进行2003环境配置，需要参

照该文档进行2.3.2.3

2.3.2.5 登录出现“automation”错误 1、问题描述：

进入主控台出现“automation”错误。

2、问题分析：

一般主控台登录出现“automation”错误有两种情况造成，一是客户端本机装有K/3中间层的包或卸载不干净，另一是没有卸载老版本K/3就直接安装安装新版本造成的（或者老版本卸载时有问题），导致客户端的注册表混乱造成的。

3、解决方案：

“冲击波”病毒出现后、微软出了针对性补丁加强了系统安全，这时客户端若远程连接中间层，必须确保本机不能有K/3中间层的包，否则会出现“automation”错误。

针对没有卸载老版本K/3就直接安装安装新版本造成的（或者老版本卸载时有问

14

金蝶K/3产品性能稳定性案例集

题），导致客户端的注册表混乱造成的，请参照下面方法处理：

1) 确认客户端kdsvrmgr.vbr和中间层kdsvrmgr.exe最后修改时间一致。

2) 把老版本的kdsvrmgr.vbr拷贝到system32目录下,在客户端先执行 clireg32 -u

-nologo x:\\winnt\\system32\\kdsvrmgr.vbr，清除老版本组件的注册信息 3) 把新版本的kdsvrmgr.vbr拷贝到system32目录下,在客户端再执行 clireg32 -d

-nologo -s xx.xx.xx.xx x:\\winnt\\system32\\kdsvrmgr.vbr，注册新版本组件的客户端信息(xx.xx.xx.xx指中间层的IP地址)

4) 若问题不能解决，请在客户端执行一下RegClear清除K/3注册信息再安装K/3。

注意：“冲击波”病毒出现后、微软出了针对性补丁加强了系统安全，这时客户端若远程连接中间层，必须确保本机不能有K/3中间层的包。

2.3.2.6 COM+在组件服务中被多次注册 1、问题描述：

K/3中的同一个组件服务，在COM+组件服务中被同时注册了多次，从而导致K/3系统运行发生错误。

2、特点：

Prog标识相同，但CLSID不一致

3、解决方法：

删除重复的组件，重新加入到组件服务中。

注意：在编译COM+组件的时候，注意打上兼容属性，避免一个prog标识多个CLSID的情况。如下图：

15

金蝶K/3产品性能稳定性案例集

2.3.2.7 COM+组件对象存放的目录需要使用英文且不要加特殊的符号

COM+组件对象存放的目录，最好使用英文而且不要加特殊的符号，否则客户端调用COM+组件有可能出现失败。

1、问题描述：

示例：在E:\\COM+问题\\MidwareTroubleshooting\\Demo\\COM+\\MemoryLeak\\Debug下存放MemoryLeak.dll组件对象。注册后如下图：

此时客户端调用将出现下面信息提示：

16

金蝶K/3产品性能稳定性案例集

2、解决方法：

目录使用英文。

注意：COM+组件对象存放的目录需要使用英文且不要加特殊的符号。

2.3.2.8 Windows安全更新导致金蝶中间层不能使用 1、问题描述：

客户通过专门的补丁服务器下载Windows补丁，然后安装到K/3中间层，安装完成后，K/3客户端会无法访问K/3中间层，重启K/3中间层也无效，但K/3中间层本身的K/3系统可用。（打了10次左右的Windows补丁，只有2次安装后K/3中间层是可以访问的）。客户只要重新用修复安装K/3中间层后（无需K/3客户端重新注册），就可以使用。

2、问题分析：

微软工程师通过查看COM＋安装日志和系统事件日志，发现每次Windows补丁安装，都导致COM＋的Catalogs重新安装。初步怀疑补丁对COM＋产生影响。在停止了所有K/3中间层服务之后，再次安装Windows补丁进行测试，K/3客户端可正常访问。

3、解决方法：

重新用修复安装K/3中间层或用户在安装Windows补丁前，先停止所有K/3中间层服务。

注意：在安装Windows补丁前，先停止所有K/3中间层服务。

2.3.2.9 中间层服务器升级到WIN2003后出现“XX组件不可用”、“内存不足”等错误 1、问题描述：

客户将K/3中间层服务器升级到Windows Server 2003之后，发现K/3运行一段时间以后，无法正常工作，出现客户端请求无法得到处理,最终导致COM+ Application崩溃的现象，中间层服务器Event Logs记录了大量的COM+错误。

客户端会提示“XX组件不可用”、“内存不足”等错误。中间层没有提示，但Event Logs出现以下错误日志。比较典型的错误日志有:

1) The run-time environment has detected an inconsistency in its internal

state. This indicates a potential instability in the process that could be caused by the custom components running in the COM+ application, the components they make use of, or other factors.

d:\\srv03rtm\\com\\complus\\src\\comsvcs\\threads\\stathread.cpp(284)中的错误，hr = 8007000e: CSTAThread: CoGetApartmentID failed

2) 运行时环境检测到其内部状态存在不一致。这说明进程中存在潜在的不稳定性，

可能是由于 COM+ 应用程序中运行自定义组件、COM+ 应用程序使用的组件或其他因素引起的。

17

金蝶K/3产品性能稳定性案例集

内容设置为空后解决。

如果未启用下面单据,执行下面的脚本

---外销订单/进口订单/装箱单/出运通知单/退运通知单/进口单证 update icclasstableinfo set flookuplist=''

where fclasstypeid in(1007100,1007101,1007120,1007130,1007131,1007140) and (cast(flookuplist as varchar(8000))) like 'trpc%'

3.5.2启用折扣管理后性能不理想

1、问题描述 10.3之后的版本启用折扣管理后单据保存等操作速度变慢 2、问题分析 通过分析相关的存储过程后，发现存储过程的写法上面存在问题，修改后问题得到解决

3、解决问题

执行下面的SQL脚本

3.6. K/3V10.4性能问题案例

3.6.1 信用管理不能启用

1、问题描述： 信用管理，启用—停用—再启用不成功 2、问题分析： 通过事件探查器跟踪后台执行的SQL发现，执行到某个位置不再执行。 3、解决问题： 经分析后发现，由于启用信用管理的存储过程中执行TRUNCATE TABLE后，立即对该数据表进行了数据插入和查询操作，由于SQL SERVER2000的一个BUG导致表的统计信息未得到更新从而导致存储过程挂起。通过将TRUNCATE TABLE修改为DELETE 操作，或者关联表操作采用HASH JOIN后问题得到解决

3.6.2 进出口、应收应付某些BOS单据加载、保存、F7多选返回时速度很慢

1、问题描述 进出口、应收应付某些BOS单据加载、保存、F7多选返回时速度很慢 2、问题分析 检查单据的保存规则、值更新事件与加载事件， takebasedata或setdecimal的设计方法，一个action设置对应一个字段，这是效率很低的写法 3、解决问题

将相同类型的action合并为一个，字段之间用逗号分隔即可。其它BOS单据同样适用

43

本文来源：https://www.bwwdw.com/article/52sf.html