金蝶K/3产品性能稳定性优化指导手册

操作系统
- WINDOWS2003是否安装SP1以上的补丁，WINDOWS 2000是否安装SP4补丁
- 32位系统，物理内存大小，对于操作系统可以支持最大内存见（下面设置需要重新启动才能生效）
  - 4GB：在BOOT.INI文件中增加/3GB开关
  - >4GB：在BOOT.INI文件中增加/PAE开关
  例如：multi(0)disk(0)rdisk(0)partition(2)\%systemroot%="Windows Server 2003 Datacenter Edition" /PAE
- 安装病毒实时防护或者启用微软防火墙
  - 如果数据库和中间层服务器启用防护，可以暂时停一段时间看是否性能有所改善，以确定是否防护产生的影响
  - 客户端需要将K3的应用放在例外中
- HOSTS文件（%SystemRoot%\system32\drivers\etc）
  - 中间层服务器将数据库服务器的IP地址和名称加到HOSTS文件中
  - 数据库服务器将中间层服务器的IP地址和名称加到HOSTS文件中
- 如果数据库内存大于2GB，但物理内存一直在2GB左右，检查组策略中【内存中锁定页面】是否设置（gpedit.msc）
  - 【计算机配置】/【windows设置】/【安全设置】/【本地策略】/【用户权限分配】/【内存中锁定页面】添加当前机器下的SYSTEM用户和登录该机器的Administrators组中的用户
  - 如果是SQL SERVER2005，不进行上面的设置将无法启用AWE设置
- 中间层和数据库服务器MSDTC设置(Windows2003+SP)是否如下

数据库
- 版本
  - SQL SERVER2000标准版只支持最大2GB内存
  - 需要支持超过2GB内存，需要选择SQL SERVER2000企业版本和SQL SERVER2005标准/企业版本
  - 如果操作系统为64位机器，建议安装64位版本SQL SERVER
  - SLQ SERVER 2005标准版支持4CPU【物理CPU】，超过4CPU【物理CPU】必须使用企业版本
- 补丁
  - SQL SERVER2000安装SP4
  - SQL SERVER2005安装SP2
- 如果在企业管理器中看到阻塞导致的情况是同一个SPID把自己阻塞了，检查处理器并行
查询分析器中执行sp_configure 'max degree of parallelism',如果返回为0，运行下面语句:

sp_configure 'show advanced options', 1

RECONFIGURE

GO

sp_configure 'max degree of parallelism',1

RECONFIGURE

GO

sp_configure 'show advanced options', 0

RECONFIGURE
- 32位系统下AWE设置(如物理内存为8GB设置数据库的最大内存为6GB)
在查询分析器中执行sp_configure 'awe enabled'，如果返回为0,表示未启用AWE。
```
sp_configure 'show advanced options', 1 
```
```
RECONFIGURE 
```
```
GO 
```
```
sp_configure 'awe enabled', 1 
```
```
RECONFIGURE 
```
```
GO 
```
```
sp_configure 'max server memory', 6144 
```
```
RECONFIGURE 
```
GO
- 数据库的故障还原模式是否为【简单】,如果采用事务日志备份，不需要修改故障还原模式
- 数据库的【自动收缩】属性是否取消
- 再查询分析器中执行DBCC SHOWCONTIG(ICSTOCKBILL)查看表的索引碎片情况，如果【扫描密度】低于85%，那需要重新执行索引重建工作
- 数据库文件和TEMPDB文件所在磁盘是否有可用空间
组件包设置
- 组件包启用帐号设置为【指定用户】或者将【交互式用户】，需要将【调用的身份验证级别】设置为【连接】，【模拟级别】为【标识】
- 组件包的【安全级别】设置为【仅在进程级别执行权限检查】
二次开发
- 如果有自定义的报表，是否设置脏读的事务隔离级别，即在报表语句前面加上
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
网络
- 在DOS模式下执行ping 【服务器IP地址】 -l 1204 –n 100
不能出现丢包现象，如果出现丢包的现象，需要检查网络

问题处理流程和分析方法

2.1 问题处理流程

一般问题的处理步骤如下：

客户反馈性能或稳定性问题，不要着急，按照如图上的步骤我们逐步分析，正确的方法是解决问题的前提，下面为你快速定位问题作一个简单的说明：

第一步：引导客户了解具体问题；

当客户出现性能问题时，首先你要找到发现该问题的客户关键人员（一般都是操作人员），然后和他进行交流沟通。

找到关键人员以后，引导客户交流，确认问题所在，确认详细的操作步骤，问题发生的模块，相关的业务场景和机器环境等。

经过前面的交流，如果有可能首先要落实问题的真实性，避免前面描述和交流导致的错误引导。

第二步：收集用户计算机信息；

自动收集服务器的事件日志，系统配置环境，操作系统版本等信息。

第三步：判断问题来源

根据获取的信息，定位问题对于系统的日志文件和数据库日志文件中的异常。在http://support.microsoft.com/ 网站查找相关的技术或者解决文档，看是否可以解决问题。

第四步：参照案例解决问题

初步定位客户问题以后，首先查看一下是否存在类似案例，如果有，可以参照案例集，我们就能够快速有效解决问题。

如果没有类似案例，我们可以参照相应的分析方法进行分析定位，解决问题（见下面章节的问题分析和解决）。

第五步：定期收缩数据库和定时优化帐套

第六步：检查数据库表结构设计是否合理

常见有：

二次开发的表没有索引,造成性能隐患；不恰当的触发器和游标的使用，大数据表缺少聚集索引。

对于K3已经存在的数据表，可以根据用户实际使用业务情况进行索引优化。

第七步：寻找合适的补丁

第八步：与研发沟通，获得解决方案

以上描述的是最基本的步骤，对于客户的性能问题我们最好是及早解决，如果不能解决尽快反馈到研发，往往发现有些客户刚开始有性能问题时，通过重启服务器等方法凑合。当客户这样使用一段时间后可能会越来越不满满意，导致后面解决问题的阻力很大，所以要积极面对，尽早解决。

2.2 问题分类

2.2.1 非K/3软件问题

这类问题大多是K/3系统的运行环境问题，还有些是应用和实施问题，下面列举一些问题的描述，主要帮助认识问题的本质分类。

2.2.1.1 网络问题

网络出现问题时一般有些客户端不能操作并且有明显错误提示。一般表现为网络不畅通，网络带宽不足，网络不稳定有丢包情况，网络安全性问题等，详细请参考手册第五章。

2.2.1.2 硬件配置

硬件配置尤其是服务器的硬件配置问题，在很多客户那儿发现硬件配置偏低，从而引起性能或稳定性问题。

数据库服务器建议使用高性能配置的机器，或通过增加CPU和内存来提升服务器性能。因为数据库是系统的所依赖的平台，如果平台本身有问题，那么应用在上面的系统肯定也会有问题。

对于硬件配置尽可能在实施时防患于未然，否则如果在使用过程中出现问题时再提议客户升级硬件，可能会受到客户的抵制。一定要对客户的未来业务量有一定的预估，给出合理的硬件配置方案。具体的应用配置请参考后面各个章节的硬件配置部分。

2.2.1.3 软件环境

软件环境主要是指数据库服务器的操作系统和SQL Server版本，以及安装的其它软件。在此特别强调数据库服务器的操作系统尽量采用WIN2003 企业版本，SQL Server使用SQL Server2000 企业版，并至少安装 SP4补丁程序。关于客户端尽量采用WIN2000操作系统，不要使用WIN98。这样有助于K/3系统更加健壮的运行。

2.2.1.4 实施和应用问题

有些性能问题可以通过合理的实施和应用来避免，主要是通过调整系统参数或使用方式让系统速度得到提升。例如序时簿的查询在过滤界面少选择要显示的列，尽可能使用严格的过滤条件，不要使用显示关联标志的系统选项都会一定程度的提高系统速度。这些问题在手册的不同部分会有相关的内容，以后也会逐步补充。

在这里还要强调一点在实施中做的二次开发很有可能引发性能问题。对于有二次开发的系统一定要对二次开发作检查，看看是否有性能问题。

2.2.2 K/3软件问题

对任何软件，都可能会存在一定的性能问题。K/3作为一个复杂的企业应用软件，同样也不可避免会存在性能问题，这需要我们积极去解决。

2.2.2.1 局部功能速度太慢，不能满足日常的业务要求

这些慢的功能点大多数是一些查询和计算功能，如物料（商品）收发汇总表查询，期末结账，成本计算等功能。执行慢的原因在于业务处理逻辑复杂，需要访问的数据量很庞大，需要使用更多的系统资源，从而可能导致所有其它功能点都变得很慢，或者系统一段时间无法响应的（实际是得不到系统资源，处于长期的等待中）现象。当然也有些功能可能是由于当初设计的时候考虑不周，算法不够优化，导致单项功能的性能较差，对于这样的问题，可以错开业务使用高峰，优化算法，或对数据库建立索引来提升性能。

2.2.2.2 整体应用存在性能问题

有些性能问题是由于当时设计系统时没有考虑到数据量的规模，当数据量达到一定规模后系统运行不能达到预期。由于这些问题从软件本身来说可能牵涉很多模块和代码，如果优化需要投入很多的资源，只能在新版产品中改进。如10.2数据授权问题就是这样一个问题，在V10.2SP1中已经做了全面优化。

2.2.2.3 系统突然出现全面的等待现象

对这类问题，大多数情况是客户端提示"调用程序忙，切换到…"，"正在调用中间层…"等提示，首先要判断是否网络或硬件问题；然后看数据库是否阻塞，COM+是否出现问题等等，否则有可能是组件本身存在问题，具体可以参考下面各个章节的内容。

2.2.2.4 有规律的在某个时段系统速度变慢

大多数是月末，或者某段业务高峰期。在发生问题的时段可能会是某一个计算型功能如结账操作耗用系统资源太严重，或者是并发程度高引发系统资源不足.

2.3 问题分析方法

在处理客户问题时，我们要对问题本质有一个清晰的认识，同时我们要采取有效的方法去逐步发现和解决问题。

2.3.1 排除法

在处理性能问题时，排除法是最有效的方法。因为大多数客户性能或稳定性问题，尤其是无规律，全面性的性能或稳定性问题，定位问题所在是很重要的。当然对于那些能够明确定位的问题，可以直接进入下面的章节寻求解决方法。

首先看看是否是非软件的问题。网络是否畅通，硬件配置是否合理，操作系统和SQL Server是否符合建议性的要求（如查看数据库表的统计信息，是否存在碎片），应用方式是否合理。

如果是软件问题主要就是定位是何功能影响了系统的运行速度。首先可以参照2.1网络与Citrix应用问题，4.1 数据库常见性能问题介绍，5.1 中间层COM+常见问题介绍判断是数据库、中间层、客户端还是网络存在问题，然后在各自的章节中寻求解决方法。

如果是数据库性能问题，我们可以从硬件，数据库配置及大小，SQL跟踪优化，数据表索引，数据库日志文件等几个方面进行排查；如果是中间层COM+问题，我们可以参照5.2 中间层COM+常见问题处理中分析和处理方法进行问题处理；如果客户端问题，一般要通过排除确定是数据库、中间层存在问题还是客户端本身程序存在问题。

2.3.2 像医生看病

解决性能问题就和医生看病一样，分支机构和客户的系统管理员一定要亲自观察现场，可以获取一些从用户描述的现象很难得到一些有价值的信息。就和医生看病一样他不可能只凭病人的描述来诊断。

2.3.3 从现象入手

解决性能问题总让人有无从下手的感觉，我们定位问题方法更多，最简单的方法从我们看到的现象入手，逐步分析细化，然后根据分析收集的指标数据，定位或解决问题。例如现象是发生在客户端cpu100%，那么直接从客户端入手即可，判断该现象是只有在一台客户端出现，还是所有客户端都出现，然后根据这个我们就可以重新定位问题或者查找原因了。

网络与Citrix应用问题

3.1 网络引起的性能问题介绍

网络引起的性能问题，反映到整个网络系统，或者单独某台计算机上。现象为K/3系统使用不稳定，时快时慢，甚至出现客户端挂起的现象。

由网络引发导致的性能问题，主要包括下面几个方面：

3.1.1 网络配置不符合K/3应用需求，带宽不足

当网络带宽不符合K/3应用需求时，最直接的后果是导致K/3应用出现性能问题，特别是进行大数据量的查询时速度更慢。

检测带宽可用带宽测试软件，例如Chariot；或者服务器架设HTTP/FTP服务，在客户端查看单线程下载文件速度来判断有效带宽，如在100M到桌面网络环境里，客户端通过文件下载实测约5—7MByte/s，据此推算该百兆网实际有效带宽40—56Mbit/s。

下表是K/3应用对网络的基础要求：

网络类别	设计要求
局域网应用	核心交换机1000M，数据库、中间层服务器、HR/Web服务器直连核心交换机 100M交换到客户端桌面，客户端到中间层有效带宽≥40M 全局域网网络延迟小于10ms，丢包率小于2%
广域网应用	核心交换机1000M，数据库、中间层服务器直连于核心交换机 100M交换到接入服务器(Citrix/终端服务)、HR/Web服务器局域网连接 10M光纤到接入服务器(Citrix/终端服务)、HR/Web服务器因特网连接 ≥64K有效带宽到每个远程客户端(Citrix/终端服务客户端) ≥512K有效带宽到每个HR/Web客户端若采用VPN+K/3 GUI模式，需≥2M有效带宽到每个远程客户端有效带宽需要远程连接网络延迟小于100ms，丢包率小于2%

3.1.2 网络不稳定或存在丢包现象

出现网络不稳定或存在丢包现象问题时一般有些客户端不能操作并且有明显错误提示。首先应该检查网络是否畅通，如果出现所有客户端都无法操作，要检查中间层和数据库服务器是否互通，并且两台服务器的IP地址和计算机名是否正确。

一般检查网络是否通畅可以使用PING的方法：

通过ping Ip地址看是否网络畅通

通过ping xxx.xxx.xxx.xxx –n 1000 –l 2000命令实测察看是否丢包和网络的平均速率

通过pathping xxx.xxx.xxx.xxx命令实测察看是否丢包

time<1ms,sent=1000,received=999,lost=1(0% loss),Min=0ms,Max=9ms,Average=0ms

for 25 second statistics中,Pct=Lost/Sent=0%即:无丢包,丢包率0%.

一般出现丢包掉线的可能原因主要有：

局域网中的某台或者多台机器感染了病毒，在疯狂发包，导致路由器NAT连接很快占满；
可能是交换机长时间没有重启其内存已用光，导致交换数据速度缓慢，或受网络风暴影响导致阻塞或交换机的某一个或几个接口模块损坏，或交换机故障引发的网络内暴

建议处理方案：

（1）试着断开某台交换机，进行逐一排查，进行隔离杀毒，找到该台机器，将其隔离；

（2）关闭局域网内所有交换机4-5分钟后，重新接通电源，观察网络是否恢复正常；

（3）联系您的网络供应商协助解决。

3.1.3 网络安全性问题

随着计算机病毒不断变种和蔓延，其危害程度也越来越高，因此网络安全最大的隐患就是病毒，它能直接导致K/3操作缓慢，出现性能问题。

保障系统安全，一般考虑几个主要因素：

1、操作系统安全

? 及时安装Windows安全补丁（SP和Hotfix）。

? AD域控制器及成员服务器组策略设置、安全模板选择。

? IPSec（IP安全策略，例如，数据库服务器仅允许某IP进行访问，防止非法访问）。（可选项）

? 数据库服务器IP地址对客户端不可见，特殊岗位可采用路由或VPN连接。（可选项）

2、防火墙管理

防火墙应用目的：设置策略，授权控制访问，诸如：IP地址、端口、网站等等；发布局域网应用（FTP、MAILServer、Web应用、局域网服务器应用程序端口）至Internet。

例如，Citrix WI服务应透过防火墙发布，而不是将Citrix-K/3服务器直接暴露在互联网招致攻击。

应用场景：数据库服务器完全受防火墙保护、HR服务器仅发布80等端口。

特别说明：防火墙目前市面上流行很多品牌型号，防火墙性能高低直接影响K/3 HR，其系统策略复杂程度均会影响网络传输。特别是K/3 HR大量并发用户应用，数据库与HR服务器之间的有效带宽达到100M，甚至更高达1G。所以，在部署防火墙的同时，要求同步考虑防火墙策略是合适，必要时，建议将HR服务器与数据库之间同属防火墙保护范围之内。

3、建立SSL安全机制（可选）

IIS的身份认证除了匿名访问、基本验证和Windows NT请求/响应方式外，还有一种安全性更高的认证，就是通过SSL（Security Socket Layer）安全机制使用数字证书。

建立了SSL安全机制后，只有SSL允许的客户才能与SSL允许的Web站点进行通信，并且在使用URL资源定位器时，输入https:// ，而不是http:// 。

简单的说默认情况下我们所使用的HTTP协议是没有任何加密措施的，这点危害在一些企业内部网络中比较大，对于使用HUB的企业内网来说简直就是没有任何安全可讲，因为任何人都可以在一台电脑上看到其他人在网络中的活动，对于使用交换机来组网的网络来说，安全威胁性要小很多。

所以，对安全性要求较高的企业，全面加密整个网络传输隧道的确是个很好的安全措施。

4、定时查杀病毒

定时地更新病毒库并在非业务操作时间进行定时的病毒查杀，可以更有效地防止病毒危害，同时也避免对K/3业务操作的性能影响。

3.2 Citrix应用引起的性能问题介绍

Citrix应用引起的性能问题一般主要在Citrix服务器的配置上面。

3.1.1 Citrix应用硬件配置指南

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

数据库性能问题

4.1 数据库常见性能问题介绍

本章主要对目前K/3数据库与性能有关的问题进行描述，帮助用户更好地优化数据库服务器性能，以提升K/3整体应用的性能。主要包括数据库服务器硬件性能、数据库维护策略、数据库表结构优化等以及一些其他注意事项。

4.1.1 数据库服务器硬件配置

从很多客户反馈的性能问题发现：数据库服务器硬件配置偏低，对系统运行性能产生了一定的影响，导致客户出现整体性的性能问题。

数据库服务器作为账套数据的存储平台，无论从性能还是可靠性方面都提出了很高的要求，其配置的基本要求如下：

经济型配置建议（100个在线用户以内应用，账套大小在4G以下）

项目	配置
OS	Windows Server 2003企业版 + 最新SP (目前SP2)
MSSQL	SQL Server 2005标准版 + 最新SP (目前SP2)
CPU	双核Xeon 5100系列，配置双路CPU，合共4物理核心
内存	4-8GB
存储	UltraSCSI或SAS，RAID 5 或 RAID 10
网络	1000M交换

标准型配置（100-200个在线用户应用，账套大小在4-8G）

项目	配置
OS	Windows Server 2003企业版 + 最新SP (目前SP2)
MSSQL	SQL Server 2005标准版或企业版 + 最新SP (目前SP2)
CPU	四核Xeon 5300系列，配置双路CPU，合共8物理核心
内存	8-16GB
存储	SAS，RAID 5 或 RAID 10
网络	1000M交换

高端应用（200-400个以上在线用户应用，账套大小在8G以上）

项目	配置
OS	Windows Server 2003企业版 + 最新SP (目前SP2)
MSSQL	SQL Server 2005企业版 + 最新SP (目前SP2)
CPU	四核Xeon 7300系列，配置四路CPU，合共16物理核心
内存	16-32GB
存储	FC-SAN
网络	1000M交换

通过增加内存和CPU可以提升数据库服务器的性能，利用RAID来存储数据可以提高数据的安全和可靠性，同时也会带来一定的I/O性能提升。另外也可以考虑将账套分布到不同的数据库服务器上。一般通过观察服务器上任务管理器的性能监控可以大概判断硬件配置是否有问题。下面主要谈谈CPU和内存因素。

4.1.1.1 与CPU有关问题

症状1：

数据库服务器中任务管理器CPU持续100%很长一段时间

分析：

当发现数据库服务器的CPU很长一段时间都是100%占用，首先确认是否为很少使用的计算功能或者是大数据量查询，还是日常业务功能；若为前者，建议适当安排系统空闲时间,尽量不要在业务高峰期运行；若为后者，请通过SQL事件探查器跟踪执行时间较长的SQL，对SQL进行优化（参考），如果仍然不能解决，请将耗时比较长的SQL发回研发中心进行分析和定位。

症状2：

数据库服务器CPU绝大多数时间保持在40%以上

分析：

数据库服务器CPU长期保持在40%以上，系统的运行速度时快时慢，这表示CPU的负荷已经很重，建议升级硬件，增加CPU的个数可能是需要的。

症状3：

数据库服务器CPU耗用很低，但系统整体性能很差

分析：

这种情况很可能是数据库发生阻塞。

对执行结果进行分析并寻求解决方法，如果不能解决，请把结果保存为文件反馈到研发中心，研发人员会根据此结果进行处理。

4.1.1.2 与内存有关问题

1. 简单判断数据库服务器内存是否够用

在任务管理器中选择查看-显示内核时间，会显示一条红线，如果红线很高，证明大量的磁盘读写操作，说明内存可能不够，需要大量的内存切换。

打开性能计数器，查看【磁盘的平均队列长度】，如果长时间大于2，可能内存不够用

2. 数据库服务器内存居高不下

首先明确，K/3中数据库服务器的内存只上升，不下降，不是我们的软件问题，而是SQL Server使用内存的策略造成，是正常现象，相关的内容可以在微软的技术支持网站上查到http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adminsql/ad_config_9zfy.asp

3. 数据库服务器内存配置

数据库的物理内存一般来说越大越好，由于考虑到成本问题，需要对用户未来的业务有一个估计，业务数据量和业务的频繁度可以作为配置服务器硬件的一个依据。数据量对数据库服务器的内存配置有直接的影响，从经验的数字来说最好是物理内存要大于账套的数据文件，如果账套数据文件小于1G，应该配置至少1G内存，如果账套数据文件大于1G, 物理内存应该和数据文件大小相当，例如账套数据文件为2.4G,那么应该配置至少2-3G内存。

4．如果物理内存超过4GB，请参照附录中《SQL Server 的大内存管理》设置

4.1.1.3 数据库实例默认选择【并行】导致死锁和阻塞问题

1：由于启用了【并行】可能导致死锁。主要表现为同一功能，隔一段时间就会出现死锁，此时客户端现象为：

如果出现这样的情况时，请在SQL 查询分析器中执行dbcc traceon(1204,3605，-1)【SQL SERVER 2000跟着标记为1204，SQL SERVER 2005中为1222】，将死锁的信息记录到数据库的日志中。然后等待场景重现，再出现后这时候运行数据库的企业管理器，查看数据库的日志，将会看到类似下面的信息：

ResType:LockOwner Stype:'OR' Mode: S SPID:64 ECID:13 Ec:(0x8E0480C0) Value:0xaa

Requested By: Owner:0xa9617ba0 Mode: S Flg:0x0 Ref:1 Life:00000001 SPID:64 ECID:14

Wait List:

PAG: 16:1:319244 CleanCnt:5 Mode: IX Flags: 0x2

Node:4

Producer: Xid Slot: 7, EC = 0x8d26a0c0, SPID: 64, ECID: 16, Blocking

Producer: Xid Slot: 5, EC = 0x8dffc0c0, SPID: 64, ECID: 14, Blocking

Producer: Xid Slot: 4, EC = 0x8b6ae0c0, SPID: 64, ECID: 15, Blocking

Producer: Xid Slot: 3, EC = 0x8e0480c0, SPID: 64, ECID: 13, Blocking

Producer List::

Consumer: Xid Slot: 6, EC = 0x8b4dc0c0, SPID: 64, ECID: 2, Not Blocking

Consumer: Xid Slot: 2, EC = 0x8db4e0c0, SPID: 64, ECID: 4, Not Blocking

Consumer: Xid Slot: 1, EC = 0x8deb80c0, SPID: 64, ECID: 3, Not Blocking

Consumer: Xid Slot: 0, EC = 0x8a00e0c0, SPID: 64, ECID: 1, Not Blocking

Consumer List::Coordinator: EC = 0x8885d560, SPID: 64, ECID: 0, Not Blocking

Port: 0x800b0480 Xid Slot: 0, EC: 0x8a00e0c0, ECID: 1 (Consumer), Exchange WaiNode:3

这样可以确定是"涉及并行的死锁"，即SPID为64的进程出现了自我阻塞而导致的死锁，该死锁主要是SQL SERVER执行的策略上的问题，SQL语句的写法上可以解决，但在不同的服务器上可能有不同表现，所以通过禁用并行来解决。如果要开启处理器支持并行计划，请确保数据库服务器的配置足够好【如16CPU【物理CPU】，32GB内存】

解决办法：

如果是早期超线程的机器，需要关闭超线程，修改CMOS

a)：开机--〉进入BIOS设置画面

b)：将HYPER-THREADING设为DISAB

取消并行执行；

sp_configure 'show advanced options', 1

RECONFIGURE

sp_configure 'max degree of parallelism',1

sp_configure 'show advanced options', 0

RECONFIGURE

根据提示，重启数据库服务

4.1.1.4 与17883错误相关

如果出现数据库HANG，查看数据的日志文件，可以看到类似下面的信息：

server 错误: 17883，严重度: 1，状态: 0

DBCC TRACEON 208，服务器进程 ID (SPID) 60。

server 进程 191:0 (8d0) UMS 上下文 0x074BECC8 似乎不是在调度程序 0 上生成的。

出现上面的问题时，可以确认是SQL SERVER本身的问题，产生该问题的原因比较多，微软提供的补丁SP4也未能解决所有的17883问题。

解决方式：（本补丁只针对SP4）

http://hotfixv4.microsoft.com/SQL%20Server%202000/sp4/SQL_Server2000_SP4_Hotfix2171/08.00.2171.00/free/255994_CHS_i386_zip.exe

Password: lUn)1p3h

如果SQL SERVER已经出了最新的补丁，则直接升级到最新的补丁即可。

相关17883问题描述：请查看微软网站的815056，319892，810885等文章

4.1.2 数据库维护策略不当

对于任何一个数据库系统，日常的维护是必要的，在日常的系统维护中分支机构应该引导客户的系统管理员做维护，防性能问题于未然。

但有时候不当的维护策略也对性能造成一定的影响。结合常见维护策略进行介绍，旨在防性能问题与未然。

在应用K/3时为了提升整体应用性能，数据库需要做如下的维护策略：

4.1.2.1 设置数据库故障还原模型为"简单"

在SQL Server企业管理器中选择一个数据库，右键点击弹出快捷菜单，选择"属性",如下图界面。数据库的故障还原模型建议使用"简单"模式。

如果采用"简单"以外的故障还原模式，将可能产生大量的日志文件从而影响数据库系统性能

注意：选择简单模式后数据库将不能做事务日志备份。

4.1.2.2 取消"自动收缩"数据库选项

将数据库"属性"中的"自动收缩日志"选项取消（如2.1.2.1下图）。由于需要频繁检查数据库的空间使用情况以及自动收缩有可能发生在数据库文件自动增长之后而增加额外的开销。

4.1.2.3 定期收缩数据库

SQL Server数据库的事务日志会由于各种原因，有时候暴涨，事务日志太大有时候会引发性能问题，因此要有计划地收缩数据库来缩小事务日志。收缩数据库时不但要收缩账套数据库，同时也要收缩SQL Server自带的TEMPDB数据库。可以通过SQL Server企业管理器做一个收缩计划，在没有业务运行的时候定期做收缩，尽量不要在平时做收缩操作，因为收缩操作耗用资源很多，且需要一段时间。

在SQL Server企业管理器中选择一个数据库，右键点击弹出快捷菜单，选择"所有任务"---〉"收缩数据库",如下图界面。

选择根据本调度来收缩数据库(收缩的频率不要过于频繁，否则容易产生更多的碎片，导致数据库性能更差)，然后点击更改按钮，如下图界面做调度安排。

4.1.2.4 定期优化帐套

在SQL Server运行一段时间后，表空间和索引的存储可能会产生碎片，这会极大的影响系统的性能。数据库表是否存在碎片可以通过在SQL查询分析器中使用下面的命令来查看：

如：dbcc showcontig(icstockbill) 显示结果为

DBCC SHOWCONTIG 正在扫描 'ICStockBill' 表...

表: 'ICStockBill'（1180583294）；索引 ID: 1，数据库 ID: 15

已执行 TABLE 级别的扫描。

- 扫描页数.....................................: 9935

- 扫描扩展盘区数...............................: 1252

- 扩展盘区开关数...............................: 8485

- 每个扩展盘区上的平均页数.....................: 7.9

- 扫描密度［最佳值:实际值］....................: 14.64%［1242:8486］

- 逻辑扫描碎片.................................: 41.35%

- 扩展盘区扫描碎片.............................: 60.46%

- 每页上的平均可用字节数.......................: 3763.6

- 平均页密度（完整）...........................: 53.50%

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

可以看出icstockbill表的扫描密度为14.64%，逻辑扫描碎片为41.35%；扩展盘区扫描碎片为60.46%说明存在较多的碎片，并且统计信息很多记录都未进行更新，这将严重影响使用该表时的查询速度，需要对该表进行重建索引。那么我们使用dbcc dbreindex(icstockbill)对icstockbill表重建索引，再对icstockbill表进行统计可以看到下面的结果：

DBCC SHOWCONTIG 正在扫描 'ICStockBill' 表...

表: 'ICStockBill'（1180583294）；索引 ID: 1，数据库 ID: 15

已执行 TABLE 级别的扫描。

- 扫描页数.....................................: 5444

- 扫描扩展盘区数...............................: 682

- 扩展盘区开关数...............................: 681

- 每个扩展盘区上的平均页数.....................: 8.0

- 扫描密度［最佳值:实际值］....................: 99.85%［681:682］

- 逻辑扫描碎片.................................: 0.00%

- 扩展盘区扫描碎片.............................: 29.91%

- 每页上的平均可用字节数.......................: 189.7

- 平均页密度（完整）...........................: 97.66%

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

可以看出icstockbill表的扫描密度为99.85%，逻辑扫描碎片为0.00%；扩展盘区扫描碎片为29.91%，数据页从原来的9935调整为5444，说明碎片已经得到了很好的整理。

可以通过两种方式进行整理，我们称之为"优化帐套"，下面介绍两种方法：

方法1：只对部分核心表进行整理，选择"账套管理" —〉"数据库" —〉"优化帐套"，缺点是账套优化功能不能做调度定时执行，需要每次手工点击执行；

方法2：在SQL Server企业管理器中做维护计划,使用企业管理器中管理—〉数据库维护计划—〉新建维护计划向导，在第三步，选择重新组织数据和索引页，如图4。

由于碎片是由于日常的业务操作导致表中的数据处于不断的删除，新增中造成的，所以应该定期进行优化帐套的操作。建议每周执行一次，同时避开使用K/3系统的高峰期。

注：如果通过重建索引后，扫描密度，逻辑扫描碎片和扩展盘区扫描碎片依然不能得到较大的下降，这时候请先记录下原来建立的索引信息，手工删除所有的索引后，然后再重新建立索引来达到降低碎片。

另外导致该问题还有可能由于数据库文件本身的碎片过多，这时候可以通过进行磁盘碎片整理后，备份后还原新账套的方式来处理。

4.1.3 数据库表结构不合理

针对客户一些特殊需求我们都是以二次开发方式来满足，因为开发周期比较短，更多关注功能实现，忽视了性能问题，常见有：二次开发的表没有索引；不恰当的触发器和游标的使用；不合适的事务隔离级别；以及不正确的SQL语句写法。

对于K/3已经存在的数据表，可以根据用户实际使用业务情况进行索引优化。这个需要一定的数据库知识，可以通过使用SQL Server事件探查器和查询分析器，分析执行时间长的SQL, 对于经常出现在where子句中的字段，并且该字段对应的值在数据表中重复数不高时可以考虑对该字段建立索引，还有就是观察表是否主要用于查询（SELECT）的表，则索引可以根据实际情况多建。但索引也并非越多越好应该限制在10个以内。

对于二次开发的数据表，可以参考下面的原则：

1）必须对表建立聚集索引

2）选择WHERE，ORDER BY，GROUP BY 子句中的字段建立为索引

3）尽量不要使用触发器和在触发器和存储过程中使用游标

4）报表采用脏读的事务隔离级别

5）不要关联不必要的表

6）可以关联物理表的不要关联视图

7）排序操作通过控件而不是SQL 语句来实现

8）WHERE子句中不要对字段使用函数进行比较操作

4.1.4 数据库性能优化方法总结

1、合理的硬件配置

2、改变和调整应用方式

3、正确的数据库维护策略

4、优化数据库索引

5、与研发沟通，获得解决方案

4.2 数据库性能常见问题解答

Q：影响系统运行性能的主要因素有哪些?

总体来说有以下几方面：

数据量

并发客户端的数量

硬件配置和软件环境配置

二次开发

数据授权

Q：如何评价并发客户数量？

正确的评价客户客户端的数量：在业务高峰期同时使用的客户端的数量，并发数越多，速度越慢，很容易造成阻塞甚至死机

。

Q：数据库服务器要注意什么事项？

1、强调数据库服务器的操作系统尽量采用WINDOWS SERVER 2003，SQL Server使用SQL Server2000 企业版或者SQL SERVER2005。确认SQL Server2000是否已经打上SP4补丁,SQL SERVER2005是否打上SP2补丁。

2、尽量将数据库服务器和中间层服务器分开在两台机器上部署，数据库建议使用64位(x64)服务器，并配置双路或四路处理器，处理器推荐Xeon双核/四核2.4G或以上，内存8G或以上，SAS或FC-SAN存储系统，1000M服务器专用网卡。

K/3数据库的性能案例请参照《金蝶K/3产品性能稳定性案例集.doc》

中间层性能和稳定性问题

5.1中间层COM+性能和稳定性问题优化指导

本章主要对目前K/3中间层应用中与性能稳定性相关的问题进行描述，包括中间层服务器配置、COM+组件挂起、CPU100%、Crash，内存泄露等问题症状，以提升中间层应用的整体性能和稳定性。

5.1.1 中间层服务器硬件配置

中间层的任务是运行K/3系统的业务组件，一个中间层服务器往往要为多个客户端提供服务，因此对中间层机器的配置要求一般较高，以提升系统应用的并发能力。

经济型配置建议（100个在线用户以内应用）

项目	配置
OS	Windows Server 2003标准版 + 最新SP (目前SP2)
CPU	双核Xeon 5100系列，配置单路CPU，合共2物理核心
内存	2-4GB
存储	UltraSCSI或SAS，RAID 1 或 RAID 5
网络	1000M交换

标准型配置（100-200个在线用户应用）

项目	配置
OS	Windows Server 2003标准版 + 最新SP (目前SP2)
CPU	双核Xeon 5100系列，配置双路CPU，合共4物理核心
内存	4GB
存储	UltraSCSI或SAS，RAID 1 或 RAID 5
网络	1000M交换

高端应用（200-400个在线用户应用）

项目	配置
OS	Windows Server 2003标准版 + 最新SP (目前SP2)
CPU	四核Xeon 5300系列，配置单路CPU(可扩双路)，合共4物理核心
内存	4-8GB
存储	SAS，RAID 1 或 RAID 5
网络	1000M交换

业务量的大小，客户端的数目会影响中间层服务器的处理和响应能力，通过增加CPU、内存可以对性能的提升带来一定的好处，但这并不是万能的，当达到一定的并发数量后，配置的提升可能对性能的改进成效并不明显，此时应该考虑中间层的分布处理。

中间层使用部门级的服务器即可。根据实际测试的结果，K/3系统中，一台配置为：主流双路双核XeonCPU、2GB内存的中间层服务器，所能负载的并发用户数为100个左右。在超过该并发数目时，可通过提升服务器的硬件配置解决，当单台服务器增加配置仍无法满足性能要求时，此时需要采用多台中间层服务器进行分布式处理。

5.1.2 中间层与客户端不同域性能优化

客户端和中间层最好是配置在同一域中，如果无法配置在同一域中。可以修改组件服务中COM+组件的安全验证选项，如下所示。降低身份验证级别，能够在一定程度上改善调用中间层组件的性能。

另外，使用组件信任注册中间层组件，以提升安全性或降低域服务器负载。

采用信任注册，需要将调用的身份验证级别设置为【连接】，模拟级别设置为【标识】

5.1.3 COM+常用处理方法

这里先列出所有常见的处理COM+问题的方法，后面针对COM+的挂起、CPU100%、性能问题、Crash，内存泄露问题的分析和处理会相应地说明各类问题可以使用哪些常用的处理方法。遇到相关中间层COM+问题时，你可以尝试下面的解决方案看能否解决问题。

出现这些问题时，可以在系统的事件查看器中查看到相应关于COM+，MSDTC，DCOM类别的错误和警告信息【通过CMD模式下运行eventvwr.msc打开事件查看器】。

5.1.3.1 重装MSDTC

方法：在CMD模式下运行msdtc –uninstall，然后重启，运行msdtc –install重新安装

说明：如果在日志中发现MSDTC服务自动停止的情况，或者你的机器是克隆并出现事务无法提交，那么可以尝试重新安装MSDTC。

注意: 该操作需要重启电脑！

5.1.3.2 MSDTC的Log文件路径错误

方法：打开组件服务—我的电脑属性—MSDTC页签，检查MSDTC的Log文件路径是否是%SystemRoot%\System32\Dtclog

说明：如果出现MSDTC无法启动的问题，请检查MSDTC的Log文件路径是否正确。

5.1.3.3 配置线程（For windows2000）

方法：修改注册表，见complusthread.reg

HKEY_LOCAL_MACHINE\Software\Microsoft\COM3\STAThreadPool

Value name: EmulateMTSBehavior

Data type: REG_DWORD

Value data: 0x64

让单个COM+ VB组件同时服务最多100个线程，以提高处理并发请求的数量。

请参考: http://support.microsoft.com/kb/303071/EN-US/

说明：WINDOWS启动的每个进程，所允许的STA线程数，一般为7+CPU个数，默认最大为10*CPU个数，当并发用户较多时，在一个进程池内组件的线程数量超过此数值时，组件的调用会发生阻塞，也容易导致组件崩溃，这也是产生"COM+ 4689错误: 运行时环境检测到其内部状态存在不一致。这说明进程中存在潜在的不稳定性，可能是由于 COM+ 应用程序中运行自定义组件、COM+ 应用程序使用的组件或其他因素引起的。d:\srv03rtm\com\complus\src\comsvcs\threads\stathreadpool.cpp(1223)中的错误，hr = 8000ffff: CSTAThreadPool: Unable to get bind thread."的原因。

由于vb组件对多线程支持较差，所以需要通过修改注册表，增加最大线程数，来解决此问题。

注意：改完注册表需要重启机器才能生效。

5.1.3.4 组件多进程池配置（For Win2003）

方法：选择"管理工具-组件服务-计算机-我的电脑-COM+应用程序"下某个应用程序包，单击右键，选"属性"菜单，进入界面后选"共用与回收"标签页，更改"池大小"。

根据目前中间层服务器的配置情况和软件的实际情况，对于大多数组件建议设置为1，如果出现中间层组件堵塞同时服务器内存充裕的情况下，对于EBOK3等应用并发调用极其频繁的组件可根据其线程数增大进程池数目。例如对于像EBOSYSTEM、EBOPUBLIC这样应用比较频繁的组件设置为2，对于EBOK/3应用极其频繁的组件设置为2-3。

说明：WINDOWS允许为每个COM+包的组件开辟多个进程池，这样就可以将该组件的线程分散到不同的进程池中，有利于系统调度，减少进程的阻塞，提高系统服务性能。

注意：在资源——CPU、内存许可的情况下，理论上进程池数量越大越好，但其受系统核心的desktop heap的限制，进程数不能无限加大，如果过大，可能导致desktop heap不足，引发组件创建失败错误。为了发挥最佳性能，必须根据COM+组件应用的情况，合理设置每个com+包的进程数。

金蝶K3中间层组件包EBO*，目前已经达到40多个，一般情形下，不要随意更改该组件包得其他属性，除非本文档中有介绍可以使用以外，否则，可能产生负面影响。一般如果操作系统剩余内存比较充足，建议对应用较多的中间层组件包EBO*进程池数量为2个，特别充裕时可以设置为3个。

5.1.3.5 Desktop heap设置

方法：扩大Desktop Heap以增加创建Apartment的个数。

a)HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\SessionViewSize

缺省是48M, 是系统范围的desktop heap 的大小,将SessionViewSize改成96M来增加整个系统范围内的desktop heap的大小。

b)HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\SubSystems\Window的值:

%SystemRoot%\system32\csrss.exe

ObjectDirectory=\Windows SharedSection=1024,3072,512 . . . . . .

1024, 3072, 512 是default setting, 将512改成4096, 以增加可创建窗口的数量。

说明：每个系统Desktop对象都有heap 与之对应，Desktop对象使用heap（堆）存储菜单、字符串和窗体等。系统从核心缓存（48M）中分配desktop heap。一个WINDOWS操作系统可以有多个desktop heap。

其分配可以通过注册表进行控制，上面b)的SharedSection=1024,3072,512的三个数字控制heap的分配

第一个键值是Desktop所有对象共享的heap大小。包括全局句柄表（窗体、菜单、图标等的句柄）

第二个键值对应交互式window station Winsta0的desktop heap的大小。用户对象如钩子、菜单、字符串、窗体等消耗desktop heap的内存。此值不必修改。

第三个键值对应非交互式window station的desktop heap的大小。如果没有这个键值，那么其大小和第二个键值一样。

在非交互式工作站下，SCM（服务控制管理台）为一个用户账号的每一个服务进程创建一个新的desktop，因此，一个用户账号的每一个服务将消耗desktop heap 的数千字节。

减少第二个或第三个键值的大小会增加相应工作站desktop的可创建数量。但较小的键值会限制每个desktop内钩子、菜单、字符串和窗体的数量，即限制此进程内组件的创建。另一方面，增加第二个或第三个键值的大小会减少desktop的可创建数量，但每个desktop内钩子、菜单、字符串和窗体的数量会增加。

因为在非交互式工作站下，SCM为一个用户账号的每一个服务进程创建一个新的desktop，较大的desktop heap值将减少此系统可以服务的用户账号数量。

全部的desktop heap 必须适应于48M系统范围的缓存。

当发生组件创建失败/超出内存的错误时，可以适当加大这些键值，如将SharedSection=1024,3072,512的三个数字改为2048,3072, 2048。

参见http://support.microsoft.com/?id=184802

5.1.3.6 应用程序回收时间限制

方法：选择"管理工具-组件服务-计算机-我的电脑-COM+应用程序"下某个应用程序包，单击右键，选"属性"菜单，进入界面后选"共用与回收"标签页，设置[应用程序回收]，使用默认值。

Lifetime Limit: 0

Memory Limit: 0

Expiration Timeout: 15

Call Limit: 0

Activation Limit: 0

说明：应用程序回收中的参数意义：生存时间限制——表示组件从创建到销毁的时间，默认为0，即按照组件自身的生命周期存活；内存限制——表示COM+占用的最大内存数，一旦实际占用达到此限制，系统会自动销毁一些组件，在确认使用情况的前提下，可以根据机器配置设置此值；过期超时——表示在组件销毁时因为尚在激活状态或其他原因，不能立即销毁情况下等待的最大时间，默认为15分钟；调用限制/激活限制——表示允许的最大调用/激活进程数，建议使用默认值0。

系统默认不限制，金蝶K3软件在Windows2000系统最大的性能问题，组件进程出现"死锁"现象，随着用户数量递增，出现的频率也越高，至今仍然没有一个较好得解决办法。在Windows2003操作系统下，略做组件服务设置，那么可以基本上解决上述"死锁"现象。一般来说，该"死锁"问题解决，那么数据库中的记录"死锁"，相应也大大缓解。可以这样理解，同样硬件条件下服务器，在Windows2003做上述进程池设置和应用程序回收时间限制，其综合性能指标比Windows2000要优越很多。也许有人会问，如果某单一业务处理时间（例如40分钟）大大操作回收时间限制？其实该系统它不会强制关闭您业务正在处理得请求，直到完成后该进程将自动关闭。简略设置如下图所示

注意：合理设置Lifetime Limit的值对解决数据库的死锁有一定帮助，但其值不要设置太短，否则会导致COM+ Runtime频繁关闭和启动DLLHOST进程，增加系统的资源压力。

5.1.3.7 MSDTC超时设置

方法：选择"管理工具-组件服务-计算机-我的电脑"，单击右键，选"属性"菜单，进入界面后选"选项"标签页，设置[事务超时]。

设置时可以根据目前的事务性能日志——例如在118S左右，因此可以设置为120S。

说明：MSDTC超时时间表示分布式事务的提交时间，与数据库访问事务有密切关系，优先级低于数据库的超时设置,分布式事务如超过此时间将中止。此时间需要根据事务的平均耗时来设置，设置过大容易导致数据库产生死锁，过小会使一些耗时较长的事务不能提交，使一些长事务被频繁的KILL,导致客户端业务不能正常完成。增大Transaction Timeout值可以减少保存数据引起过多的失败操作。

5.1.3.8 空闲等待时间设置

方法：选择"管理工具-组件服务-计算机-我的电脑-COM+应用程序"下某个应用程序包，单击右键，选"属性"菜单，进入界面后选"高级"标签页，设置[空闲等待时间]。

此参数与上述回收参数设置的生存时间限制参数综合作用，协调处理组件的销毁工作；需要根据客户用户数量与频繁调用状况来决定。

说明：空闲等待时间表示一个进程在空闲状态时的等待时间，超过此时间则会进行销毁，此时间需根据组件调用情况合理设置，设置过长将导致组件进程不能及时释放，设置过短将导致组件频繁销毁创建。

注意：该参数不能设置太大，以尽量减少空闲进程对系统资源的占有。

5.1.3.9 确保中间层组件编译参数的正确

方法：使用工具VB CheckW2K进行检查，对没有选中Unattended Execution和Remained In Memory选项进行编译的中间层组件重新编译（主要指二次开发组件）。

说明：如果中间层没有选中Unattended Execution和Remained In Memory选项进行编译，运行COM+组件会导致COM+的不稳定，甚至导致内存泄露，因而对中间层组件要求编译时参照下面要求进行编译：

General页面

1.Unattended Execution 必选

2.Upgrade ActiveX Controls 必选

3.Retained In Memory 必选

4.Threading Mode :选Apartment Threaded

5.1.3.10 更新服务器环境

方法：此部分主要是更新COM+应用服务器的环境，保证服务器的稳定，主要包括

（1）服务器端使用最新的VB运行时文件。安装最新的VB SP6 Runtime,将msvbvm60.dll从版本96.90升级到版本97.82

（2）升级操作系统到最新的Service Pack，WIN2000请打SP4，WIN2003请打SP1。

（3）升级MDAC到最高版本。

5.1.4 Win2003下中间层EBO组件包安全设置

在Windows 2003环境中安装K/3中间层，特别是早期版本，要求对EBO包属性中安全设置部分进行修改，否则，当客户端数量超过一定数量时，将不定时出现COM+服务错误致使客户端全部中断。所以要求按照如下图设置，否则K/3系统运行不稳定。

如果组件包采用【交互式用户】和【下列用户】的方式运行，将【调用的身份验证级别】设置为【连接】，【模拟级别】设置为【标识】

5.1.5 杀毒软件对中间层的影响

杀毒软件对中间层的影响主要产生原因是：

（1）中间层运行将再内存中产生大量的Dllhost.Exe进程

（2）杀毒软件启用实时监控进程，将监督Dllhost.Exe

（3）系统CPU内存急剧上升

可以采取的防御措施包括：

（1）定期空闲时间杀病毒。

（2）K3业务进行时，停止杀毒软件实时监控服务。

5.1.6 Windows2003中IIS6.0进程管理

相比Windows2000中IIS5.0，IIS6.0同样存在进程管理得优点。经典案例："金蝶集团人力资源管理系统"，也就是说金蝶数字神经系统中的HR.，往年金蝶员工清楚记得在做绩效评估时，要求员工分部门，按照不同时段去完成，而且即使这样还无法保证系统"死机"，而2004年1月自从Hr更换为Windows2003操作系统后，还没有发现过上述现象。系统非常稳定。

5.2 COM+问题常用分析方法

5.2.1 排除法

COM+挂起、死锁和异常问题一般可以从数据库,系统环境和组件本身出发进行分析，通过逐个排除来定位问题具体在数据库、系统环境还是组件本身。

（1）对数据库我们可以通过SP_LOCK和select * from sysprocesses 查看数据库锁的信息和进程阻塞情况,通过 KILL SPID结束长时间未响应的进程；

（2）对于系统环境和组件本身，我们可以创建一个简单的测试组件进行测试，如果简单的组件也出问题，该问题很可能是由于环境导致的，否则，是代码导致的。

（3）对于环境问题，我们可以通过方法4.1.3.3 配置线程修改DIIHOST的MAX THREAD来看是否是由于线程限制引起，如果是我们可以更改加大DIIHOST的MAX THREAD，同时了解系统是否克隆，系统的事务处理是否出问题，如果是，可以通过5.1.3.1 重装MSDTC的方法重新安装MSDTC看问题能否解决，或者我们可以尝试重新安装操作系统来解决。同时，还可以检查下面一些因素:病毒防护程序，注册表，用户权限，网络连接情况。我们还可以通过一些工具，比如filemon来检视问题发生时候文件访问情况，看看有没有什么异常。

（4）对于代码问题，我们可以通过记录log文件来跟踪死锁发生在什么方法上，看是在哪一行发生了错误，错误代码是什么，然后尽可能简化该方法来找到问题的根源。

How To Create Error Handlers in Visual Basic COM Components

http://support.microsoft.com/?id=269797

（5）如果问题不是每次都发生，我们需要在问题发生后抓dump文件，也就是相关进程的内存镜像来分析，分析方法见【金蝶K3产品性能稳定性优化指导手册(辅助工具).doc COM+问题分类分析和处理方法】部分

5.2.2 信息收集综合分析法

发生COM+问题后，如果我们很难确定发生问题的原因，我们可以收集下面的信息，然后综合收集的信息综合分析，看问题的根源是在哪一部分。

根据日志收集com+错误信息，根据COM+错误信息分析和处理问题

根据应用程序ID，定位到具体的com+组件和类上，查看相关的组件和类运行是否正常,是否能正确被创建和实例化。
1. 收集desktop heap内存消耗情况，如果消耗太大可以参照5.1.3.5 Desktop heap设置处理。

收集方法：

拷贝heapmonpkg.exe到要检测的机器上；
打开命令行窗口，运行heapmonpkg.exe (安装目录设在C:\Heapmon)；
运行instheapmon.bat (这会从微软的public symbol server下载win32k.sys的调试符号并且安装一个driver,所以请保证能访问internet)；
运行heapmon.bat，显示结果在屏幕上，并且输出到C:\Heapmon\stats.txt。

收集进程池数，线程数，看设置是否合理。通过5.1.3.3 配置线程，5.1.3.4 组件多进程池配置（For Win2003）反向查看。
收集事务并发数量，最长事务执行时间。
收集站点并发数量。
检查vb组件编译设置，见5.1.3.9 确保中间层组件编译参数的正确。
收集内存/cpu信息，看是否存在性能或内存泄露问题。
收集数据库大小，索引信息，表的大小，看是否数据库存在瓶颈。
1. 按照KB287643设置DebugBreakOnFailFast为Y，收集相关信息，然后设置为N. 当COM+发生异常时会弹出提示，这是可以抓一个完整的COM+DUMP文件进行问题的分析和处理，DUMP分析见【金蝶K3产品性能稳定性优化指导手册(辅助工具)COM+问题分类分析和处理方法】部分。
  
  How To Obtain a Userdump When COM+ Failfasts
  
  http://support.microsoft.com/default.aspx?scid=kb;en-us;Q287643
2. MPSReport
  
  http://www.microsoft.com/downloads/details.aspx?FamilyID=CEBF3C7C-7CA5-408F-88B7-F9C79B7306C0&displaylang=en
  
  使用alliance版本收集MPSReport, 直接运行即可,文件会生成在% Windows%\MPSReports\Alliance\cab目录下。
3. COM+ Catalog Dump
  
  命令行: comcatdump.exe > c:\comcatdump.log

comcatdump.zip 密码123456

客户机器上system32下面msvbvm60.dll的版本，参照5.1.3.10 更新服务器环境。关于msvbvm60.dll 在Windows Server 2003上应该是不需要组件勾选这些options的，请参考，http://support.microsoft.com/?id=833891。
通过性能日志查看系统性能情况

在服务器上打开性能监视器

1）展开 "性能日志和警报"

2）右键点击"计数器日志"

3）选择"新建日志设置..."

4）输入描述名称

5）注意日志文件的位置 (或转到"日志文件"选项卡更改位置)

6）点击"添加对象"按钮，加入Process, Memory两个对象，选择"关闭"。

7）点击"添加计数器"，弹出对话框，在性能对象下拉框中选择Process对象，选中 "所有计数器" 和 "所有实例" 单选按钮，选择Memory对象，选中 "所有计数器"，选择"关闭"

8）点击 "确定"。

抓dump,具体命令如下，分析见【金蝶K3产品性能稳定性优化指导手册(辅助工具)COM+问题分类分析和处理方法】部分。
1. 下载Debugging Tools For Windows安装到比如，C:\debugger目录。
  
  http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx
2. 打开cmd.exe,切换到C:\debugger目录，键入命令行: cscript adplus.vbs –quiet –pn dllhost.exe –crash –o C:\dllhost_dmp抓DUMP文件的命令参数对各种具体问题会有一些不同，请参见【金蝶K3产品性能稳定性优化指导手册(辅助工具)COM+问题分类分析和处理方法】部分
3. 对Windows Server 2003 请用下面的方法生成dump, 如果已经使用adplus来抓取dump,就打开命令行，切换到c:\debugger, 键入kill cdb.exe，即可杀掉debugger并dllhost.exe. 然后请如下图示enable Windows Server 2003的COM DUMP抓取。
  
  设置后请restart组件进程。
  
  dump会自动生成在 %systemroot%\system32\com\dmp下，请保证dllhost运行的账户对这个目录有写入权限。

5.3中间层COM+问题解答

5.3.1 如何解决COM+/MTS 4097 错误事件?

当COM/COM+应用程序发生违例时，会在操作系统事件日志中产生4097事件。当发生这个错误时，可以按照下列步骤检查:
(1)升级MDAC到最高版本
(2)如果应用程序存取第三方数据库软件，确保客户端软件与COM+/MTS兼容
(3)使用OleView.exe确认组件能够被实例化
(4)升级操作系统到最新的Service Pack
(5)如果程序由VB编写，在编译前， "Unattended Execution" 和"Retained in Memory"选项需要使能
(6)服务器端使用最新的VB运行时文件
(7)具有强健的出错处理程序

5.3.2 不支持事务的组件是否能放入COM+应用程序中？

事务处理和对象请求代理是COM+/MTS 编程模型的两个重要的组成部分。不包含事务处理的组件仍可以利用分布式组件对象模型和COM+/MTS的进程级安全系统。这样， COM+/MTS 被用来管理对象实例和对象生命周期。

5.3.3 如何在安装完COM+ Application Proxy之后, 修改远端服务器名？

首先要安装Windows 2000 Service Pack 1 或以上版本。然后在应用程序属性中选择Activation对话框，在里面填入远端服务器的IP地址或机器名。

5.3.4 VB在COM+和MTS中创建对象有何异同点?

在MTS中，必须在根对象中用ObjectContext.CreateInstance来创建子对象。这种方法在COM+仍然可行，但不是必需的。 COM+可以使用VB标准的CreateObject函数，正确将事务转移到子对象。

5.3.5 需要开启哪些端口以使MSMQ能够透过防火墙存取？

只发消息： TCP 1801
发消息和活动目录存取： TCP 1801， RPC 135， 2101
收发消息和活动目录存取： TCP 1801， RPC 135， 2101, 2103, 2105。

5.3.6 把COM+ 应用程序导出为Application Proxy后，安装到Windows NT 或 Windows 98上时，为什么CreateObject()会产生"class not registered"错误？

在客户端用regedit观察，发现组件CLSID并没有注册。这个问题将在安装Windows 2000 SP3之后解决。

这个现象只发生于安装Application Proxy到Windows 2000客户端时。即使安装的是Application Proxy，Windows Installer也会试图对所依赖的动态链接库等调用LoadLibrary()。因此，如果LoadLibrary()找不到相应的动态链接库，就会出现此错误。有下列方法可以解决此问题：
1）先将所依赖的动态链接库拷贝到客户机的winnt\system32目录，再安装Application Proxy。
2）生成自己的安装程序，写入DCOM所需的注册表项目。

5.3.8 做大的查询时COM+组件调用时间过长，此时若客户端用户人为结束进程，COM+还是一直在转，需要几分钟后COM+才能释放

客户想强行关闭时，告诉用户还在运行，有一种通知机制，避免用户以为没有在执行而人为结束进程。

若事务运行时间真的这么长，可以优化设计，改成多个小事务或采用异步查询（马上返回，用户查询状态：进行，完成）。

可以通过com+admin的killComponent方法停止COM+组件，但不建议使用，会影响其他用户。

5.3.9 如何优化进程间通讯（包与包间的调用），提高性能

K/3有很多基础的COM+组件经常要被其他包的COM+组件调用，这样会影响系统性能，建议对一些经常调用的基础组件配置为Library application,即通过中间层包的分层解决，减少调用的性能损耗，但需要注意：

（1）远层不能调用配置为Library application的COM+组件，需要再包多一层供远程调用

（2）防止组件导致进程崩溃影响其他同一进程内的其他组件，要有完善的出错处理机制。

也可以考虑在实现外部接口时，如果同时存在进程间通讯或包内的组件间调用，通过公共类的引用来实现，以便减少性能损失。另外，可以使用K/3性能监控工具查看各方法调用的占用时间。

5.3.10 防火墙导致COM+不能访问的问题

WIN2003启用防火墙后不能创建COM+组件，安装瑞星杀毒软件后不能连接COM+组件，这些都是因为防火墙禁止某些端口造成COM+不能访问，可以通过放开一些端口，然后修改REG使COM+使用这些端口即可。可以使用http://www.sysinternals.com上的TcpView工具查看相关端口。

5.3.11 COM+包[安全属性]设置中如果设置身份验证级别为无会有什么影响，对性能提升有无帮助？

COM+的身份验证级别改为无会提高性能，但其他用户若知道COM+接口可随意调用，存在安全性问题，建议按默认设置。

有安全性级别认证需要域用户。

5.3.12 如何更好地部署COM+，需要遵循什么原则

COM+分包原则：按工作量分包，保证各个包工作量的均衡。

5.3.13 VB组件能否支持对象池

实现对象池组件需要实现IOBjectctrol接口并设置canbepooled为true，同时组件需要支持聚合，即组件释放时会聚合到COM+对象池中，并没有真正释放。因而VB组件实现不了。

5.3.14 3G补偿的作用

内存的一个设置，WIN默认每个进程的最大内存为4G：其中2G用户空间，2G核心空间。使用3G后，用户空间会涨到3G，而系统核心空间缩小到1G。主要为应用程序增加内存使用。

5.3.15 在中间层MODULE能不能执行SQL

可以，但是不能定义ADO或CONNECTION为全局变量，否则会成为性能瓶颈。任何COM对象一般都不建议声明成全局变量。COM+是无状态（Stateless）的。

5.3.16 .Net调用自动COM+时，并发性能较差

在.Net调用自动COM+时，在压力测试情况下发现30%的时间都消耗在建立COM+对象上，并发性能较差。

.net由于是托管的代码，在调用COM+性能会比VB调用COM+慢很多。但是随着微软新操作系统的出现，到时候将会倒过来。

1、由于采用自动事务的COM+都采用垃圾回收，每次调用时都会重新创建新的COM+对象，导致创建时间将会消耗大量性能，因此需要尽量减少COM+的调用。而HR现在采用的外围采用委托事务的方法将是很好的解决方案。

2、对于仍然采用自动事务的COM+代码，建议采用COM+对象缓存池，具体使用案例由微软工程师提供。

3、建议COM+组件要均衡配置，按工作量分包，保证各个包工作量的均衡。

5.4中间层非COM+性能优化

5.4.1 停止K/3系统相关服务

1、若没有使用管理驾驶舱模块，请将中间层服务器上的Apache Tomcat服务停止。

2、若没有使用人力资源系统（HR），请将中间层服务器上的HRJobProcess服务停止。方法同上。

3、若没有使用远程传输系统（iMts），请将中间层服务器上的Kingdee iMTS Service服务和Kingdee iMTS Event Server停止，方法同上。

5.4.2 域服务器、中间层服务器、数据库服务器分开部署

客户端性能问题

6.1 客户端性能问题介绍

客户端表现出来的性能问题，一般可以反映到数据库或中间层的优化上，最后没有办法才到代码级别的优化。

6.1.1 某些客户端的速度比以往使用K/3慢一点

客户反馈：

某些客户端的速度比以往使用K/3慢一点

处理分析：

大多数是客户端的硬件配置可能偏低，而且使用了WIN98操作系统，建议客户适当升级客户端的硬件配置，使用win 2000 professional操作系统，或者建议客户把使用频繁的K/3客户端作较好的配置，在不增加硬件的情况下对已有的pc做调剂。同时，告诉客户K/3系统之所以可能比他们以前用的小系统慢，是因为功能的复杂性，如提供了并发控制的网络控制和严密的授权逻辑。重要的是能够满足客户的日常业务。

硬件配置建议客户端CPU主频2G或以上，内存至少256兆（推荐512兆）

6.1.2 某些局部功能速度太慢

客户反馈：

局部功能点速度很慢，很可能会引发整个系统的瘫痪，进而导致所有其它功能点都变得很慢，甚至出现死机（实际是得不到系统资源，处于长期的等待中）现象。这些比较慢的功能点一般包括大数据量的物料（商品）收发汇总表查询，期末结账，成本计算等功能

典型示例：

计算类——期末结账，MRP运算,凭证生成，成本计算
查询类——报表（物料收发汇总表），序时簿
日常票据处理业务

处理分析：

对于上面谈到典型局部功能点慢的问题，首先寻求技术支持或者从技术支持网站查询相关补丁，若是一个通用的问题，可能已经有了相关的补丁。如果没有相关的补丁解决，请提交研发，这些与客户日常业务密切相关的操作，必须要能满足客户的要求。当然针对根据不同类别有不同处理建议。

（1）对于计算类，如果不是日常功能，建议客户尽量不要安排在业务高峰期做，以免影响其它功能点；

（2）对于查询类，建议客户根据自己需要设置查询过滤条件，避免不做任何过滤做大数据量的查询，从应用方式避免出现性能问题。

（3）对于日常票据处理业务，特别是与客户日常业务密切相关的操作，如果没有相应的性能补丁，请迅速提交研发跟踪处理。

6.1.3 客户端出现Automation 错误

关于Automation错误的成因也是多方面的，最多的是支持软件如：WINDOWS文件、系统控件等，都有可能导致问题的出现。当然，K/3自身的问题也存在。Automation错误，是系统无法捕获的错误，根据以前遇到此问题的经验，通常有以下几种可能：

1、客户端的MDAC程序出现问题，通过安装MDAC2.8来解决；

2、服务器的MSDTC没有正常启动，或启动用户的权限有问题，请检查组件服务中的MSDTC并使用具有启动权限的用户来启动；

3、客户端的分布式DCOM没有正常启动，请检查客户端的DCOM配置属性中是否选择上"在本机启用分布式COM"选项。

4、客户端或服务器中安装了相应的防火墙，截断了客户端与服务器的DCOM访问，比如XPSP2的内置防火墙设置、个人防火墙软件关闭了135和1024以上的端口，都会造成此问题。

5、客户端或服务器安装某防病毒软件与K/3的DCOM访问存在冲突，如瑞星等。

6、客户端的组件没有正常注册，请使用TS0026补丁工具进行注册，下载地址：

<http://www.kingdee.com:8080/download/agentdown/tech/ts0026.rar>

7、我们所遇到的多是在卸载其他软件后出现的（如用友的软件，等等），估计很可能是系统文件或公用文件受到损坏所致。所以也建议朋友们尽量保持系统文件的清洁，防止卸载文件导致错误。

6.1.4 如何查看具体哪个组件存在性能问题

可以通过K/3性能监控工具检测是哪个组件哪个方法存在性能问题，然后针对具体代码进行优化。

工具使用说明：在局部客户端出现性能问题时，打开该客户端跟踪工具进行跟踪，将跟踪结果保存成.ktr文件传回研发中心进行分析（缓慢现象出现前后1分钟内的信息最有价值）。

6.1.5 关于趋势防火墙与K/3的冲突

当趋势防火墙升级到V6.5后，会不停的扫描K/3的主进程，导致K/3客户端越来越慢，以致感觉象死机。解决的方案就是把K/3的安装目录添加到趋势防火墙的例外列表中。如下图所示

6.1.6 使用了严重影响K/3系统性能的系统选项

功能和性能往往是矛盾的，有些系统选项能够从功能方面给客户带来方便，但是往往会造成严重的性能问题。所以要在功能和性能方面权衡，有时候可以说服客户不要使用一些严重影响性能的选项，其实只要让客户理解，大多数客户是可以接受的。

1、工业系统中的序时簿显示关联标志

在工业系统中如果选择序时簿显示关联标志会严重影响序时簿的查询速度，在大规模并发下还很有可能引发所有工业物流客户端的全面等待甚至死机。其实这个功能大多数客户并没有使用，甚至根本都不理解有何用途。所以建议在实施的时候直接关闭。

2、商业系统中的自动填补断号

在商业系统中如果选择单据自动填补断号，会严重影响单据的保存速度，而且数据量越大速度越慢，甚至引发死机，所以建议不要使用这个选项。

相关案例以及解决方法：河北某客户反映零售单转换功能会造成阻塞、死锁。经分析发现，零售单转换的存储过程中取得单据编号的过程占了总时间的90%。并且存储过程涉及到商业的几个主要业务表的操作。由于这几个主要业务表长时间的锁定，造成了阻塞甚至死锁的出现。经分公司与客户协调，去掉填补断号选项并清楚了系统日志，系统达到良好的运行状态。

3、大多数过滤条件中的包含未审核单据或包括未过帐凭证

很多物流的报表有包含未审核单据的选项，很多财务的报表有包含未过帐的选项，这种选项都会严重影响报表的响应速度。建议尽量不要使用。

4、减少序时薄显示字段提高性能

现在K/3系统中序时薄显示的字段没有修改后缺省都是选择所有的字段，导致查询的时候关联表增多，数据量增大，从而导致成本增大，速度慢。

解决方式：通过手工设置每次需要显示字段，或者使用下面的工具，设置只需要显示的字段。

5、K/3系统选项建议设置
1. 取消[显示所有下级明细数据]选项。
  
  请打开[物料]，选择[查看]菜单下的[选项]，取消[显示所有下级明细数据]的选项，需要每台客户端每用户都进行设置。上周五现场发现客户并没有设置，请请务必设置，这样每个客户端都减少一点压力就是对整体性能的提升。
2. 序时簿查询慢
  1. 调整查询方式，尽量少用[包含]的查询条件
  2. 减少查询项，只显示需要的字段（可以保存成不同过滤方案）
  3. 如果可以的话，系统设置不使用"单据操作权限控制到操作员组"参数
1. 选单慢
选单调用序时簿，主要是上面序时簿查询慢的问题，出采取上面的措施外，请使用选项"选单时弹出过滤界面"[打开单据--"选项"菜单--选中"选单时弹出过滤界面"],这样在F7选单前可以先过滤你要的单据,减少数据量,提高性能。

需要每台客户端每用户都进行设置。
1. 修改系统设置选项
6.1.7 其他

1、如果使用客户端的消息平台功能，大量的消息读取SQL，可能引发阻塞，建议每个客户端关闭消息功能或将刷新时间减小。

6.2.5 系统突然出现全面的死机现象

1、问题描述：

突然间所有客户端无法使用，大多数情况是客户端提示"调用程序忙，切换到…"，"正在调用中间层…"等提示，等了一段时间也没有反应，客户认为"死机"了。

2、问题分析：

（1）首先有可能网络中断或者不稳定，这种情况，一般客户端报告明显的网络错误；

（2）如果网络畅通，有可能是网络中IP地址和计算机名称的不匹配。在这里，要注意的一种情况就是如果客户的中间层和数据库服务器是分开的，要确保这两台机器能够互通，这里常出现的一个问题就是ip地址和计算机名不匹配，也就是说，在hosts文件中记录的IP地址和计算机名称不匹配，假如数据库服务器记录了错误的信息，就会造成在客户端报一个"定义的应用程序和对象错误"等错误，但实际是中间层服务器可以访问数据库服务器，但是数据库服务器无法访问中间层服务器。这时要确保网络中IP地址和计算机名称的匹配，保证地址解析的正确性。

（3）如果客户端提示"调用程序忙，切换到…"，"正在调用中间层…"等提示，客户可以不停的切换重试，或者强行中断客户端程序,分析：第一种原因是服务器硬件资源不足，注意观察数据库服务器的CPU表现，如果CPU资源长期达到40%以上，这表明CPU资源已经严重不足，如果CPU达到100%,则是某一个功能独占了数据库服务器CPU资源；第二种原因是数据库阻塞，此时数据库数服务器CPU耗用很低，但是整体性能很差。

3、解决方法：

（1）请先保证网络畅通和稳定；

（2）确认hosts文件中的网络中IP地址和计算机名称的匹配，保证地址解析的正确性；

（3）如果客户端提示"调用程序忙，切换到…"，"正在调用中间层…"等提示，如果通过自己观察，数据库服务器的CPU资源长期达到40%以上，这表明CPU资源已经严重不足，需要升级硬件。如果CPU达到100%,则是某一个功能独占了数据库服务器CPU资源；第二种原因是数据库阻塞，此时数据库数服务器CPU耗用很低，这种情况请参考：3.1.1.1 与CPU有关问题

（4）如果是中间层COM+出现问题，请参考第3章中间层COM+问题进行处理。

（5）如果客户端的操作系统是XP，在服务器上和客户端上，都把MaxUserPort改为65534，然后重新启动服务器和客户端。设置方式参见

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

6.2.6 客户端出现"新事务不能登记到指定的事务处理器中"

1、问题描述：

    数据库和中间层服务服务器为WINDOWS2003+SP1或者WINDOWS XP，使用K/3时，出现"新事务不能登记到指定的事务处理器中"的错误。

2、问题分析：

    1）数据库和中间层服务器是否在同一网段；

    2）查看中间层组件属性"标识"采用的信任模式；



    3）查看MSDTC的安全配置情况，系统缺省安装时是"要求对双方进行验证"的



3、解决方法：

    1）如果数据库服务器和中间层服务器不在同一个网段，在中间层的HOSTS文件中加上数据库服务器的IP和计算机名，数据库服务器的HOSTS文件中加上中间层服务器的IP和计算机名。HOSTS文件在%SystemRoot%\system32\drivers\etc下。如果操作系统是WINDWOS 2000也需同样处理。

    2）如果未采用信任注册的模式，需要修改"COM安全"页下的"编辑限制"



    增加Everyone 用户

3）MSDTC的安全配置情况，修改为"不要求方进行验证"，如果为HR系统需要选择"启用XA事务"

附录1：SQL Server 的大内存管理

1. 概述:

标准的 32 位地址最多可映射 4 GB 内存。因此，32 位进程的标准地址空间限制为 4 GB。默认情况下，在 32 位 Microsoft Windows 操作系统上，将为操作系统保留 2 GB 空间，另外 2 GB 空间可由应用程序使用。如果在 Windows NT Enterprise Edition 或 Windows 2000 Advanced Server 的 Boot.ini 文件中指定 /3GB 开关，则操作系统将只保留 1 GB 的地址空间，而应用程序最多可使用 3 GB 的地址空间。

AWE 是 Windows 的内存管理功能的一组扩展，它使应用程序能够使用的内存量超过通过标准 32 位寻址可使用的 2-3 GB 内存。AWE 允许应用程序获取物理内存，然后将非分页内存的视图动态映射到 32 位地址空间。虽然 32 位地址空间限制为 4 GB，但是非分页内存却可以远远大于 4 GB。这使需要大量内存的应用程序（如大型数据库系统）能使用的内存量远远大于 32 位地址空间所支持的内存量。

2. 在操作系统上配置AWE:

在操作系统上配置 AWE 之前，请考虑下列事项：

AWE 允许在 32 位体系结构上分配超过 4 GB 的物理内存。只有当可用物理内存大于用户模式的虚拟地址空间时，才应该使用 AWE。
若要支持大于 4 GB 的物理内存，必须将 /pae 参数添加到 boot.ini 文件中并重新启动计算机。例如:

multi(0)disk(0)rdisk(0)partition(2)\%systemroot%="Windows Server 2003 Datacenter Edition" /PAE
如果计算机上的可用物理内存超过 16 GB，操作系统就需要 2 GB 的虚拟内存地址空间供系统使用，因此只能支持 2 GB 的用户模式虚拟地址空间。为了使操作系统能够使用超过 16 GB 的内存，应确保 boot.ini 文件中没有 /3gb 参数。如果存在该参数，操作系统就不能使用超过 16 GB 的物理内存。

注意:

当"/PAE"参数应用于Boot.ini文件的时候，操作系统从双层线性地址转换转移到三层地址转换。额外的转换层提供对于超过4 GB的内存的访问。所以，如果"/3GB"交换机也随"/PAE"一同使用，那么操作系统可能因内存匮乏而求助于磁盘分页。这一步骤将对服务器性能产生负面影响。详细信息，请参阅"Windows 2000中的Intel物理寻址扩展（PAE）"：

表1总结如何根据可用的内存容量配置扩展内存设置。

等于或小于4 GB	4 GB至16 GB	大于16GB
/3GB参数	禁用/3GB	禁用/3GB
	启用AWE	启用AWE
	启用PAE（Boot.ini）	启用PAE（Boot.ini）

表2 总结各32位操作系统的最大物理内存支持能力

操作系统	最大内存支持能力
Windows 2000 Advanced Server	8 GB
Windows 2000 Datacenter Server	32 GB
Windows Server 2003企业版（32位）	32 GB
Windows Server 2003 Datacenter Server（32位）	64 GB

3. WIN2000 与 WIN2003 对AWE支持的差异

WIN2000 / SQL2000	WIN2003 /SQL 2005
必须运行于Windows 2000 Advanced Server 或 Windows 2000 Datacenter Server	必须运行于Enterprise版本以上
物理内存必须大于3GB, 否则不管 awe enabled 的参数设置如何，SQL Server 都将以非 AWE 的模式运行	理论上适用于所有内存配置
SQL Server实例不对所用的内存地址空间的容量进行动态管理如果可用物理内存大于 max server memory 选项的值，SQL Server 实例会锁定 max server memory 中指定的内存量。如果可用物理内存小于 max server memory 选项的值或如果尚未设置 max server memory 选项，SQL Server 实例只留下 256 兆字节 (MB)，而锁定所有其余的可用内存	可以动态地管理 AWE 映射内存（在 min server memory 和 max server memory 选项的约束内）以平衡 SQL Server 内存的使用从而满足总系统要求可以考虑设置 SQL Server 的 max server memory 以保证其他内存能用于运行在计算机上的其他应用程序
分配之后，直到 SQL Server 关闭才会释放 AWE 映射内存. Microsoft 极力建议在每次启用 AWE 时设置 max server memory 选项的值，并建议考虑服务器上运行的其他应用程序的内存要求。	因为可以动态地管理 AWE 映射内存,如果需要更少的资源，SQL Server 会将 AWE 映射内存返还给操作系统，以供其他进程或应用程序使用
SQL Server AWE 将忽略 min server memory。	min server memory 设置有效

4. SQL Server 启动AWE的配置:

操作步骤：

将"锁定内存页"权限赋于运行SQL Server的帐户。
gpedit.msc à计算机配置-->Windows 设置-->安全设置-->本地策略-->用户权利指派-->内存中锁定页面，添加运行SQL Server服务的用户。
网络数据吞吐量设置。如果在"网络连接"中选中了"最大化网络应用程序数据吞吐量"选项，则操作系统将在文件系统缓存中缓存应用程序的 I/O 页面，从而优先处理执行缓冲输入/输出 (I/O) 操作的应用程序。此选项可能会限制可用于 SQL Server 正常操作的内存。所以要改掉。
本地连接属性 à文件及打印机共享 à属性，如果选中了"最大化网络应用程序数据吞吐量"，请任选一个相应的其他选项。
1. 配置 awe enabled 选项
  
  方案一: SQL2005提供在管理器的配置, 如下图所示:
方案二: 使用存储过程sp_configure配置

sp_configure 将 awe enabled 选项设置为 1，然后重新启动 SQL Server。
sp_configure 'show advanced options', 1

RECONFIGURE

sp_configure 'awe enabled', 1

RECONFIGURE

sp_configure 'min server memory', 1024

RECONFIGURE

sp_configure 'max server memory', 6144

RECONFIGURE

3：如果启用 Address Windowing Extentions (AWE) 支持，则单个 SQL Server 2000 实例最多只能使用计算机上 50% 的物理内存。

注意：该问题只发生在运行于基于 x86 或基于 x64 的计算机上的 32 位版本的 Microsoft SQL Server 2000 Service Pack 4 中。

例如，如果您的计算机具有 16 GB RAM，且启用了 AWE，则 SQL Server 2000 的单个实例只能访问 8 GB RAM。

解决方案

修复程序信息

要获得此修复程序，请访问下面的 Microsoft 网站：

http://www.microsoft.com/downloads/details.aspx?displaylang=zh-cn&FamilyID=7C407047-3F1F-48B8-9E4C-DC32875E1961 (http://www.microsoft.com/downloads/details.aspx?displaylang=zh-cn&FamilyID=7C407047-3F1F-48B8-9E4C-DC32875E1961)

重要说明：对于基于 x64 和基于 x86 的计算机，只存在一个下载。该修复程序使用将确定平台和安装正确文件的安装程序技术。

先决条件

SQL Server 2000 Service Pack 4。

要获取 SQL Server 2000 Service Pack 4，请访问下面的 Microsoft 网站：

http://www.microsoft.com/technet/prodtechnol/sql/2000/downloads/default.mspx(http://www.microsoft.com/technet/prodtechnol/sql/2000/downloads/default.mspx)

重新启动信息

应用此修复程序后，不必重新启动计算机。

注册表信息

不必更改注册表。

修复程序文件信息

此修复程序仅包含解决本文列出的问题所必需的文件。此修复程序不包含将产品完全更新到最新版本所必需的所有文件。

此修复程序的英文版具有下表中列出的文件属性（或更新的文件属性）。这些文件的日期和时间按协调通用时间 (UTC) 列出。当您查看文件信息时，该时间将转换为当地时间。要了解UTC 与当地时间之间的时差，请使用"控制面板"中"日期和时间"工具中的"时区"选项卡。

适用于基于 x86 计算机的 SQL Server 2000 32 位版本

日期时间版本大小文件名 ----------------------------------------------------------- 14-May-2005 01:11 2000.80.2040.0 9,150,464 Sqlservr.exe

适用于基于 x64 计算机的 SQL Server 2000 32 位版本

日期时间版本大小文件名平台 --------------------------------------------------------------------- 14-May-2005 01:11 2000.80.2040.0 9,150,464 Sqlservr.exe x86

http://zbqlh.blog.163.com/blog/static/3638022201171511435685/

ccrong

关注

1
点赞
踩
5

收藏

觉得还不错? 一键收藏
0
评论
金蝶K/3产品性能稳定性优化指导手册

金蝶K/3产品性能稳定性优化指导手册 2011-08-15 11:43:05| 分类： ERP应用|字号订阅金蝶K/3产品性能稳定性优化指导手册(常见问题)（V3.0）?金蝶软件(中国)有限公司研发中心K/3产品事业部.设计部解释目的本手册在于指导技术支持人员、分支机构实施服务人员和客户处理K
复制链接

扫一扫