Lotus Domino: Verificando o NSD: Difference between revisions
(→Indice) |
|||
| Line 3: | Line 3: | ||
== Indice == | == Indice == | ||
=== MailExpandNamesExt === | |||
function MailExpandNamesExt was used to expand all groups in a recipients list. From this stack, you can tell that the delivery threads are busy expanding groups in the recipient's list. | |||
Checking in mail.box, the pending mails are mass mails with large groups in bcc field. | |||
################################### | |||
# thread 6/55 :: router, pid=xxxx, tid=xxxx # | |||
################################### | |||
... | |||
[8] 0xd1c2ee98 MailExpandNamesExt(??, ??, ??, ??, ??, ??, ??, ??) + 0x340 | |||
... | |||
[http://www-01.ibm.com/support/docview.wss?uid=swg21292087 See this technote] | |||
=== OSLockSpin(??) === | === OSLockSpin(??) === | ||
Revision as of 15:56, 15 September 2010
Esse artigo lista alguns itens a observar na hora de analisar o nsd
Indice
MailExpandNamesExt
function MailExpandNamesExt was used to expand all groups in a recipients list. From this stack, you can tell that the delivery threads are busy expanding groups in the recipient's list.
Checking in mail.box, the pending mails are mass mails with large groups in bcc field.
################################### # thread 6/55 :: router, pid=xxxx, tid=xxxx # ################################### ... [8] 0xd1c2ee98 MailExpandNamesExt(??, ??, ??, ??, ??, ??, ??, ??) + 0x340 ...
OSLockSpin(??)
When investigating the NSD server thread stacks, a specific stack always showed to be the most CPU consuming thread. Using OS tools, the thread always calls OSLockSpin().
OSLockSpin(??) is a low level function in Domino code used to grab a mutex from the OS to prevent other threads from doing the same operation at the same time.
################################### ###### thread 9/49 :: router, pid=581714, tid=3948649, ptid=9510) ###### ################################### [1] 0x090000000011597c __fd_select(??, ??, ??, ??, ??) + 0xac [2] 0x0900000000846b80 select(0x0, 0x0, 0x0, 0x0, 0x119879420) + 0x28 [3] 0x0900000000846b14 unix_usleep(0x157c0000157c0) + 0x6c [4] 0x09000000006c6450 OSDelayThread(0x5800000058) + 0x48 [5] 0x0900000000699cac OSLockSpin(0x700000004ada954) + 0x1b4 [6] 0x090000000069b1cc OSUnlockReadSem(0x700000004ada910) + 0xd4 [7] 0x090000000165b178 CRWSEMReadLock::~CRWSEMReadLock()(0x119879710, 0x200000002, 0x0) + 0x3c [8] 0x0900000001658f88 CDirAttributeTypeDescriptions::GetNext()(0x119879ab0) + 0x70 [9] 0x0900000001658d7c CDirAttributeTypeDescriptions::AssertAll()(0x119879ab0) + 0x3c ... [27] 0x0000000100067aa8 TransferThread(0x1) + 0x218 [28] 0x09000000006c2a80 ThreadWrapper(0x0) + 0x118 [29] 0x090000000049f4f4 _pthread_body(??) + 0xdc ###################################
TCPEndp_CheckSocketReady
Possible network bottleneck, in http/router/server processes when network I/O waiting for input to come while handling HTTP or NRPC request
################################### ###### thread 30/115 :: server, pid=327930, tid=1904809, ptid=2315) ###### ################################### [1] 0x090000000011597c __fd_select(??, ??, ??, ??, ??) + 0xac [2] 0x09000000023cdec4 select(0x1600000016, 0x112f24e50, 0x112f26e50, 0x112f28e50, 0x112f24e28) + 0x28 [3] 0x09000000023cca54 TCPEndp_CheckSocketReady(0x1000000000001, 0x112f2b208, 0x1f4000001f4) + 0x6dc [4] 0x09000000023cd794 cmd_poll(0x151800001edc, 0x112f2b208, 0x112f2b200, 0x112f2b128) + 0x258 [5] 0x0900000000b11314 nti_poll(0x1edc00001edc, 0x112f2b208, 0x112f2b200) + 0x214