Lotus Domino: Verificando o NSD: Difference between revisions

From Wiki
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
...

See this technote


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