Domino NSD日志诊断.docVIP

Domino NSD日志诊断/分析 收藏 随着Domino服务器在生产环境中的长时间运行，用户量增多，数据量增大后，会带来一系列的问题；如宕机频繁、运行效率低下、系统资源消耗大等现象。本身Domino属于文档型数据库，在数据库中的文档数量越多，数据库越大；访问效率就会越低。大多数项目初期： 程序员为了完成任务或赶工，编写过程中并不会考虑程序运行效率、容错等问题； 在布署运行环境的时候，一般不会全面考虑服务器的运行状况，不会对服务器进行相应的性能优化和调整；所以在数据量增大和用户数增大时，出现性能低下等问题。 基于以上现象，客户满意度达不到，有可能造成项目失败的可能性。 遇到这类情况后，Domino管理员就有必要通过一系列手段来评估目前环境的问题在哪？性能瓶颈在哪？主要什么原因引起的？应该如何进行调整？ 在我眼中Domino管理员工作是非常复杂和繁锁的，Domino管理工作可以细分从服务器管理、数据库管理、邮件管理、人员管理、安全管理、复制管理、策略管理等，这些工作你可以一人完成(这个人要相当牛B了，对Domino运行机制，邮件路由机制，复制机制，Internet协议等都要有比较深层次的了解)，也可以一个小组来完成。 如果做为一个合格Domino管理员，不懂得如何编写程序，可以说根本算不上一个真正的系统管理员。就像二流黑客拿一些专门的黑客工具黑网站，黑QQ号一样，只知道机械化的做，并不知道为什么要这么做，基础原理是什么。 当你的Domino服务器宕机后，向IBM800电话支持，他们都会要求你提供NSD日志给他们进行分析，经他们分析后，会告诉你宕机原因，是由什么由于引起宕机。 言归正传，我们先讲讲如何分析NSD日志，并从中找出服务器目前的问题所在，宕机目要是由什么引起的。 NSD日志存放于%DominoData%\IBM_TECHNICAL_SUPPORT目录下，文件格式： nsd___日志生成日志(YYYY_MM_DD)@日志生成时间(HH_MM_SS).log 例： nsd_all_AIX_as2_2008_04_03@17_32_40.log nsd_W32I_as5_2008_07_18@11_07_24.log 以文件名能很快清楚服务器的基本信息。 NSD分析工具有两种（目前我所知道的，也许还有其他的）Laza和Lotus Notes Diagnostic(简称：LND)两种，大致功能是相同的，Laza因为有SPR库和PMR库支持，可以快速的找出服务器宕机的解释和解决办法，但是SPR库和PMR库，IBM是不对外开放；所以我们使用的话Laza或LND是没区别的。我推荐大家使用LND足够了，简单方便，配合Google查询足够完成NSD分析工作。 如何分析？很简单，安装完LND后，启动Lotus Notes客户端，打开LND库(LND缺省会将lnd.nsf安装在你%NotesData%\LND目录下)，如下图： 单击Open Process a file，打开一个NSD文件，则会将一个NSD进行分析，并将结果保存在Notes文档中。NSD分析结果文档分为以下部分： Stack：记录引起宕机的主要Stack片断信息 HighLights：主要强调的错误信息，包括出错任务名称、进程号或内存地址等 SPR Search：SPR查询关键字，使用这些关键字，在IBM Support网站上能查询相关信息；（这个是最有效的解决办法之一） Options：设置信息，可以不管 Stack related infos：记录详细的Stack信息，分为以下几个部分，其中观察红色加粗部分就可以定位宕机主要原因以及所由哪个用户在使用哪个数据库中哪个文档（文档中调用了哪段程序）所引起的： open database(s) by the process：进程打开的数据库 Possible file name(s) in stack frames：可能涉及到的数据库文件名 Process Associated Collection(s)View(s)：进程所涉及到的集合和视图 Process Handle Table Info：进程所涉及到的Handle Table信息 Process Memory：进程使用内存情况 Process Memory Mapping：进程使用内存地址映射表 Process Top 10 Memory block usage：进程中前10个内存块使用情况 Shared OS Fields：共享OS区(此处记录了宕机的主要原因) Stack frames Dump：Stack结构回收信息 Virtual Thread(s)：所涉及的虚拟线程(此处记录了宕机时所涉及到的数据库、文档以及Domino设