Definitions of threads seen in sm_monitor outputs/logs
search cancel

Definitions of threads seen in sm_monitor outputs/logs

book

Article ID: 315897

calendar_today

Updated On:

Products

VMware Smart Assurance

Issue/Introduction

Provide definitions of threads seen in sm_monitor outputs.
What is the meaning of the lines/threads which are present in sm_monitor logs?

Observed the following lines/threads from Smarts sm_monitor summary log:

InCharge Framework Current size 1
SM_ElementManager Current size 1
SubscriberFE-<SAM_domain>_NL-Driver-EventTimer Current size 1
uptime responder Current size 1
SubscriberFE-EventTimer Current size 1
Flow KeepAlives Current size 39
SubscriberFE-<SAM_domain>_NL-Driver-EventTimer Current size 1
SM_PropertyPoller Current size 1
ICS_ActionScheduler::ICS-ActionScheduler Current size 1070
SM_LicenseManager Current size 9
SubscriberFE-<SAM_domain>_Event-Driver-EventTimer Current size 1


Do not know meaning of threads like InCharge Framework, SubscriberFE-<SAM_domain>_NL-Driver-EventTimer seen in Smarts sm_monitor summary log.

Environment

Smarts - 10.1.x

Resolution

The definitions of threads seen in SM_Monitor outputs as shown above are as follows:

1. InCharge Framework
A thread associated with a timed queue to provide general timing services to the server. Not related to processing external events received from the monitored domain. Users can ignore this thread.

2. SM_ElementManager
A thread associated with a timed queue to facilitate the function of periodically checking the active status of system components. Not related to processing external events received from the monitored domain. Users can ignore this thread.

3. SubscriberFE-<SAM_domain>_NL-Driver-EventTimer
This is the companion thread of the corresponding SubscriberFE's socket observer thread. It is also associated with a timed queue.
This thread is used by the corresponding SubscriberFE object to facilitate the implementation of some timing services, such as it can generate periodic timer events and inject the events into the notification data flow for the .asl script (executed on the event driver thread) to process. 
Users can ignore this thread as well.
*For this particular thread, it is part of the thread group associated with a domain named as <SAM_domain> (in relevance to the user scenario given).*

4. uptime responder
A thread associated with a timed queue to provide the "heartbeat" service to the server's client applications. Users can ignore this thread.

5. SubscriberFE-EventTimer
A thread with the same nature as (3) but associated with a subscriber front end with a default queue name. Can be ignored.

6. Flow KeepAlives
A thread created by TCP flow management function to facilitate the implementation of exchanging keepalive bits between the two end points of a TCP connection. Users can ignore the threads of this type.

7. SubscriberFE-<SAM_domain>_NL-Driver-EventTimer-
Please See (3).

8. SM_PropertyPoller
A thread used to facilitate the implementation of monitoring property changes of objects stored in repository. Users may see temporary queue accumulation of this thread from time to time when the server sees a burst changes of object properties. An accumulation of this queue may explain the temporary slowness of SAM. But in general, this queue should be able to clear itself in time.

9. ICS_ActionScheduler::ICS_ActionScheduler
A thread associated with a timed queue as well. The thread provides timing service to the SAM server to facilitate periodic automatic tasks - such as autoarchiving or acknowledgement or event state auto-clean up, etc. An accumulation of this queue may indicate the server is busy with automatic tasks created to continue processing received notifications at delayed time according to the policy configured for notification processing.

10. SM_LicenseManager
A thread dedicated to perform license related management tasks.

11. SubscriberFE-<SAM_domain>_Event-Driver-EventTimer
Please See (3).