K3客户性能问题工作指导手册V

《K3客户性能问题工作指导手册V》由会员分享，可在线阅读，更多相关《K3客户性能问题工作指导手册V（39页珍藏版）》请在装配图网上搜索。

1、 K/3客户性能问题工作指导手册 第1版K/3客户性能问题工作指导手册 金蝶软件(中国)有限公司 此文档有研发中心K/3总体设计组解释38第一章： 前言3Y面临的问题3Y解决问题：手册的目的31，指导分支机构服务人员和客户处理现有性能问题42，指导实施人员在实施中避免将来可能发生的性能问题43，理解性能问题，提高工作能力4Y阅读对象4Y手册的组织和阅读方式4Y一些关于本手册的说明5由于此手册牵涉一些K/3在技术方面的细节，为了防止有些人用意不良，断章取义来攻击K/3和公司，请注意保密5本手册的是从研发人员的角度写的，目的是为了和分支机构一起解决客户的性能问题，但是可能存在偏颇，欢迎提供建议和意

2、见,同时此手册不止是针对性能问题，对一些常见的非功能问题也作了描述5本手册是K/3总体设计组半年来处理客户性能问题的一些经验的总结，不是一个逻辑严密的体系，当然文字方面的功底可能也不是太好（请谅解程序员的作文水平,写此手册的时候才发现自己WORD的操作技能太差），我们努力写的更好，但是能力有限，欢迎指正5第二章： 性能问题概述6第一节.客户性能问题的表面现象:6一.某些局部功能速度太慢，不能满足日常的业务要求6二.系统突然出现全面的死机现象7三.系统所有功能频繁出现等待现象，且等待时间较长8四.有规律的在某个时段系统速度变慢8五.某些客户端功能好像比正常的速度慢一点8第二节.影响系统运行性能的

3、主要因素:8一.数据量9二.并发数9三.硬件配置和软件系统配置10四.二次开发10五.数据授权11第三节.客户性能问题的本质分类:11一.非K/3软件问题11一)网络问题11二)硬件配置12三)软件环境12四)实施和应用问题12二.K/3软件问题13一)架构级的问题13二)局部功能算法问题13第三章： 性能问题处理策略和处理流程13一.性能问题所涉及的角色14二.性能问题的处理策略14Y尽量自力更生14Y消防员和消防规则15三.客户性能问题的处理流程16四.性能问题处理相关的工作产品16第四章： 性能问题分析方法和辅助分析工具17第一节.方法论17Y排除法17Y像医生看病17第二节.辅助分析工

4、具17一.Windows任务管理器18一)使用方法18二)数据库服务器CPU曲线的一些典型结论191，CPU持续100%一段时间192，CPU大多数时间保持在40%以上193，良好的CPU状态20三)判断数据库内存是否够用的一种简单方法20二.组件服务20一)使用方法20二)如何找到正在执行的资源耗用多的组件22三)如何判断中间层的阻塞22四)关于STA模式COM+线程数限制问题22三.SQL Server的事件探查器（SQL-PROFILE）22一.使用方法22二.一些使用技巧28三.主要跟踪数据的解释29四.数据库死锁和阻塞监测工具29第五章： 性能问题的解决方法31第一节.一些观点31Y

5、速度是相对的31Y解决性能问题需要得到客户的配合和支持31Y积极面对，尽早解决31第二节.解决方法:31Y升级硬件31Y改变和调整应用方式32Y寻找合适的补丁32Y优化数据库索引32Y与研发沟通，获得解决方案32第六章： 优化性能的系统维护策略和一些常见问题32第一节.优化性能的系统维护策略32一.收缩数据库32二.优化账套34三.培训操作用户养成良好的操作习惯34四.根据用户的业务特点做适当的索引优化34第二节.一些常见问题35一.数据库服务器内存居高不下35二.SQL-SERVER能够使用多少物理内存35三.SQL-SERVER事务日志超长36四.SQL-SERVER数据文件大小不正常36

6、第一章： 前言本章主要描述K/3现在面临的性能问题的现状、手册的目的、阅读对象、手册的组织方式以及阅读方法Y 面临的问题毋庸置疑，K/3现在已经成为国内最优秀的ERP软件，但是随着K/3产品的不断壮大，K/3产品的功能越来越强，在我们的产品不断实现更加强大功能的同时，另外一个问题却慢慢浮现出来，这个问题就是性能问题。问题以前也存在，但是现在暴露了出来，显得极为突出，客户在抱怨，分支机构在抱怨,性能问题已经严重影响了公司和K/3的声誉。从一种角度这也说明了K/3的优秀，K/3已经有了广大的客户群，同时客户在K/3系统运行了大规模的业务。当然我们要勇敢正视这个问题，积极的去解决问题，从管理层到研发

7、的每一个人现在都在重视和解决这个问题。Y 解决问题：手册的目的软件尤其是企业应用软件的性能问题，可以说是一个比较复杂的问题，软件本身，软件的运行环境，实施，客户应用方式都可能引发问题。同时解决这个问题也绝不是能和修改一个BUG一样，一次性解决，这个问题会成为一个长久的问题，这不是说我们金蝶一次性做不好，我想任何软件公司都不可能做到。当然研发会全力以赴，精益求精，做好软件的每一个细节，把K/3做到极致。同时我们实施人员，服务人员也要了解性能问题，掌握一些技能，处理非软件本身的性能问题，只有大家一起努力，才能让客户满意，让每一个客户的K/3系统稳定高速的运行。写这个手册的目的就是希望能够让广大实施

8、服务人员以及客户更好的了解性能问题，掌握处理问题的策略，方法，在以后的工作中有效的解决和处理性能问题对于性能问题，我想我们应该这样说：我们一直在努力，我们也必须这么做。记得以前看过一篇关于SAP开发管理的文章，其中SAP的一位开发管理人员说过一句话，原话已不记得，但是大概的意思是，他们的程序员为提高每一个功能点的速度每天在努力，这反映了SAP的产品尽善尽美的追求，同时我想这也说明性能问题不是一天就可以解决的。归纳起来本手册的主要目的和作用有以下几点：1， 指导分支机构服务人员和客户处理现有性能问题随着K/3客户群的壮大，客户应用规模的不断扩大，现在有性能问题的客户不断增加。面对性能问题，分支机

9、构和客户不知道如何下手处理，在半年多的客户支持中，通过与分支机构和客户的直接接触，发现：有些分支机构不知道性能问题应该找那个角色来支持；即使找到了研发，也存在严重的沟通问题，在描述问题时很笼统；有些问题其实很容易解决，但是缺乏一定的知识和能力，也需要研发来解决；希望能通过阅读此手册，让分支机构和客户对性能问题有一定的认识，具备一定的处理问题的能力，掌握与研发交流的技巧，有效的解决解决现有性能问题。2， 指导实施人员在实施中避免将来可能发生的性能问题有些性能问题本身就是实施不当引起的，有些问题可以在实施中通过变通的方式加以避免，在实施的时候就应该对客户的数据量和并发做一定的预计，在做实施方案时考

10、虑性能问题。实施人员通过学习此手册希望能够在实施中对可能存在的性能问题有一定的指导意义。在半年的客户支持中发现有些项目在实施阶段就有了性能问题，所以在实施中避免将来可能发生的性能问题有很重要的意义。3， 理解性能问题，提高工作能力正如前面所说，性能问题将会是一个应用软件长久存在的问题，所以掌握一定有关性能问题的知识,深入理解性能问题，对提高工作能力有很大的帮助，更好的帮助顾客成功。Y 阅读对象本手册的主要阅读对象是技术支持人员、实施人员、客户服务人员、有一定技术能力公司授权的客户系统管理员。Y 手册的组织和阅读方式第一章就不用说了，前言对于所有的手册都差不多，一带而过就可以了。第二章是对性能问

11、题的一个概述，手册的重点不在像教课书咬文嚼字说明概念，主要是根据工作经验，说明了K/3客户性能问题的表现，影响K/3系统性能的主要因素，K/3性能问题的本质和分类。在以往的工作中往往发现向客户和分支机构询问客户系统的表现是一件很困难的事，有的甚至就是说“慢“ 或者“死机“，就好像你告诉医生说我病了一样，研发人员从这样的描述中得到的信息很少，很难进一步定位和分析问题.通过学习本章希望对性能问题有一定的深入认识，便于以后在工作中的交流。很多客户的性能问题并不是由于软件本身引起的，至少不是绝对的，理解影响系统性能的因素和从本质上认识性能问题的分类，可以就地解决一些性能问题。对于此章请认真阅读，相信这

12、些内容都很简单，但是系统实用的描述对于你还是有一定的用处。第三章主要说明了对于性能问题的处理策略和处理流程，让所有相关人员理解性能问题处理策略和了解处理流程，确保我们知道如何有效的利用合理的流程和资源高效的解决问题，这些与技术无关，但是对于分支机构和客户来说了解这些策略和流程能提高工作的效率。花点时间在这一章应该有好处。第四章主要对一些常用的性能监测工具的使用做了说明，同时对如何分析性能问题作了描述，希望通过这一章的学习能掌握分析定位性能问题的方法，这是本手册的重点里面的内容在手册中写了很多，但是实际很少，这就是技术手册的尴尬。第五章讲述了对于各种性能问题的解决方法和策略，这里有技术和非技术的

13、解决策略，希望对分支机构自力更生解决客户的性能问题和在与研发交流中有帮助。第六章是一些技术方面的专题和系统关于性能方面的维护策略，这些问题可以让你更深刻的了解K/3系统，让你在客户那儿游刃有余。Y 一些关于本手册的说明 由于此手册牵涉一些K/3在技术方面的细节，为了防止有些人用意不良，断章取义来攻击K/3和公司，请注意保密。 本手册的是从研发人员的角度写的，目的是为了和分支机构一起解决客户的性能问题，但是可能存在偏颇，欢迎提供建议和意见,同时此手册不止是针对性能问题，对一些常见的非功能问题也作了描述。 本手册是K/3总体设计组半年来处理客户性能问题的一些经验的总结，不是一个逻辑严密的体系，当然

14、文字方面的功底可能也不是太好（请谅解程序员的作文水平,写此手册的时候才发现自己WORD的操作技能太差），我们努力写的更好，但是能力有限，欢迎指正。在写此手册的时候我最痛苦的就是如何组织内容的结构，就像一个医生无法把自己的治病经验一下子描述清楚，所以很多问题都翻来覆去的出现在不同的章节，我的原则就是宁可罗嗦，也要清楚，也许这样反而不清楚。第二章： 性能问题概述本章主要描述了什么是性能问题、性能问题的表面现象、影响K/3系统性能的因素、本质上性能问题的分类什么是性能问题: 在这儿不想从其它的书上抄一段文字来定义什么是性能问题。当客户突然对你说:”我们的K/3死机了”、“你们K/3的销售出库单保存太

15、慢了”，“老是出现中间层切换重试”、”我们不能出库了”、“我们的客户在排队” 这就是性能问题。当出现这些问题的时候，你可能告诉客户重启服务器,一段时间后客户已经对此厌烦，如果不及时处理，我们K/3的声誉和公司的声誉在客户那儿可能就直线下降，作为服务人员和实施人员的你很着急，这些情况我都遇到过，这时候我们首先作的就是具体的了解问题，向客户询问系统的情况，这儿存在一个在软件行业普遍存在的问题那就是对问题的描述和沟通（告诉别人的和要告诉别人的误差往往很大），所以你要引导客户，询问具体的情况，当然如果你在现场那更好，即使你在现场，你如果不能处理，向研发寻求支持，你也要能够和研发很好的沟通，否则研发人员

16、就只能到现场去处理，浪费不必要的资源。你可以从客户那儿得到对性能问题的表面现象的描述，但是你要尽可能按照下面的分类引导客户描述问题，这样你能更快得到更准确的信息。但是真正的问题隐藏在背后，我们需要把了解到的表面现象转换为问题的本质。同时要了解影响性能问题几种主要因素，这些都有助于迅速的定位和分析问题。第一节. 客户性能问题的表面现象:当客户出现性能问题时，他们给你的描述可能是五花八门，有的能够描述的很清楚，有的就说得很笼统，这取决于客户系统管理员对系统的了解和能力，但是你要引导客户和你的沟通，尽量得到一个比较准确的描述。根据客户对现象的描述可以得到一些初步的解决方案。以下是K/3总体设计组半年

17、来从客户支持中的到一些现象的汇总和归纳，在每个现象中会给出一些初步的解决方法，当那些初步的解决方法无法解决时需要深入了解客户的情况，做进一步的分析，然后给出解决方案，这会在后面的章节中给出进一步的说明。所有现象没法做一个逻辑严密按照某一个分类依据的完全分类，各种表象可能是交错的重叠的，希望我们能在后续的版本中做进一步的分类。一. 某些局部功能速度太慢，不能满足日常的业务要求客户如果能给出这样的描述是最好的，证明他已经很明确的定位到问题的所在。这些慢的功能点大多数是一些查询和计算功能，如大数据量的物料（商品）收发汇总表查询，期末结账，成本计算等功能。这些慢的功能由于使用过多的系统资源，很可能会引

18、发整个系统的瘫痪，导致所有其它功能点都变得很慢，甚至出现死机（实际是得不到系统资源，处于长期的等待中）现象。对于大数据量的报表或序时簿查询，你要询问客户是否可以作适当的过滤，这种查询和大多数的计算型功能是否可以不在业务高峰期做，如果能够和客户达成一致的意见，从应用方式避免是最好的，有些客户尤其是不熟练的客户经常会不做任何过滤做大数据量的查询。有些查询可能已经做过优化，可能在现有架构下已经没有办法做更进一步的优化，所以需要和客户沟通，从应用方式避免。你也可以寻求技术支持或者从技术支持网站查询相关补丁，如果是一个通用的问题，可能已经有了相关的补丁，这样的话你打上相关补丁可能就很容易的解决了问题。你

19、要想到K/3数以万计的客户，你的问题可能在其他客户那儿早就发现了，早已经获得解决。对于期末结账、成本计算、MRP运算等功能、大多数的查询功能类的性能问题，大部分问题都可以获得补丁或升级软件来解决，如果确实不能解决，或者不能说服客户改变使用方式，从客户的角度也确实需要更快的速度才能满足业务要求，应该迅速提交研发部门，研发来研究是否可以做优化。这样的每次优化，一点一滴的优化，最终就会使K/3全面优化。也许你要说研发为何不能未卜先知，我们已经作了很多，我们也一直在努力，但是客户的情况千差万别。 如果这些慢的功能点是票据和凭证的日常业务操作如保存，审核等，如果没有相关的补丁解决，应该迅速提交研发，这些

20、与客户日常业务密切相关的操作，没有任何理由，必须要能满足客户的要求。二. 系统突然出现全面的死机现象经常听到客户说他们的系统死机了，或许有些分支机构的人说是死锁了，关于这些说法后面的含义可能差别很大。当听到这种说法时需要进一步的询问详细情况。最好处理的情况，最简单的情况是网络问题，当然你首先要肯定网络的畅通，不过出现这种问题时一般会在客户端报告明显的网络错误。在这儿要注意的一种情况就是如果客户的中间层和数据库服务器是分开的，要确保这两台机器能够互通，这里常出现的一个问题就是ip地址和计算机名不匹配，也就是说，在hosts文件中记录的IP地址和计算机名称不匹配，假如数据库服务器记录了错误的信息，

21、就会造成在客户端报一个“ 定义的应用程序和对象错误“等错误，但实际是中间层服务器可以访问数据库服务器，但是数据库服务器无法访问中间层服务器。在这时候要确保网络中IP地址和计算机名称的匹配，保证地址解析的正确性。但是大多数情况是客户端提示“调用程序忙，切换到”，“正在调用中间层”等提示，这些提示本质上都是一样，或许你等一段时间（几分钟）系统又开始响应，这种情况就是和下面第三种情况描述的一样，或许你等了几十分钟也没有反应，实际上你不可能等那么长的时间，这时候你认为是死机了，要么你不停的切换重试，可能认为鼠标点的越快，系统会反应的更快（这不是笑话，在有一家客户那儿他们把回车键用重物压着，达到不停的切

22、换重试的效果）,要么你强行中断客户端程序。之所以分为两种情况，是由于引发这两种情况的原因有些差异。引发这些情况的原因主要有两种，第一种原因是服务器硬件资源不足，如果中间层和数据库部署在同一台服务器，或者数据库服务器配置偏低，这就会导致在数据量大和并发多的情况下系统资源不足，这时候你可以看看服务器的CPU表现，如果CPU资源长期达到40%以上，这表明CPU资源已经严重不足，如果CPU达到100%,则是某一个功能独占了数据库服务器CPU资源；第二种原因是数据库阻塞，此时数据库数服务器CPU耗用很低，这种情况下可能有些客户端的有些功能模块还可以用。对于第一种情况，当然软件的原因不能完全排除，但是这时

23、候硬件的提升可能是必要的,如果是CPU达到100%的情况就需要优化那个独占CPU的功能点。对于第二种情况，软件的原因是主要的，需要从软件本身的改进来避免。第一种原因可能更多引发第三种情况，第二种原因可能更多的引发所谓的死机。看了上面的描述你就会觉得此手册在内容组织方面显得有些混乱，我也感觉到有些没有条理，但是有些不好做，努力吧。三. 系统所有功能频繁出现等待现象，且等待时间较长在上面一种现象中已经对这种现象作了一些说明，其实之所以单独来描述，主要是说明此种现象下需要提升硬件资源。如果系统所有功能点都很慢，且频繁出现，但是每次都在几分钟之内能够响应，这时候如果数据库服务器的CPU耗用持高不下（长

24、期在40%）以上，这就说明数据库服务器的硬件资源尤其是CPU资源严重不足。简单分析原因，这可能是数据量大，并发较高。不过提升硬件对客户可能是一件很难接受的事，所以最好在实施中能够有预见性的避免。在以后的章节中会对硬件的配置给出一个经验性的推荐.当然这种现象的发生软件也需要改进，但是改进的效果可能不是太明显，改进的难度可能比较大，改进的周期可能会比较长。四. 有规律的在某个时段系统速度变慢大多数是月末，或者某段业务高峰期。在发生问题的时段可能会是某一个计算型功能如结账操作耗用系统资源太严重，或者是并发程度高引发系统资源不足.实际上是上述三种现象由于用户业务的特点没有在平时暴露出来。之所以分开来说

25、，是让你不要这种时段特性所蒙蔽.在这种情况下也比较难处理，客户认为平时都很好，可能拒绝提升硬件等建议.这时候建议客户改变使用方式也很困难，但是有时候从成程序角度也不是太好优化。此时我们只有这几方面的工作都努力了。五. 某些客户端功能好像比正常的速度慢一点有时候你会感觉到某些客户端的速度可能比你以往使用K/3慢一点，这种情况下大多数是客户端的硬件配置可能偏低，而且使用了WIN98操作系统，当然我们尽量会优化客户端代码，但是这种优化确实比较难做，所以有时候需要向客户解释，最好是能够成功说服客户适当升级客户端的硬件。这种情况下，有时候客户会拿其原先使用的系统的响应速度和K/3比较，这时候一个解释的理

26、由就是功能和性能是有矛盾的，K/3的功能相对一般的软件要复杂，这就会适当的降低性能。第二节. 影响系统运行性能的主要因素:系统运行性能表现不只是软件的问题，很多因素都影响系统的速度。最主要的因素有以下几种，当然这只是我们认为最重要的，不要从理论和逻辑的角度去考究它。对这些因素的分析，主要是让你对系统性能问题有全面的认识，曾经有分支机构的人对我说“我们以前怎么就没考虑过硬件问题呢”。所以有必要对这些因素做些说明，让我们的实施人员和服务人员有时候更好的了解问题和处理问题。一. 数据量一般来说，所有数据库应用软件的瓶颈都在数据库，数据量的大小对系统的运行速度有直接的影响。账套大小是衡量数据量大小的一

27、个简单实用的标准，但是注意要看数据库数据文件的大小，有时候SQL-SERVER日志会很大（关于这个问题在后面的常见问题中会作分析），但是数据文件并不大。有时候数据文件本身的大小也不能真实反映数据量的大小，如果一个表没有聚集索引，SQL-SERVER有时候会使这个表占用很大的磁盘空间，这个关于SQL-SERVER的问题也会在后面的得常见问题中做分析。在数据量的估计方面，有一些关键的基础资料和业务数据对整个账套的数据量可以作出一个大概的估计。基础资料中财务部分的科目，物流中的物料可以作为衡量数据量的一个主要依据，同时财务中凭证的多少，物流中仓库单据的多少可以用来衡量业务规模。当然有些特殊的客户由于

28、其行业和业务的个性太强，可能需要其他的业务数据来衡量其业务数据规模同样的功能，数据量越大其性能肯定会有所下降。我们的实施人员应该在实施准备阶段对用户未来的业务有一个估计，对用户数据量的估计可以作为配置服务器硬件的一个依据。数据量对数据库服务器的内存配置有直接的影响，从经验的数字来说最好是物理内存要大于账套的数据文件，如果账套数据文件小于1G,应该配置至少1G内存，如果账套数据文件大于1G,物理内存应该是数据文件的向上取整，例如账套数据文件为2.4G,那末应该配置至少3G内存。对于高于3G内存的配置，SQL-SERVER如果要是用超过2G的内存需要一些其它的配置，这在后面的常见问题会专题论述。数

29、据量对查询功能的性能有显著影响，这时候从应用方式方面要调整，尽可能少使用查询功能，在查询的过滤条件中尽可能使用严格的过滤条件。同时如果你具备一些关于数据库索引方面的知识，可以适当的通过索引来优化性能。有时候结转新账套也是一个解决数据累计量太大的手段，这需要实施中有良好的计划。研发一直和继续在大数据量应用方面研究和提升K/3的性能。 二. 并发数客户端的并发数量也是影响系统性能的一个主要因素，这不需要做太多的说明。客户端的并发数有时候是一个模糊的概念，这里要注意区分客户购买的模块数量和客户实际同时使用的客户端的并发数量，有的客户可能购买了100个客户端，但是可能只有大概20个处于同时使用的状态，

30、有的客户虽然购买了30个客户端，但是同时都在不停的使用。我们应该以同时使用的客户端作为依据。另一个值得注意的问题就是客户可能日常只有少量的客户端使用，但是在某个业务高峰期有大量客户端同时使用，最好是使用在业务高峰期的同时使用的客户端作为并发数量的依据。一般来说，和数据量一样，在实施中应该对客户端的并发数做一个预估。客户端并发数对硬件配置的影响最大。经验的结论，一般来说都应该使用专业的服务器，如果同时并发客户端超过20个就应该分离中间层和数据库服务器，对于中间层服务器保持每20个并发1个CPU,对于数据库服务器保持每10个客户端一个CPU.这些经验数字中的并发数量指同时不停使用的客户端的数量。并

31、发量主要影响服务器CPU个数的配置。对于并发量大引发的性能问题，可以考虑是否能把一些大数量的查询和计算功能放在非业务高峰期使用。三. 硬件配置和软件系统配置系统的规模不同，要求的硬件配置也不同，硬件配置对性能问题有直接的影响这不用多说。在硬件配置方面特别需要强调的是实施环节，一定要对客户的未来业务量有一定的预估，给出合理的硬件配置方案。在硬件配置的建议方面在上述两个问题中也结合数据量和并发数做了一定的说明。数据库服务器建议一定要刚开始就配置的比较高，且可以通过增加CPU和内存来升级，这样做得理由，第一，数据库是系统的瓶颈所在，第二，由于同一个账套无法分到多台服务器上，同时数据库也没有可以进行负

32、载均衡的集群方案（SQL-SERVER的集群都是为了提高可靠性），也就是说无法通过增加机器的个数来提升性能。对于数据库服务器的CPU和内存配置建议请看数据量和并发因素中的经验性结论。对于内存指的是物理内存而非虚拟内存对于中间层服务器来说，内存的配置不是太重要，有512M内存都可以，对于CPU个数的要求可以参照在数据量和并发数中的经验性结论。由于中间层的可扩展性，可以通过增加机器的个数来均衡负载，所以如果客户对系统投资预算不足的情况下可以不需要配置太好的中间层服务器。以后可以逐步扩展，实际上有512M内存的PC都可以做中间层服务器，可以通过增加机器来扩充。当然如果客户预算充足的情况下还是尽可能采

33、用专业服务器对于服务器的CPU有一个观点必须要说明那就是“1+12“，这个公式的意思是两个1G的CPU表现出来的性能远远大于一个2GCPU的性能，所以CPU的个数对服务器很重要对于数据库服务器的操作系统最好使用WIN2000 ADVANCE SERVER,实际上我是说的含蓄，我实际上是想说必须使用，当然如果你使用DATACENTER那肯定更好。同时SQL-SERVER最好使用2000企业版，记住是企业版。 由于K/3为了界面的美观和易用性等因素，导致对客户端硬件的配置要求相对要高一些，在配置差点的客户端性能表现要差些，我们会在后续版本中持续改进，但是由于客户端硬件配置差引发的性能问题往往很难改

34、进，改进的效果也不是太明显。这样的问题除非客户对性能要求很高，一般不会提出问题。当然如果现在采购的机器，肯定不会有太多的问题，但是如果客户使用原来采购的机器，那就不一样了。在实施中适当注意这个问题，有些情况下可以建议客户把好点的机器用作K/3的常用业务操作。对客户端的操作系统建议使用WIN2000 PROFESSIONAL,不要使用WIN98,WINDOWSME等。从使用方式方面建议客户不要在使用K/3时打开OFFICE系列软件。对于硬件配置尽可能在实施时防患于未然，否则如果在使用过程中出现问题时再提议客户升级硬件，可能会受到客户的抵制。四. 二次开发在这里绝对不是说二次开发做得不好，由于二次

35、开发的周期短，可能难免会有些疏忽，或者是对性能问题没有重视，二次开发功能有时候对系统资源尤其是数据库资源的耗用比较严重，导致系统出现阻塞，系统性能显著下降，在这里提出这个问题，就是希望二次开发人员在做二次开发时注意性能问题。对于大多数二次开发做的报表或查询建议数据库事务隔离级别使用Read UnCommitted ,具体的原因和技术细节请察看SQL-SERVER的帮助中关于事务隔离级别的说明。五. 数据授权启用数据授权会使系统的性能显著下降。在V10.2中会对数据授权做彻底改进。对于现有客户。我们的策略是通过调整使用方式来缓和，在数据授权时不要使用上级组权限检查选项，这样可以在很大程度上提高性

36、能，同时建议客户按照单个用户做数据授权，不要在用户组做数据授权，客户如果接受此建议，可以通过补丁方式提高速度。这些调整方式都可能导致授权工作量很大，可以通过手工修改数据库来提高效率。第三节. 客户性能问题的本质分类:客户反馈的性能问题和客户现场表现的性能问题，可能是五花八门。但是从本质上来说，可以分为两大类，K/3软件问题和非K/3软件问题。这种大的分类也不是绝对的，有时候多种问题混在一起，互相影响，很难区分。从本质上的分类有利于定位问题，发现问题，发现问题是解决问题的前提.每一大类又可以细分，问题的分类可以帮助你多种角度考虑和分析问题。一. 非K/3软件问题有些性能问题，不是由于K/3系统软

37、件本身绝对引起的。这些问题大多是K/3系统的运行环境问题，还有些是应用和实施问题。当然这不是说绝对的与我们的软件无关，而是说为了让K/3更好的运行，这些问题应该被解决和避免。这些问题可以分为以下几种。当你遇到性能问题时，或者在实施中为将来的性能问题作准备时，应该首先尽量避免和解决以下问题。因为这些问题不是我们软件的改进可以解决的。这些问题和前面讲的影响性能问题的因素有些是相同的。一) 网络问题如果出现有些客户端不能操作，并且明显的报错，与网络相关的错误，应该首先检查网络是否畅通，如果出现所有客户端都无法操作，要检查中间层和数据库服务器是否互通，并且两台服务器的IP地址和计算机名是否正确。这里要

38、说的一个问题是关于网络带宽，从目前的局域网来说，最少也有10M带宽，这样的带宽运行K/3应该没有问题，所以在局域网中的K/3系统，不要过多的怀疑网络带宽的问题。在局域网中需要关注的是网络的畅通和网络中地址解析的正确性。关于终端和WEB方面的网络问题，在此不予说明。这里还需要说明的是关于客户端和中间层不在同一域的问题，最好是配置客户端和中间层在同一域中，如果无法配置在同一域中。可以修改组件服务中COM+组件的安全验证选项，如下所示。降低身份验证级别，能够在一定程度上改善调用中间层组件的性能。二) 硬件配置硬件配置尤其是服务器的硬件配置问题，在很多客户那儿发现硬件配置偏低，这可能是 原先提供的硬件

39、配置建议有些不合理。通过观察服务器上任务管理器的性能监控可以大概判断硬件配置是否有问题。关于硬件配置的建议请看影响系统运行性能的主要因素。如何分析硬件问题请看后面的分析工具和分析方法。三) 软件环境软件环境主要是指数据库服务器的操作系统和SQL-SERVER版本，在此特别强调数据库服务器的操作系统尽量采用WIN2000 ADVANCE SERVER，SQL-SERVER要使用SQL-SERVER2000 企业版 SP3。关于客户端尽量采用WIN2000操作系统，不要使用WIN98。在此特别说明这些建议有助于K/3系统更加健壮的运行，不是说K/3系统不支持其他配置。四) 实施和应用问题有些性能问

40、题可以通过合理的实施和应用来避免，也就是说调整系统参数，使用方式让系统速度得到提升。在这儿用工业序时簿的查询为例来说明，对工业序时簿如果在过滤界面少选择要显示的列，尽可能使用严格的过滤条件，不要使用显示关联标志的系统选项都会一定程度的提高系统速度。这些问题往往需要对K/3系统有深入的理解。在手册的不同部分会有相关的内容，以后也会逐步补充，例如上一节中有关数据授权方式的调整就是一种。有一家客户在实施中物料编码中物料组很多，每个物料组下面的物料很少，导致F7功能基本无法使用，原因是树型控件(TreeView控件)在节点数量多的时候性能很差,过多的物料组节点是系统无法运行F7功能。但是BOM的分组很

41、少，每一个组下面的明细又很多，走了另一个极端，也导致系统的性能很差。在这里还要强调一点在实施中做的二次开发很有可能引发性能问题。对于有二次开发的系统一定要对二次开发作检查，看看是否有性能问题。二. K/3软件问题对于任何软件，都会存在问题，也会存在一定的性能问题。K/3作为一个复杂的企业应用软件，当然也会存在性能问题。对于K/3软件本身性能问题我们可以分为几种，这种分类对于实施和服务人员未必能够理解。做这样的分类的目的主要是让实施和服务人人员了解研发对于这些问题不同的处理方式和处理策略，以便有效快速，相互配合解决客户的问题。一) 架构级的问题有些性能问题是由于当时设计系统时没有考虑到数据量的规

42、模，当数据量达到一定规模后系统无法正常运行，同时这些问题从软件本身来说牵涉很多模块和代码，如果优化需要很大的改动和工作量。对于这样的问题只能通过在新版产品中改进，如果做补丁，稳定性很难得到保证。对于现有客户只能通过局部的改进和调整使用方式来解决,本质解决问题需要升级软件,如果最新版的软件还没有改进，而且问题比较普遍，研发会在新版中做改进。如数据授权问题就是这样一个问题，现在有很多客户反馈性能问题，所以在V10.2中做全面优化。二) 局部功能算法问题有些功能的算法可能不够优化，导致单项功能的性能较差，而且这种问题的优化比较局部，不影响其他模块和代码，对于这样的问题，一般会通过补丁方式来解决。大多

43、数的性能问题都是这种问题。对于有些局部的功能问题可以通过数据库索引的优化来提升性能。第三章： 性能问题处理策略和处理流程本章主要阐述当你面对客户问题时如何处理、如何与研发、技术支持做有效快捷的沟通在以往对分支机构和客户的支持过程中，发现分支机构对性能问题的处理流程不是太清晰，有了问题不知道如何处理，也不了解研发的处理策略。由于性能问题与功能问题有所不同，在此将对整个处理流程加以说明，以便日后能够有效快速的互相配合解决性能问题。一. 性能问题所涉及的角色为了更好地维护客户的利益，更快更有效地解决K/3的性能问题。目前K/3系统部对于K/3性能问题的处理流程进行了规范，建立了专门的机制来处理性能问

44、题，力争在第一时间解决问题。在K/3的性能问题处理过程中，涉及的角色主要有如下图的5个。在性能问题的处理过程中，职能分工是这样的：K/3总体设计组主要负责工作流程的制定和优化，软件架构和综合性能问题（无法定位到模块）分析和处理，分支机构和技术支持部性能问题处理技能培训，客户性能优化工作文档的制定和规范。分支机构和技术支持部在接受培训后能够分析，定位和解决部分问题，尤其是网络问题，硬件环境问题，通过索引优化或者调整应用方式能够解决的问题,以及已有补丁的局部功能问题，对于不能解决的客户认真填写,提交总体设计组，技术支持部，或者项目组。项目组尤其是CDC（主设计师）对需要优化的具体局部功能应该尽快给

45、予处理。二. 性能问题的处理策略Y 尽量自力更生对于性能问题我们希望客户，分支机构，技术支持能够尽可能在通过此手册的学习或其他的学习，尽可能自力更生解决性能问题。对于硬件配置，网络，软件环境等非K/3软件本身的性能问题希望分支机构在实施的时候尽可能做好。有些局部的性能问题可以搜索补丁看看是否已作了优化补丁。对于局部功能的性能问题，请分支机构或客户在提交技术支持提单时尽可能写明模块和描述清楚问题，技术支持就可以直接提交到研发每一个部门的CDC来处理，对于不能定位或全面性的问题提交总体设计组来处理,特别要说明的是不要把功能和性能问题混为一谈，甚至把功能问题当作性能问题。客户分支机构技术支持研发，这

46、和其他技术支持的流程一样，但是如果是紧急的客户问题，可以直接电话联系总体设计组来处理。Y 消防员和消防规则对于性能问题研发现在的策略就是一方面积极配合分支机构处理现有客户的性能问题，派出消防员，另一方面研发现在从开发过程和技术两方面大力优化K/3系统（消防规则），相信V10.2整个系统的性能会有很大的提升。三. 客户性能问题的处理流程说明：在目前的研发架构下，每个部门有一个CDC（主设计师），主设计师有责任处理客户属于本部门模块的局部性能问题。四. 性能问题处理相关的工作产品对于客户性能问题有时候为了定位问题需要了解客户系统的很多具体情况，为了提高交流和沟通的效率，分支机构或者客户要向研发人员

47、提交K/3客户性能问题诊断模版。希望分支机构和客户能够认真填写此文档，有助于研发人员迅速定位和分析问题。模版如下：第四章： 性能问题分析方法和辅助分析工具本章主要说明性能问题的分析方法和一些常用的简单有效的分析工具第一节. 方法论处理任何问题都需要正确的方法。Y 排除法在处理性能问题时，排除法是最有效的方法。对于那些能够明确定为局部性能问题，当然就不需要分析了。但是大多数性能问题，尤其是无规律，全面性的性能问题定位问题时很重要的。从前面对性能问题的本质分类，首先看看是否是非软件的问题。网络是否畅通，硬件配置是否合理，操作系统通和SQL-SERVER是否符合建议性的要求，应用方式是否合理。如果是

48、软件问题主要就是定位是何功能影响了系统的运行速度。Y 像医生看病解决性能问题就和医生看病一样，分支机构和客户的系统管理员一定要请自观察现场，不要轻易相信用户的描述，有些时候从描述的现象很难得到一些有价值的信息，甚至是对自己的一种误导。就和医生看病一样他不可能只凭病人的描述来诊断。第二节. 辅助分析工具如果系统出现性能问题，可能产生性能问题的原因很多，可能是某个客户端组件有性能问题，可能是中间层组件出现阻塞，或者是SQL Server数据库的版本不是企业版等等，我们怎样才能找出真正的问题出在哪里呢？对系统进行问题跟踪检测是一种行之有效的办法。系统性能出现问题，总会有一些特征出现，除了简单的客户反

49、应很慢外，还有别的“蛛丝马迹”会暴露出来，以便于我们找到问题的关键所在。下面就常见的一些系统性能监测工具作一个简单的介绍：一. Windows任务管理器如果K/3系统很慢，是不是系统没有可用的CPU和内存等资源了？Windows任务管理器可以帮助我们发现系统资源的使用情况。一) 使用方法要打开“任务管理器”，请用右键单击任务栏上的空白处，然后单击“任务管理器”，或者把 “Ctrl+Alt+Delete”三个键同时按下，选择“任务管理器”。l 选择“性能”选项卡，如下图：可以发现系统CPU和内存的使用情况。在系统出现性能问题时，监测一段时间系统资源的使用情况。l 选择“进程”选项卡，如下图：如果

50、在上图中发现CPU或者内存的使用率比较高，通过该图，可以发现资源究竟被哪些进程所消耗。是否还有别的系统（除K3）消耗了宝贵的CPU和内存资源。下图中可以看出SQL Server消耗了系统91的CPU，K3消耗了8%的CPU。二) 数据库服务器CPU曲线的一些典型结论由于数据库是K/3系统的瓶颈，我们主要观察数据库服务器的性能，通过观察数据库服务器CPU的运行曲线，可以得出一些典型结论。特别说明要观察一段时间的CPU运行状态，而不是看一瞬间的状态。1， CPU持续100%一段时间如果发现数据库CPU在某一段时间持续达到100%,成一条直线状，这可以判断是某项功能耗用了全部的CPU资源，这项功能如

51、果是很少使用的计算功能或者是大数据量查询，建议适当安排,不要在业务高峰期运行，如果是日常功能绝对需要优化。如果能够直接判断是某项具体的功能最好，如果在并发下无法判断到底是何功能。可以通过SQL-PROFILE跟踪执行时间较长的SQL。2， CPU大多数时间保持在40%以上如果数据库服务器CPU长期保持在40%以上，系统的运行速度时快时慢，这表示CPU的负荷已经很重。如果不能优化软件本身，升级硬件，增加CPU的个数可能是需要的。在这儿要说明一点，不能认为CPU达到100%才是CPU资源不足。3， 良好的CPU状态良好的CPU状态是CPU能够经常跌落到40%以下，并且可以跌落到0。三) 判断数据库

52、内存是否够用的一种简单方法在任务管理器中选择查看-显示内核时间，会显示一条红线，可以理解为磁盘读写的时间，如果红线很高证明大量的磁盘读写操作，说明内存可能不够，需要大量的内存切换。二. 组件服务主要用来分析中间层的性能表现一) 使用方法使用组件服务管理工具可以配置和管理 COM 组件及 COM+ 应用程序，在K3中间层服务器监视组件的使用情况。l 启动组件服务管理工具在“开始”菜单，依次指向“程序”、“管理工具”，然后单击“组件服务”。 l 检查K3中间层组件是否在运行如下图，选择“Com+应用程序”可以发现哪些组件正在运行；选择工具条上的“状态查询”能够更加直观的查找哪些组件在运行中。如果客

53、户端用户比较多或者网络速度比较慢的情况下，中间层服务器有可能出现服务，从而引起性能问题。可以通过组件服务的事件列表检查是否有比较多的事件在排队等待。界面如下图：二) 如何找到正在执行的资源耗用多的组件有时候如果中间层的CPU或内存耗用很严重，由于在多个客户的并发下有时候客户很难发现是那一项操作引发了问题，这时候可以找一下那一个组件包中的哪一个组件耗用资源比较严重，配合其他的观察：如在此阶段用户都在做那些操作，有助于发现引发问题的功能。首先在任务管理器的进程选页签上寻找耗用资源较多的DLLHOST进程，在这儿说明一下，每一个中间层组件包在运行时有一个DLLHOST进程，每一个包包含很多组件。找到

54、耗用资源较多的DLLHOST，找对应的PID(进程标示号)，根据PID在组件管理中可以找到对应的组件包，然后在对组件包下面寻找调用时间长的组件，把此组件的信息和其他用户操作信息反馈到研发，可以定位到具体的功能。三) 如何判断中间层的阻塞对于中间层服务器，有可能发生阻塞，这时候主要看上面所描述的组件服务器中事务列表中的组件排队情况，如果有较长的排队情况，就代表出现阻塞，可以考虑把组塞较多的组件分离出来重新放到一个新建的包中，因为每一个COM+组件包有一个进程。四) 关于STA模式COM+组件线程数限制问题对于VB编写的COM+组件，由于不能编译为MTA线程模型，每个组件包进程的线程数默认为10个

55、，也就是说同一个组件包中所有组件功能只能最多有十个同时运行。对此问题，微软提供了一个修改线程数量限制的方法，那就是修改注册表选项，可以让线程数达到100。此项改进在V10.0已经在安装包做了修改，如果是以前版本的客户可以直接修改中间层服务器注册表选项。可以直接把以下注册表文件导入。修改默认设置后，会提高中间层的并发性能。三. SQL Server的事件探查器（SQL-PROFILE）主要用来跟踪数据库的SQL执行情况，发现耗时较长的SQL,从而发现影响性能的原因,分支机构可以使用此工具得到跟踪文件，把跟踪文件返回到研发，用来分析和定位问题。这是最有效的定位分析问题的手段。一. 使用方法K3出现

56、性能问题，很多都是与SQL Sever数据相关。是否是一次查询了太多的数据造成数据库负载过大，出现性能问题？使用该工具可以使我们发现是哪些SQL 语句消耗了SQL Server数据库的资源，对于发现性能问题会很有帮助，特别是给研发的软件工程师们。SQL 事件探查器用于以下活动： 逐步分析有问题的查询以找到问题的原因。查找并诊断运行慢的查询。捕获导致某个问题的一系列 SQL 语句。然后用所保存的跟踪在某台测试服务器上复制此问题，接着在该测试服务器上诊断问题。监视 SQL Server 的性能以精细地调整工作负荷。 l 启动事件探查器工具在“开始”菜单，依次指向“程序”、“Microsoft SQ

57、L Server”，然后单击“事件探查器”。 l 打开该程序后选择“文件”菜单的“新建”的子菜单“跟踪”，打开如下的界面：选择SQL Server服务器名称（或者输入IP地址，如果是本机器可以输入“.”英文句号），然后输入SQL Server的身份验证登陆名和密码，可以和数据库管理员联系。l 选择“事件”选项卡在该图中设置需要跟踪的SQL Server事件类。主要用来跟踪SQL语句和存储过程的事件，通常情况下只要设置TSQL事件类的SQL:BatchCompleted事件和存储过程事件类RPC:Completed、SP:Completed事件即可。l 选择“数据列”选项卡，如下图：在该图中选择

58、要捕获的数据列。建议把左边的数据列全部添加到选定的数据列表中，捕获完整，充分的信息。设置完上面的信息后，点击“运行”按钮。对选定的数据库服务器进行一定事件的跟踪，然后另存为跟踪文件，如下图：可以对数据列：CPU（事件所使用的CPU事件，毫秒为单位），Reads（服务器代表事件执行的逻辑磁盘读取数），Writes（服务器代表事件执行的物理磁盘写入数），Duration（事件所花费的事件总计，毫秒为单位）进行查看，查找读取或写入物理磁盘次数多的操作，耗时比较多的操作。为查找性能问题提供有力的证据，对性能优化也具有参考的价值。各个数据列的具体含义列举如下表，以供参考查阅。数据列列号描述Applica

59、tion Name110创建与 SQL Server 实例的连接的客户端应用程序名。 该列由应用程序传递的值填充，而不是由所显示的程序名填充。 Binary Data2与在跟踪中捕获的事件类相关的二进制值。 ClientProcessID19由主机计算机分配给进程的 ID，在该进程中客户应用程序正在运行。如果客户端提供客户端进程 ID，则填充此数据列。 Column Permissions44表明是否已设置了列权限。分析语句文本，以确定将哪些权限应用到了哪些列。 CPU 18事件所使用的 CPU 时间总计（以毫秒为单位）。 Database ID13USE database 语句所指定的数据库

60、 ID，如果没有对给定实例发出过 USE database 语句，则是默认数据库。如果在跟踪内捕获 Server Name数据列且服务器可用，则 SQL 事件探查器将显示数据库名。 通过使用 DB_ID 函数确定数据库的值。 DatabaseName35正在运行用户语句的数据库的名称。 DBUserName140客户端的 SQL Server 用户名。Duration 13事件所花费的时间总计（以毫秒为单位）。 End Time 15事件结束时的时间。启动事件的事件类（如 SQL:BatchStarting 或 SP:Starting）的该列不填充。 Error31给定事件的错误号。通常是存储

61、在 sysmessages 中的错误号。EventClass127捕获的事件类类型。 EventSubClass121事件子类的类型，提供有关每个事件类的进一步信息。例如，Execution Warning 事件类的事件子类值代表执行警告的类型： 1 = 查询等待。查询必须等待资源（如内存）才能执行。2 = 查询超时。查询在等待执行所需的资源时超时。所有事件类的该数据列均不填充。FileName36所修改的文件的逻辑名称。 Handle33ODBC、OLE DB 或 DB-Library 所用的整数，用以协调服务器的执行。 Host Name18正运行客户端的计算机名。如果客户端提供主机名，则

62、填充此数据列。若要确定主机名，请使用 HOST_NAME 函数。Index ID24受事件影响的对象上的索引 ID。若要确定对象的索引 ID，请使用 sysindexes 系统表的 indid 列。 Integer Data25与在跟踪中捕获的事件类相关的整型值。 LoginName11用户的登录名（SQL Server 安全登录或 Microsoft Windows 登录凭据，格式为 DOMAINUsername）。LoginSid141登录用户的安全标识号 (SID)。可以在 master 数据库的 sysxlogins 表中找到该信息。对于服务器中的每个登录，SID 是唯一的。 Mode32不同事件所用的整数，用于描述事件已接收或要请求的状态。 NestLevel29表示 NESTLEVEL 所返回的数据的整数。 NT Domain Name17用户所属的 Microsoft Windows NT 4.0 或 Windows 2000 域。 NT User Name16Windows NT 4.0 或 Windows 2000 用户名。Objec