应用性能调优样例

gahg

近期一个客户的Domino oa server升级（5---〉6）后，发现应用的性能有了很大的下降，后来做了重装服务器，修复数据库和更新索引，性能没有什么大的改进，最后发现一篇文档，不要去维护数据库的未读标记可以提高web触发代理的性能，于是尝试了一下，居然效果不错。

由于Domino 数据库缺省情况下会对数据库中的未读标记进行维护，在一些文档数较多的数据库中，这样的操作会花费较多的时间，导致web触发的代理会比较慢，特别是在R6的版本中。未读标记通常对于应用数据库没有太大的意义，一般用于邮件数据库中，所以建议用户取消该选项，具体操作在数据库的高级属性中勾选上“不维护未读标记”

然后再对该数据库进行压缩重建，load compact –c dbname,使其生效。

In Release 6, Web-Triggered Agents Take Longer to Complete when Maintaining Unread Marks

Product:
Lotus Domino  >  Lotus Domino Designer >  Versions 6.5, 6.0
Platform(s):
AIX, HP-UX, i5/OS, Linux, Solaris, Windows, z/OS
Doc Number:
1212520
Date:
2005-07-26





Technote


Problem

After you upgrade a Lotus Domino server from Release 5 to Release 6, you find that Web-triggered agents run noticeably slower.  Agents affected include LotusScript and Java agents triggered using WebQueryOpen or WebQuerySave, or those triggered by the OpenAgent URL command.  You are more likely to see a performance impact if running Web agents concurrently (Server document -> Internet Protocols tab -> Domino Web Engine tab -> "Run Web agents concurrently").




Solution

Domino 6 is working as designed.  Enhancements to the underlying unread functionality introduced in Domino 6 require additional system resources beyond what R5 required.  This is as designed and is a consequence of upgrading the internal format of the unread table storage.  This additional overhead can affect the performance of Web-triggered agents that access that database.  For some databases, unread marks are not necessary.  If you disable the property to maintain unread marks, you can avoid the overhead and improve Web-triggered agent performance.

To disable maintaining unread marks, open each database that the affected agent accesses and perform the following steps:

1.  Select File -> Database -> Properties and go to the Advanced tab.
2.  Select "Don't Maintain Unread Marks."
3.  Run the Compact command with the -c parameter by issuing the following command on the server console:
Load compact –c

Tip:  You can also run the Compact server task with the -u or -U option to enable or disable this property and then compact.

For more information on this property, refer to the Domino Designer Help topic "Properties that improve database performance."

Additional diagnosis details
By inserting print statements at the beginning and end of an agent and enabling AgentThreadDebug=1, you can determine if an agent is being impacted by unread mark overhead. On the server console, you will see a delay between the last print statement that the agent outputs and the time the agent terminates, such as follows:

[1014:0023-0DA0] 07/14/2005 09:20:26 PM  *** Agent Start: agent "WebQueryOpen" in "D:\notes\data\testdb.nsf" (thread [1014:0023-0DA0])  
[1014:0023-0DA0] 07/14/2005 09:20:34 PM  Agent message: Starting Execution
[1014:0023-0DA0] 07/14/2005 09:20:34 PM  Agent message: Completed Execution
[1014:0023-0DA0] 07/14/2005 09:20:47 PM  *** Agent Completed: agent "WebQueryOpen" in "D:\notes\data\testdb.nsf" (thread [1014:0023-0DA0])   

When a LotusScript or Java agent terminates, it synchronizes any changes that it may have made to the unread marks in all of the databases that it has opened during its execution. This process is synchronized against concurrent operations by a semaphore, so if several copies of an agent are running concurrently, other agents have to wait if another is already terminating.

It is possible for this situation to occur with agents being run by the Agent Manager task; however, it is most likely to be observed for Web-triggered agents because a fairly high degree of concurrency is needed for this synchronization to cause a noticeable delay in agent execution time.

If you run NSD during the agent executive, you can see that one or both of the thread stacks shown below are present. (Note that the time that the NSD is taken impacts whether or not you see these thread stacks.  You may have to take several NSDs to capture them at the right time.)

############################################################
### thread 39/151: [   nhttp:01c0:0f54]
### FP=51dd3dc8, PC=77f82870, SP=51dd3da4, stkbase=51ce0000, stksize=262144
############################################################
[ 1] 0x77f82870 ntdll.RtlAdjustPrivilege+143 (1d54,3a98,0,600a7dd7)
[ 2] 0x7c57b3db KERNEL32.CreateProcessW+393 (1b1,4b201170,60c31f44,0)
@[ 3] 0x600011a8 nnotes._OSLockSemInt@8+216 (4b201170,1,51dd3e70,62652a0b)
@[ 4] 0x600010be nnotes._OSLockSem@4+14 (4b201170,5a2b0236,5a2b0190,0)
@[ 5] 0x62652a0b nlsxbe.ANDatabase::ANDCloseThread+203 (0,5a2b0190,51dd4348,62648812)
@[ 6] 0x626489da nlsxbe.ANDatabase::ANDClose+202 (5a2b0190,51dd3ed4,62659e22,1)
@[ 7] 0x6264816b nlsxbe.ANDatabase::`scalar deleting destructor'+11 (1,51dd0002,5a2b0190,51dd4348)
@[ 8] 0x62659e22 nlsxbe.ANotes::ANDecRefCount+370 (1,51dd4364,5ab8cf9c,0)
@[ 9] 0x626428a2 nlsxbe._ANCLASSCONTROL@16+194 (5ab7b720,106,51dd4348,0)
@[10] 0x62643309 nlsxbe._tag_NotesADTControl::ClassControl+25 (5a2b01bc,5ab7b720,106,51dd4348)
@[11] 0x600590b2 nnotes.LSsInstance::AdtCallBack+226 (5ab7b720,626427e0,106,5ab8cf80)
@[12] 0x60069241 nnotes.LScObjCli::CallAdtProc+145 (5ab8cf40,106,0,5dc72b34)
@[13] 0x6009119b nnotes.LScObjCli::DropDead+27 (5ab8cf40,5dc724f0,51dd4438,6010b803)
@[14] 0x6008c3c9 nnotes.LSsThread::DeleteVar+425 (5ad4f048,5dc72b34,5e3f636c,51dd4444)
@[15] 0x6010b803 nnotes.LSsThread::DeleteModuleLocals+227 (5e3f636c,5e20f358,5e3f1264,ffffff00)
@[16] 0x60021523 nnotes.LSsThread::NRun+963 (5ad4f048,5ad4f048,5e20f358,51dd4544)
@[17] 0x60023276 nnotes.LSsThread::Run+182 (5ad4f048,5ab7b720,5ad4f048,5946b518)

############################################################
### thread 132/151: [   nhttp:01c0:0834]
### FP=57ad36b8, PC=6060878e, SP=57ad3638, stkbase=579e0000, stksize=262144
############################################################
@[ 1] 0x6060878e nnotes._LocateID@28+574 (27140b50,bbdda,57ad3818,57ad3810)
@[ 2] 0x60606b37 nnotes._IDHInsert@12+231 (19de,bbdda,0,27140b50)
@[ 3] 0x60609fdc nnotes._IDHInsertRange@16+92 (19de,bbdda,bbdda,0)
@[ 4] 0x60602fc1 nnotes._IDInsertRange@16+97 (19de,bbdda,bbdda,0)
@[ 5] 0x6018726c nnotes._IDInsertTable@8+892 (19de,2639,179af06e,2987)
@[ 6] 0x60605c4d nnotes._IDTableDifferences@20+1549 (2639,2987,57ad3d74,57ad3d78)
@[ 7] 0x608583e0 nnotes._DbSetUnreadNoteTable@24+800 (57ad3e18,17996b60,21,1)
@[ 8] 0x6077b4d1 nnotes._iNSFDbSetUnreadNoteTable@24+145 (0,17996b60,21,1)
@[ 9] 0x6078587c nnotes._ApplyDiffsToUnreadList+188 (57ad3e18,1,0,58d1a9b4)
@[10] 0x60785770 nnotes._iNSFDbDisassociateUnreadList@4+32 (57ad3e18,58d1a9b4,179968e8,19ff0e8)
@[11] 0x60759a5d nnotes._NSFDbDisassociateUnreadList@4+77 (0,58d23dfe,58d23d58,0)
@[12] 0x62652a62 nlsxbe.ANDatabase::ANDCloseThread+290 (0,58d23d58,57ad4348,62648812)
@[13] 0x626489da nlsxbe.ANDatabase::ANDClose+202 (58d23d58,57ad3ed4,62659e22,1)
@[14] 0x6264816b nlsxbe.ANDatabase::`scalar deleting destructor'+11 (1,57ad0002,58d23d58,57ad4348)
@[15] 0x62659e22 nlsxbe.ANotes::ANDecRefCount+370 (1,57ad4364,5caed654,0)
@[16] 0x626428a2 nlsxbe._ANCLASSCONTROL@16+194 (5c6feb98,106,57ad4348,0)
@[17] 0x62643309 nlsxbe._tag_NotesADTControl::ClassControl+25 (58d23d84,5c6feb98,106,57ad4348)
@[18] 0x600590b2 nnotes.LSsInstance::AdtCallBack+226 (5c6feb98,626427e0,106,5caed638)
@[19] 0x60069241 nnotes.LScObjCli::CallAdtProc+145 (5caed5f8,106,0,5e54cb54)
@[20] 0x6009119b nnotes.LScObjCli::DropDead+27 (5caed5f8,5e3567b0,57ad4438,6010b803)
@[21] 0x6008c3c9 nnotes.LSsThread::DeleteVar+425 (5cc93e28,5e54cb54,5e581b0c,57ad4444)
@[22] 0x6010b803 nnotes.LSsThread::DeleteModuleLocals+227 (5e581b0c,5da578a0,5e581264,ffffff00)
@[23] 0x60021523 nnotes.LSsThread::NRun+963 (5cc93e28,5cc93e28,5da578a0,57ad4544)
@[24] 0x60023276 nnotes.LSsThread::Run+182 (5cc93e28,5c6feb98,5cc93e28,5a1813f4)

In the above threads, the second one is performing its unread mark synchronization, while the first one is waiting for it to complete (indicated by the OSLockSem and OSLockSemInt calls).










本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/11279/showart_321985.html