金蝶K3产品性能稳定性案例集.docx
- 文档编号:10426228
- 上传时间:2023-05-25
- 格式:DOCX
- 页数:69
- 大小:829.22KB
金蝶K3产品性能稳定性案例集.docx
《金蝶K3产品性能稳定性案例集.docx》由会员分享,可在线阅读,更多相关《金蝶K3产品性能稳定性案例集.docx(69页珍藏版)》请在冰点文库上搜索。
金蝶K3产品性能稳定性案例集
金蝶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.1K/3数据授权导致F7、单据查看、序时簿查看、选单关联速度很慢(工业类型账套)33
3.2.2出入库单据丟失34
3.2.3应收冲应付的单据生成凭证时导致数据库服务器死锁34
3.3.K/3V10.1性能问题案例34
3.3.1K/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
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
1.性能案例总体分析步骤
作为服务人员或实施人员,遇到客户的性能或稳定性问题时,请您不要着急,可参考如下步骤:
第一步:
引导客户了解具体问题;
第二步:
收集用户计算机信息;
自动收集服务器的事件日志,系统配置环境,操作系统版本等信息。
对与中间层服务器使用MPSRPT_Alliance_X86.EXE,对于数据库服务器使用MPSRPT_SQL.exe
工具位置:
MPSRPT_Alliance_X86.exe:
MPSRPT_SQL.exe:
如果现场问题需要总部支持的话,请使用上面的工具收集计算机的信息。
MPSRPT_SQL.exe运行后:
将会生成CAB文件,CAB会被生成在%systemroot%\MPSReports\SQLServer\
通常名字为%COMPUTERNAME%_SQL_MPSReports_XXXXXXXXXX_X.CAB。
(%systemroot%为Windows系统目录,比如C:
\WindowsorC:
\Winnt)
第三步:
判断是否网络问题,网络是否丢包等;由于病毒也是导致网络不稳定的一个原因,所以需要确定是否存在病毒;
建议:
网络推荐至少百兆网,全交换更好,推荐采用域结构,域服务器不要跟K/3服务器装在一起。
关于客户端和中间层不在同一域的问题,最好是配置客户端和中间层在同一域中,如果无法配置在同一域中。
可以修改组件服务中COM+组件的安全验证选项,如下图所示。
降低身份验证级别,能够在一定程度上改善调用中间层组件的性能。
附丢包率判断方法:
丢包率
通过客户端192.168.1.205,对中间层192.168.1.2,做如下操作:
(1)ping192.168.1.2–n1000–l2000
(2)pathping192.168.1.2
(1)time<1ms,sent=1000,received=999,lost=1(0%loss),Min=0ms,Max=9ms,Average=0ms
(2)for25secondstatistics中,
Pct=Lost/Sent=0%
即:
无丢包,丢包率0%.
第四步:
检查用户操作系统,如果是WINDOWS2003是否安装SP1,SQL2000是否打上SP4,请参照文档:
第五步:
定期维护和优化帐套,具体参见《金蝶K/3产品性能稳定性优化指导手册》。
第六步:
数据库表结构不合理,常见有:
Ø二次开发的表没有索引,造成性能隐患;
Ø不恰当的触发器和游标的使用,大数据表缺少聚集索引。
第七步:
寻找合适的补丁。
第八步:
与K/3开发部沟通,获得解决方案。
2.总体通用性能问题案例
本章主要对目前K/3系统在实际运行过程中遇到的一些通用性能案例进行介绍分析,具体内容按照网络、数据库、中间层、客户端层次结构来组织。
2.1网络与Citrix性能问题案例
2.1.1通用案例1—-网络架构问题
1、问题描述:
使用某一台交换机的所有使用K/3的机器(该交换机为第三级),出现客户端挂起的情况,K/3系统使用不稳定。
2、问题分析:
1)将出现问题的客户端机器的网线拔掉,过5-10秒再重新插入后,系统挂起现象解决,K/3可以正常使用;
2)通过PINGxxx.xxx.xxx.xxx–l1024–n100后,发现统计信息中存在丢包的现象;
3)接到另外一台交换机(该交换机为第一级)上后,发现K/3系统使用稳定,但总体性能下降,分析原因为网线的距离过长,从而导致了数据传输上的损失
3、解决方法:
重新部署网络架构
2.1.2通用案例2—-病毒导致网络问题
1、问题描述:
所有机器使用K/3同一个功能时,快的时候6-7秒,慢的时候要1分多钟(已经排除数据量和查询数据范围的问题)。
2、问题分析:
客户端网络使用光纤接入,使用PINGxxx.xxx.xxx.xxx–l1024–n100检查,发现都存在丢包的现象,但如果整个网络只存在一台计算机时,系统使用正常。
怀疑是病毒原因。
使用杀毒软件进行杀毒后,发现有多台客户端有病毒。
由于感染病毒后会疯狂发包,导致路由器NAT连接很快占满,从而导致性能问题。
3、解决方法:
丢包掉线可能原因:
1)局域网中的某台或者多台机器感染了病毒,在疯狂发包,导致路由器NAT连接很快占满。
建议方案:
试着断开某台交换机,进行逐一排查,进行隔离杀毒,找到该台机器,将其隔离。
2)可能是交换机长时间没有重启其内存已用光,导致交换数据速度缓慢,或受网络风暴影响导致阻塞或交换机的某一个或几个接口模块损坏,或交换机故障引发的网络内暴。
建议方案:
关闭局域网内所有交换机4-5分钟后,重新接通电源,观察网络是否
恢复正常。
2.1.3通用案例3—-Citrix服务端内存问题
1、问题描述:
某集团在培训练习过程中(同时登陆的有40台机器,使用的CITRIX登陆),发现系统使用速度非常慢,在一段时间不操作机器的情况下,K/3客户端会报错误,后自动退出。
服务器配置为:
CPU为Xeon5160双核3.0G,内存为1GB,Citrix服务端耗用内存2GB多。
2、问题分析:
一般去除操作系统和Citrix服务器的的消耗,每个CitrixK/3客户端大概耗用50兆左右内存。
因此对于30个客户端的并发,可能需要30*50+500(操作系统和Citrix服务器的消耗)=2000(M)的内存。
如果内存不足时,操作系统将会自动进行换页处理,这时需要空余的磁盘空间作为交换文件,但也会极大影响程序的性能。
3、解决方法:
增加服务器内存(建议加到4GB)。
2.1.4通用案例4—-应用Citrix打印问题
1、问题描述:
某客户在应用CITRIX进行K/3应用的过程中存在下面问题:
问题一:
打印的单据打印到了别的客户端的打印机上
问题二:
HP1020,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终端GUI与WEB模式都不能打印。
在服务器上安装HP1020打印驱动,如下图配置:
在客户端按上设置即可,重新登陆.
问题三:
缺省纸张的问题。
1)必须使用本地打印驱动,即在服务器上安装客户端打印机的驱动,而不是使用通用驱动打印。
ManagementConsole—>PrinterManagement—>Properties—>Drivers—>NativeDriversonly(如无特殊打印机最好选择此项),缺省为:
Useuniversaldriveronlyifnativedriverunavailab
2)启用设置套打格式。
3)纸张的设置可在客户端的打印机上设置。
请检查以下设置:
ManagementConsole——>PrinterManagement——>Properties——>Printers——>inheritclientprinter'ssettingforkeepingprintereddocuments是否勾选?
选择该项,可延用客户端的打印设置。
2.2数据库性能问题案例
2.2.1通用案例1—-数据库日志文件过大
1、问题描述:
客户数据库的LOG文件非常大,达到680M(实体文件是2.6G左右),做过数据库压缩、数据库剥离,重新建了日志文件后速度变快,如此反复了两次,现在又慢了下来。
导致客户端运行速度非常慢,严重时连一个客户端都进不去。
2、问题分析:
该问题是由于没有把数据库的故障还原设置为简单,导致数据库LOG文件很大,影响数据库性能,可以对数据库做一些优化设置来处理。
3、解决方法:
1)把数据库的故障还原设置为“简单”(注意:
该故障还原模式下数据库不能进行事务日志备份)。
2)数据库分离附加〔采用日志分离的方式减少日志文件的大小:
首先在“SQLSERVER企业管理器”分离数据库,然后删除此数据库的日志文件(*.ldf),最后再重新附加数据库〕。
3)数据库收缩(在数据库服务器进行数据库实体收缩)。
4)检查二次开发的触发器和存储过程是否存在批量更新数据库不严谨造成日志文件增大(关键)。
5)执行下面附件的SQL,核对一下是否有的表占用的空间过大没有释放,可以优化一下此表的索引结构,保存此表后可以把过多的空间释放出来。
2.2.2通用案例2—-数据文件大小不正常
1、问题描述:
SQLServer的数据文件变得不正常,大小和客户的数据量从经验上很不相符,这种异常会很大地影响系统性能,还有可能引发错误。
2、问题分析:
该问题主要是由于有些表没有建立聚集索引引发,需要运行工具来分析检查。
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数据库,可以采用下面几种方式,最好做一个定期执行计划
方法一
◆重启SQLSERVER服务
◆ALTERDATABASEtempdbMODIFYFILE(NAME='tempdev',SIZE=需要收缩的大小)
◆ALTERDATABASEtempdbMODIFYFILE(NAME='templog',SIZE=需要收缩的大小)
方法二
◆sp_spaceused@updateusage=true
◆dbccshrinkdatabase(tempdb,'百分比')
方法三
◆dbccshrinkfile(tempdev,'需要收缩的大小')
◆dbccshrinkfile(templog,'需要收缩的大小')
4、建议
1)将tempdb数据库文件的初始大小设置为合理的大小,以避免当需要更多空间时文件自动扩展。
如果tempdb数据库扩展得过于频繁,性能会受不良影响。
2)如果需要使用数据库文件按百分比增长,将文件增长增量百分比设置为合理的大小,以避免tempdb数据库文件按太小的值增长。
如果文件增长幅度与写入tempdb数据库的数据量相比太小,则tempdb数据库可能需要始终扩展,因而将妨害性能。
3)最好设置数据库文件的增长方式为按指定的字节数方式,建议设置为200MB。
4)将tempdb数据库放在快速I/O子系统上以确保好的性能。
在多个磁盘上条带化tempdb数据库以获得更好的性能。
使用文件组将tempdb数据库放在除用户数据库所使用的磁盘之外的磁盘上。
2.2.4通用案例4—-数据库服务器硬件问题
1、问题描述:
物流的出入库单据都不能保存。
2、问题分析:
根据现场描述的情况,进行同样的操作,发现业务能正常处理,怀疑数据库服务器存在问题,让现场提供数据库服务器的事件日志和数据库日志,发现存在下面的错误信息。
事件日志:
Envetid:
17055
Envetid:
17052
错误:
823,严重度:
24,状态:
2
I/Oerror(badpageID)detectedduringreadatoffset0x0000000224a000infile'E:
\DataBase\AIS20050529165714_Data.mdf'.
Eventid:
19011
SuperSocket信息:
ConnectionListen(Shared-Memory(LPC)):
Error5。
事件ID(4194)的描述(在资源(COM+)中)无法找到。
本地计算机可能没有必要的注册信息或消息DLL文件来从远程计算机显示消息。
您可能可以使用/AUXSOURCE=标识来检索词描述;查看帮助和支持以了解详细信息。
下列信息是事件的一部分:
组件ProgID:
服务器应用程序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
Envetid:
4193
Source:
msdtc
资源管理器执行了恢复操作并调用了ReenlistmentComplete,说明恢复过程已完成。
但至少一个通过资源管理器登记的事务的状态仍然是“不确定”
数据库:
2006-03-1708:
53:
28.64spid16表错误:
对象ID1384001053,索引ID0,页(1:
41775)。
测试(IS_ON(BUF_IOERR,bp->bstat)&&bp
2006-03-1708:
53:
28.64spid16表错误:
对象ID1384001053,索引ID0,页(1:
41775)。
测试(IS_ON(BUF_IOERR,bp->bstat)&&bp
2006-03-1708:
53:
28.65spid16表错误:
IAM页(1:
41775)(对象ID1384001053,索引ID0)超出了此数据库的范围。
使用DBCCCHECKDB出现下面信息:
2006-03-1712:
57:
55.95spid15表错误:
分配页(0:
67108864)的IAM_PAGE页首结构值无效。
类型为0。
请检查该页上的类型、对象ID和页ID。
3、解决方法:
根据上面的日志,查看微软网站相应的说明,由于使用DBCCCHECKDB存在无法修复的情况,这种情况可以排除是数据系统本身的原因,因为在硬件系统方面。
建议客户将服务给硬件提供商检查,检查后发现导致该问题的原因在于硬盘系统存在问题。
微软网站关于错误的说明文档见:
2.2.5通用案例5—-系统整体运行速度非常慢
1、问题描述:
客户反馈,当前网速为10M,整体系统运行速度非常慢,例如审核一张单据,从查到该单据,到审核完毕,时间在5分钟左右才可以完成,中间仍会经常断掉,需要重新登陆,已经制约了部分业务的进行。
2、问题分析:
1)K/3系统数据全部都在一个数据库中,长期以来,积累了大量的数据,包括:
仓存管理业务数据、作业成本数据、财务数据等等信息,都在里面长期存放,目前数据库已有8G(包括日志文件);
2)网速目前为10M,可能对此有部分影响,但已满足系统运行要求;
3)作业成本的数据表设计是否存在性能问题,账套一直在无限地增加数据量,这里讨论是一种加速度的增加,即每年账套数据量增加呈递增状。
3、解决方法:
1)请事先备份好数据(如果数据是完全备份,不是增量备份和日志备份),再把数据库属性在企业管理器里的故障还原设置为“简单”;
2)执行【BACKUPLOG数据库名withnolog】截断日志;
3)打开“企业管理器”点击右键->所有任务->收缩数据库;
4)在中间层优化账套(打开“账套管理”->数据库->优化账套),或者通过建立索引维护计划进行优化账套;
5)用户操作建议:
单据查询时,设置精确的过滤条件,以提高查询效率,尽可能避免由于大数据量的读取IO操作导致
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 金蝶 K3 产品 性能 稳定性 案例