Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

TM1 Planning Analytics - Locking Contention Guide

215 vues

Publié le

Here is guide to locking and TM1

Publié dans : Données & analyses
  • Soyez le premier à commenter

TM1 Planning Analytics - Locking Contention Guide

  1. 1. Lock Contention Management Product Area of Tip or Technique Lock Contention Management Playbook Product(s): IBM TM1 Area of Interest: Infrastructure Lock Contention Management
  2. 2. Lock Contention Management Playbook Copyright and Trademarks Licensed Materials - Property of IBM. © Copyright IBM Corp. 2015 IBM, the IBM logo, and Cognos are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml While every attempt has been made to ensure that the information in this document is accurate and complete, some typographic exist. IBM does not accept responsibility for any kind of loss resulting from the use of information contained in this document. The information contained in this document is subject to change without notice. This document is maintained by the You can send comments, suggestions, and additions to Microsoft, Windows, Windows NT, and the Windows logo are tra Corporation in the United States, other countries, or both. Lock Contention Management Playbook IBM Confidential Property of IBM. 5 the IBM logo, and Cognos are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A demarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml While every attempt has been made to ensure that the information in this document is accurate and complete, some typographical errors or technical inaccuracies may exist. IBM does not accept responsibility for any kind of loss resulting from the use of information contained in this document. The information contained in this document is subject to change without notice. This document is maintained by the IBM Business Analytics Proven Practices You can send comments, suggestions, and additions to cscogpp@ca.ibm.com Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. 2 IBM Confidential the IBM logo, and Cognos are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A While every attempt has been made to ensure that the information in this document al errors or technical inaccuracies may exist. IBM does not accept responsibility for any kind of loss resulting from the use of information contained in this document. The information contained in this document Practices team. cscogpp@ca.ibm.com. demarks of Microsoft
  3. 3. Lock Contention Management Playbook Table of Contents INTRODUCTION................................ PURPOSE OF THIS DOCUMENT ................................ APPLICABILITY................................ EXCLUSIONS AND EXCEPTIONS ................................ DETERMINING VERSION OF TM1 ................................ TM1 LOCKING FOUNDATION TM1 LOCK MODES................................ A Read Lock (R)................................ A ReadOnly Lock (RO) ................................ An Intent Exclusive to Update no copy (IXNC) An Intent Exclusive to Update (IX) A Write Lock (W) ................................ TM1 Lock Compatibility................................ Two Phase Locking................................ When are locks acquired and released? Transaction Commit ................................ Contention Types (Lock states)................................ Symptoms of Lock Contention ................................ TM1TOP ................................................................ OPSCONSOLE ................................ IBM COGNOS TM1 SERVER MONITOR WHICH TOOL SHOULD I USE? ................................ CONTENTION ON OBJECT LOCKS ................................ Lock Contention Management Playbook IBM Confidential ................................................................................................ ............................................................................................... ................................................................................................................. .............................................................................................. ........................................................................................... ON.................................................................................... ................................................................................................ ................................................................................................ ................................................................................................ An Intent Exclusive to Update no copy (IXNC)................................................................ An Intent Exclusive to Update (IX) .................................................................................. ................................................................................................ ................................................................................................ ................................................................................................ When are locks acquired and released? ................................................................ ................................................................................................ ....................................................................................... ...................................................................................... ..................................................................................... ................................................................................................................ ONITOR PLUG-IN FOR APACHE JMETER............................................. ............................................................................................. ......................................................................................... 3 IBM Confidential ........................................ 5 ...............................5 .................5 ..............................5 ...........................5 .................... 6 ............................................6 ............................................6 ...................................6 ..................................6 ..................7 ..........................................7 ..................................7 ........................................8 ...........................................8 ......................................8 .......................9 ......................10 ..................... 10 ................ 12 ............. 13 ............................. 14 ......................... 15
  4. 4. Lock Contention Management Playbook SAMPLE SCENARIOS................................ CUBE OPERATION SCENARIO DELETE CUBE OPERATION SCENARIO UPDATE DIMENSION OPERATIONS ................................ TURBO INTEGRATOR OPERATION................................ TURBO INTEGRATOR................................ CHORE INTEGRATOR................................ LOGON ................................................................ LOGOFFS ................................................................ WHAT DO I NEED TO CAPTURE/PROCEED? HAVE TM1TOP GATHERING................................ TM1 LOGGERS ................................ Lock Contention Management Playbook IBM Confidential ............................................................................................... ELETE.................................................................................... PDATE ................................................................................... ................................................................................................ ......................................................................................... ................................................................................................ ................................................................................................ ..................................................................................... ..................................................................................... PTURE/PROCEED? ........................................................... ............................................................................................... .............................................................................................................. 4 IBM Confidential ............................... 16 .................... 16 ................... 16 .................................. 17 ......................... 17 ........................................ 18 ........................................ 19 ..................... 19 ..................... 20 ........................... 21 ............................... 21 .............. 21
  5. 5. Lock Contention Management Playbook Introduction Purpose of this document This document provides the necessary information to understand TM1 server lock management, and the steps to help Applicability The information outlined in this document IBM TM1 9.5.2 using the Planning Samples IBM TM1 10.2.1 using the Planning Samples package shipped IBM TM1 10.2.2 using the Planning Samples package shipped with TM1 installer Exclusions and exceptions The technique outlined in this document requires the use of undocumented and unsupported capabilities in IBM TM1. As a result and are not considered supported. Determining version of TM1 Please refer to the following document describing how to determine your TM1 Version https://www.ibm.com/developerworks/community/wikis/home/wiki/Wc8dd794ce663_464f_89 d9_5472bde75168/page/Determining%20TM1%20Server%20Version Lock Contention Management Playbook IBM Confidential ocument necessary information to understand TM1 server lock management, and the steps to help troubleshoot lock contention issues. outlined in this document was validated using the: Planning Samples package shipped with TM1 installer IBM TM1 10.2.1 using the Planning Samples package shipped with TM1 installer IBM TM1 10.2.2 using the Planning Samples package shipped with TM1 installer xceptions The technique outlined in this document requires the use of undocumented and unsupported As a result the technique and its associated files are provided and are not considered supported. Determining version of TM1 Please refer to the following document describing how to determine your TM1 Version https://www.ibm.com/developerworks/community/wikis/home/wiki/Wc8dd794ce663_464f_89 d9_5472bde75168/page/Determining%20TM1%20Server%20Version 5 IBM Confidential necessary information to understand TM1 server lock The technique outlined in this document requires the use of undocumented and unsupported provided “as is” Please refer to the following document describing how to determine your TM1 Version https://www.ibm.com/developerworks/community/wikis/home/wiki/Wc8dd794ce663_464f_89
  6. 6. Lock Contention Management Playbook TM1 Locking Foundation In order to better understand TM1 locking issues, one will need to deepen their knowledge of the various lock types that are implemented in TM1 server (engine). Locking is necessary to protect data integrity, and to ensure that when a query is the correct results are returned. In addition, locking is implemented inside of TM1 to synchronize (traffic cop) access to underlying data structures. TM1 Lock Modes The TM1 server is implemented to support 5 lock modes. The lock modes are Read ReadOnly (RO), Intent to Update with no Copy (IXNC), Intent to Update (IX) and W A Read Lock (R) Allows concurrent read access to an object while allowing one TM1 thread to own the right to modify the object READ locks are used to ensure that an thread is referencing that object. A ReadOnly Lock (RO) Allows concurrent read access to an object while allowing no threads to own the right to modify an object Ensures a collection of objects cannot An Intent Exclusive to Update no copy (IXNC) Indicates a thread's ownership of the right to modify an object, no before image is made Before images are needed to restore object state in case of a rollback Only used if an operation can never roll back or there is some other mechanism besides before images to perform the rollback Very rarely used in the server Only used if the object was created by the current operation, so rollback means destroying the object entirely, not restoring the before image Lock Contention Management Playbook IBM Confidential Foundation In order to better understand TM1 locking issues, one will need to deepen their knowledge of the various lock types that are implemented in TM1 server (engine). Locking is necessary to protect data integrity, and to ensure that when a query is executed, the correct results are returned. In addition, locking is implemented inside of TM1 to synchronize (traffic cop) access to underlying data structures. The TM1 server is implemented to support 5 lock modes. The lock modes are Read ReadOnly (RO), Intent to Update with no Copy (IXNC), Intent to Update (IX) and W Allows concurrent read access to an object while allowing one TM1 thread to own the right to READ locks are used to ensure that an object is not changed by another thread whilst current ject. Allows concurrent read access to an object while allowing no threads to own the right to Ensures a collection of objects cannot change until read is complete An Intent Exclusive to Update no copy (IXNC) Indicates a thread's ownership of the right to modify an object, no before image is made Before images are needed to restore object state in case of a rollback ration can never roll back or there is some other mechanism besides before images to perform the rollback Only used if the object was created by the current operation, so rollback means destroying toring the before image 6 IBM Confidential In order to better understand TM1 locking issues, one will need to deepen their knowledge of executed, the correct results are returned. In addition, locking is implemented inside of TM1 to The TM1 server is implemented to support 5 lock modes. The lock modes are Read (R), ReadOnly (RO), Intent to Update with no Copy (IXNC), Intent to Update (IX) and Write. Allows concurrent read access to an object while allowing one TM1 thread to own the right to object is not changed by another thread whilst current Allows concurrent read access to an object while allowing no threads to own the right to Indicates a thread's ownership of the right to modify an object, no before image is made ration can never roll back or there is some other mechanism besides Only used if the object was created by the current operation, so rollback means destroying
  7. 7. Lock Contention Management Playbook An Intent Exclusive to Update (IX) Indicates a thread's ownership of the right to modify an object Intent eXclusive locks are used to indicate that a user is modifying an object. Only one user can modify an object at any point in owns the right to make modifications. A Write Lock (W) Allows only one thread to access an object Write locks are used to give a user completely exclusive access to an object. Write locks are acquired at the end o that were made while holding an IX lock. TM1 Lock Compatibility Lock compatibility becomes an issue when one application (or TM1 thread) holds a lock on a TM1 resource (Cube, Dimension …) and another app object. When the two lock modes are compatible, the request for a second lock on the object can be granted. If the locks are incompatible, the TM1 server may either place the request into a Wait state, until the resourc on the context of the operation. In the table below, a values of Yes, implies that the thread requesting the Lock, would be allowed to proceed. A value of No, implies that the thread requesting the blocked until the lock is released by the holding thread. Lock Requested Lock Currently Held None None yes Read yes ReadOnly yes IXNC yes IX yes Write yes Note IX and R locks are compatible; however wait (but not rollback/retry). Lock Contention Management Playbook IBM Confidential An Intent Exclusive to Update (IX) Indicates a thread's ownership of the right to modify an object Intent eXclusive locks are used to indicate that a user is modifying an object. Only one user can modify an object at any point in time. The first user to acquire an IX lock owns the right to make modifications. Allows only one thread to access an object Write locks are used to give a user completely exclusive access to an object. Write locks are acquired at the end of a transaction to commit the changes to each object that were made while holding an IX lock. Lock compatibility becomes an issue when one application (or TM1 thread) holds a lock on a TM1 resource (Cube, Dimension …) and another application requests a lock on the same object. When the two lock modes are compatible, the request for a second lock on the object can be granted. If the locks are incompatible, the TM1 server may either place the request into a Wait state, until the resource is released, or return immediately. The behavior depends on the context of the operation. In the table below, a values of Yes, implies that the thread requesting the Lock, would be allowed to proceed. A value of No, implies that the thread requesting the Lock, would be released by the holding thread. Lock Currently Held None Read ReadOnly IXNC IX yes yes yes yes yes yes yes yes yes yes no no yes no no no yes no no no no no no no however, existing R lock holders can cause the IX holder to 7 IBM Confidential time. The first user to acquire an IX lock f a transaction to commit the changes to each object Lock compatibility becomes an issue when one application (or TM1 thread) holds a lock on a lication requests a lock on the same object. When the two lock modes are compatible, the request for a second lock on the object can be granted. If the locks are incompatible, the TM1 server may either place the request e is released, or return immediately. The behavior depends In the table below, a values of Yes, implies that the thread requesting the Lock, would be Lock, would be Write yes no no no no no existing R lock holders can cause the IX holder to
  8. 8. Lock Contention Management Playbook Two Phase Locking Locks are acquired during the "growing" phase of a during the execution of an operation Locks are not released until the "shrinking" phase. The shrinking phase begins when the transaction commits. When are locks acquired and released? TM1 does not expose the concept of database system, there are no BeginTransaction/EndTransaction API calls. In TM1, a transaction is a single API call. The locks will be acquired, granted, or accumulated within the respective API call, and released when the API call completes. Examples: When constructing the data that makes up a view When executing a TI process or a Chore The exception to the rule would be TIs (and Chores). Since a TI script can consist of multiple TM1 functions, the locks that are acquired by each of the API functions will not be released until the TI function completes. In the case of a TM1 Chore, the locks will be released once the Chore completes. As of TM1 10.1 the Commit would occur. The options are, end of each TI process Mode, or end of the Chore which is Multiple Commit Mode. Transaction Commit Completely exclusive access to an object (WRITE lock) is only granted The lock protocol is such that a WRITE lock request can never deadlock. Write lock requests are subject to starvation (more later) Lock Contention Management Playbook IBM Confidential Locks are acquired during the "growing" phase of a transaction as objects are accessed g the execution of an operation Locks are not released until the "shrinking" phase. s when the transaction commits. When are locks acquired and released? TM1 does not expose the concept of a transaction outside the API. Compared to a Relational database system, there are no BeginTransaction/EndTransaction API calls. In TM1, a transaction is a single API call. The locks will be acquired, granted, or accumulated within the and released when the API call completes. onstructing the data that makes up a view xecuting a TI process or a Chore The exception to the rule would be TIs (and Chores). Since a TI script can consist of multiple TM1 functions, the locks that are acquired by each of the API functions will not be released until the TI function completes. In the case of a TM1 Chore, the locks will be released once As of TM1 10.1 there was an attribute on a Chore, which controls when the Commit would occur. The options are, end of each TI process which is Single Commit Mode, or end of the Chore which is Multiple Commit Mode. Completely exclusive access to an object (WRITE lock) is only granted at commit time. The lock protocol is such that a WRITE lock request can never deadlock. Write lock requests are subject to starvation (more later) 8 IBM Confidential transaction as objects are accessed a transaction outside the API. Compared to a Relational database system, there are no BeginTransaction/EndTransaction API calls. In TM1, a transaction is a single API call. The locks will be acquired, granted, or accumulated within the The exception to the rule would be TIs (and Chores). Since a TI script can consist of multiple TM1 functions, the locks that are acquired by each of the API functions will not be released until the TI function completes. In the case of a TM1 Chore, the locks will be released once which controls when which is Single Commit at commit time.
  9. 9. Lock Contention Management Playbook Contention Types (Lock states) The TM1 server surfaces (when queried) various contention types. The content depend on the nature of the conflict. The following is a list of possible situational conflicts that may arise. IXC - This state is known as a WaitForIXConflictLockEvent. This occurs when a thread is requesting an IX lock on an object, but a object. IXCur - This state is known as a WaitForIXCurrentEvent. This occurs when a thread is requesting an IX lock on an object, but another thread is currently holding a Read lock on the resource. WR - This state is known as a WaitForWriterEvent. This occurs when a thread is requesting a Write lock on a resource, but another thread is currently holding a Read lock on the resource. IXR - This state is known as a WaitForIXReaderEvent.This occurs when a requesting an IX (or Read) lock on a resource, but another thread is currently holding a Write lock. WC - This state is known as a WaitForCompletionEvent. This occurs when a thread is waiting on another thread to release its locks. DDR - This state is known as a Data Reservation Release. This occurs when a thread is waiting for data. TM1 API calls that frequently can cause locks: TI Execution - Can read or IX lock objects for a long time SecurityRefresh - Will read lock most objects in the syst SaveDataAll - Will read lock every cube and IX lock every modified cube CubeCellValueSet - IX locks the target cube Held a short time, but will be blocked by other users trying to read or modify the same cube CubeCellSpread - IX locks the target cube May hold IX lock for a long time depending on volume of data being modified ViewArrayConstruct - Read locks the cubes involved May hold read locks which block contribution depending on computation complexity Lock Contention Management Playbook IBM Confidential Contention Types (Lock states) The TM1 server surfaces (when queried) various contention types. The contention type will depend on the nature of the conflict. The following is a list of possible situational conflicts This state is known as a WaitForIXConflictLockEvent. This occurs when a thread is requesting an IX lock on an object, but another thread currently holds an IX lock on the same This state is known as a WaitForIXCurrentEvent. This occurs when a thread is requesting an IX lock on an object, but another thread is currently holding a Read lock on the This state is known as a WaitForWriterEvent. This occurs when a thread is requesting a Write lock on a resource, but another thread is currently holding a Read lock on This state is known as a WaitForIXReaderEvent.This occurs when a thread is requesting an IX (or Read) lock on a resource, but another thread is currently holding a Write This state is known as a WaitForCompletionEvent. This occurs when a thread is waiting on another thread to release its locks. tate is known as a Data Reservation Release. This occurs when a thread is TM1 API calls that frequently can cause locks: Can read or IX lock objects for a long time Will read lock most objects in the system at the same time Will read lock every cube and IX lock every modified cube IX locks the target cube Held a short time, but will be blocked by other users trying to read or modify the same cube he target cube May hold IX lock for a long time depending on volume of data being modified Read locks the cubes involved May hold read locks which block contribution depending on computation complexity 9 IBM Confidential ion type will depend on the nature of the conflict. The following is a list of possible situational conflicts This state is known as a WaitForIXConflictLockEvent. This occurs when a thread is nother thread currently holds an IX lock on the same This state is known as a WaitForIXCurrentEvent. This occurs when a thread is requesting an IX lock on an object, but another thread is currently holding a Read lock on the This state is known as a WaitForWriterEvent. This occurs when a thread is requesting a Write lock on a resource, but another thread is currently holding a Read lock on thread is requesting an IX (or Read) lock on a resource, but another thread is currently holding a Write This state is known as a WaitForCompletionEvent. This occurs when a thread is tate is known as a Data Reservation Release. This occurs when a thread is Held a short time, but will be blocked by other users trying to read or modify the same cube May hold read locks which block contribution depending on computation complexity
  10. 10. Lock Contention Management Playbook Views that use Dynamic Subsets Changes to data and metadata invalidate dynamic subsets. when their contents need to be computed, causing contention be used if the subset is updated due to potential locking. BatchUpdateStart/Finish – This commit each write for next to accumulate it. Try to do anything you can do to lessen the calculations required for readers (viewarrayconstruct blocks writers) Cubecellspread - lock length depends on volume of data update SaveDataAll - allows readers unless it requires SaveDataAll schedule should be determined in relation to organization require Symptoms of Lock Contention Contention on locks may lead to degraded queries are not executing in a timely manner. TM1Top can be used to identify who is waiting at any TM1Top follow. What tools can I use? Various tools are available to dynamically surface user/chore/system threads locking activity that in turn can contribute to TM1 Server Contention. Currently, there are three tools that are available; TM1Top, OpsConsole and JMeter. TM1Top TM1Top is the more mature of the TM1 server monitoring tools. The following are pros and cons to TM1Top TM1Top is included in the TM1 server install kit (resides in bin longer available with the TM1 server installation; instead the tool can be downloaded from DeveloperWorks. http://www.ibm.com/developerworks/library/ba Console based program, only available on Windows Indicates which users are causing contention Lock Contention Management Playbook IBM Confidential iews that use Dynamic Subsets - The contents of a dynamic subset needs to be calculated. Changes to data and metadata invalidate dynamic subsets. Dynamic subsets are IX locked when their contents need to be computed, causing contention. Dynamic subsets should not is updated due to potential locking. This cannot use accumulation within the processes, it can commit each write for next to accumulate it. Try to do anything you can do to lessen the calculations required for readers ayconstruct blocks writers) lock length depends on volume of data update allows readers unless it requires reconstruct of dynamic subset. A proper SaveDataAll schedule should be determined in relation to organization requirements. Symptoms of Lock Contention lead to degraded performance, or the appearance submitted data or queries are not executing in a timely manner. o identify who is waiting at any moment in time. Additional slid Various tools are available to dynamically surface user/chore/system threads locking activity that in turn can contribute to TM1 Server Contention. Currently, there are three tools that are M1Top, OpsConsole and IBM Cognos TM1 Server Monitor Plug-in for Apache TM1Top is the more mature of the TM1 server monitoring tools. The following are pros and TM1Top is included in the TM1 server install kit (resides in bin). As of 10.1, the tool is no longer available with the TM1 server installation; instead the tool can be downloaded from ww.ibm.com/developerworks/library/ba-pp-infrastructure-cognos_specific-page674/index.html Console based program, only available on Windows Indicates which users are causing contention 10 IBM Confidential The contents of a dynamic subset needs to be calculated. Dynamic subsets are IX locked Dynamic subsets should not on within the processes, it cannot reconstruct of dynamic subset. A proper ments. performance, or the appearance submitted data or moment in time. Additional slides on Various tools are available to dynamically surface user/chore/system threads locking activity that in turn can contribute to TM1 Server Contention. Currently, there are three tools that are in for Apache TM1Top is the more mature of the TM1 server monitoring tools. The following are pros and As of 10.1, the tool is no longer available with the TM1 server installation; instead the tool can be downloaded from page674/index.html
  11. 11. Lock Contention Management Playbook Shows the operations they are performing Shows how long they have been Does not show what object they are contending Easiest to configure, and startup quickly Can be run from a console, and collect locking information (to a file) in the background You can cancel a Thread via the UI Can only be used in Real time mod The following is a sample screen capture of TM1Top Lock Contention Management Playbook IBM Confidential Shows the operations they are performing Shows how long they have been running Does not show what object they are contending on Easiest to configure, and startup quickly Can be run from a console, and collect locking information (to a file) in the background You can cancel a Thread via the UI Can only be used in Real time mode, not historical The following is a sample screen capture of TM1Top 11 IBM Confidential Can be run from a console, and collect locking information (to a file) in the background
  12. 12. Lock Contention Management Playbook OpsConsole OpsConsole is included in the TM1 server install kit The user interface is browser based Indicates which users are causing contention Shows the operations they are performing Shows how long they have been running Shows what object they are contending ( Can schedule capture (snapshot) of You can cancel a Thread via the UI Can only be used in Real time mode, no historical The following is a sample screen capture of k Contention Management Playbook IBM Confidential is included in the TM1 server install kit (as of 10.1) The user interface is browser based Indicates which users are causing contention y are performing Shows how long they have been running what object they are contending (Beginning in 10.1.1) apture (snapshot) of locking information (to a file) in the background You can cancel a Thread via the UI Can only be used in Real time mode, no historical The following is a sample screen capture of OpsConsole 12 IBM Confidential locking information (to a file) in the background
  13. 13. Lock Contention Management Playbook IBM Cognos TM1 Server Monitor Plug The tool can be downloaded from the following location http://www.ibm.com/developerworks/library/ba The site also provides some information on how t web site. Runs inside jMeter framework (which is Java based), and can run on any Java supported environment Indicates which users are causing contention Shows the operations they are performing Shows how long they have been running Does show what object they are contending Easier to configure, and startup quickly You cannot cancel a Thread via the UI Allows TM1 administrator to analyze thread activity in real time or States are color coded, to aid in analysis of thread activity Ability to slide through time Displays graph of thread count by states (one click away) The following is a sample screen capture of the IBM Cognos TM1 Server Monitor Plug Apache JMeter Lock Contention Management Playbook IBM Confidential IBM Cognos TM1 Server Monitor Plug-in for Apache JMeter The tool can be downloaded from the following location http://www.ibm.com/developerworks/library/ba-pp-infrastructure-cognos_specific-page675/index.html The site also provides some information on how to install, configure and use the tool on the Runs inside jMeter framework (which is Java based), and can run on any Java supported Indicates which users are causing contention Shows the operations they are performing ey have been running Does show what object they are contending on, and the thread ID that is blocking to configure, and startup quickly You cannot cancel a Thread via the UI to analyze thread activity in real time or historical States are color coded, to aid in analysis of thread activity Displays graph of thread count by states (one click away) The following is a sample screen capture of the IBM Cognos TM1 Server Monitor Plug 13 IBM Confidential page675/index.html o install, configure and use the tool on the Runs inside jMeter framework (which is Java based), and can run on any Java supported The following is a sample screen capture of the IBM Cognos TM1 Server Monitor Plug-in for
  14. 14. Lock Contention Management Playbook Which tool should I use? Your choice of tool to use depends on what you want to achieve, and how quickly you want achieve it. For example, if you are logged onto a Windows machine, and you want to quickly connect to a TM1 server to see the TM1Top would probably be limited to the TM1 Administrators. If you want to provide Top like functionality to non TM1 admin users, OpsConsole might be the better approach, as it is browser based no need to install software on desktop. If you want to perform some analysis of the TM1 activity, in real time or post collection, the IBM Cognos TM1 Server Monitor Plug in for Apache JMeter tool would be suited for this type of work. Lock Contention Management Playbook IBM Confidential Your choice of tool to use depends on what you want to achieve, and how quickly you want achieve it. For example, if you are logged onto a Windows machine, and you want to quickly connect to a TM1 server to see the activity, TM1Top might be the way to go. Access to TM1Top would probably be limited to the TM1 Administrators. If you want to provide Top like functionality to non TM1 admin users, OpsConsole might be the better approach, as it is install software on desktop. If you want to perform some analysis of the TM1 activity, in real time or post collection, the IBM Cognos TM1 Server Monitor Plug in for Apache JMeter tool would be suited for this type of work. 14 IBM Confidential Your choice of tool to use depends on what you want to achieve, and how quickly you want achieve it. For example, if you are logged onto a Windows machine, and you want to quickly activity, TM1Top might be the way to go. Access to TM1Top would probably be limited to the TM1 Administrators. If you want to provide Top like functionality to non TM1 admin users, OpsConsole might be the better approach, as it is install software on desktop. If you want to perform some analysis of the TM1 activity, in real time or post collection, the IBM Cognos TM1 Server Monitor Plug-
  15. 15. Lock Contention Management Playbook Contention on Object Locks It is possible for the performance of multi object lock contention. Lock contention occurs when two users attempt to access the same object in a manner that is not compatible with each other. The simplest way to identify the cause of object lock contention is to enable contention logging . If verbose lock logging is not a viable option, the cause of lock contention. This is sometimes necessary field. Note Object locks aren't the only form of concurrency control in the server. Critical sections are frequently used to protect data structure integrity. Contention on critical sections c analyzed using internal tools as well Lock Contention Management Playbook IBM Confidential Contention on Object Locks for the performance of multi-user applications to be negatively affected by object lock contention. Lock contention occurs when two users attempt to access the same object in a manner that is not compatible with each other. identify the cause of object lock contention is to enable verbose lock ng is not a viable option, TM1Top and debug logs can be used This is sometimes necessary when diagnosing contention in the bject locks aren't the only form of concurrency control in the server. Critical sections are frequently used to protect data structure integrity. Contention on critical sections can be as well 15 IBM Confidential user applications to be negatively affected by object lock contention. Lock contention occurs when two users attempt to access the same verbose lock can be used to identify osing contention in the bject locks aren't the only form of concurrency control in the server. Critical sections are an be
  16. 16. Lock Contention Management Playbook Sample Scenarios The following scenarios represent Cube Operation Scenario Delete A user is querying a TM1 Cube, which in turn forces a Read lock on Cube. A second user attempts to delete that same cube. The blocking condition would play out in manner, and we observe the information in TM1 Monitoring tool. T1. User 1 (thread 10104) has a long running Read lock on a cube T2. User 2 (thread 11464) attempts to Delete the Cube T3. User 2 enters a Wait (Wait:IXCur), the info message in blocking In the jMeter capture, we can observe that the thread 10104 has been granted a Read Only lock on the Cube1 Cube, and that thread 11464 is delete the cube from the TM1 server. Th state, until the Read lock is released. Cube Operation Scenario Update In this scenario, a user is querying a TM1 Cube, which in turn forces a Read lock on Cube. The Read Lock is acquired to ensure t cube while it is referenced. Meanwhile, a cube. Before the Rule can be applied to the Cube, an IX lock must be requested and granted The thread that is requesting the IX will remain in a blocked (Wait) state until the Read lock is released. The blocking condition would play out in the following manner, and we observe the information in TM1 Monitoring tool. Read lock on Cube, user attempts to create a Rule, User 1 (thread 10104) has a long running Read lock on a cube User 2 (thread 11464) attempts to create a Rule on the Cube User 2 enters a Wait (Wait:IXCur), the info message indicates the threadID that is blocking Lock Contention Management Playbook IBM Confidential The following scenarios represent simple interaction that would typically occur in a given day. Scenario Delete A user is querying a TM1 Cube, which in turn forces a Read lock on Cube. A second user attempts to delete that same cube. The blocking condition would play out in the following manner, and we observe the information in TM1 Monitoring tool. User 1 (thread 10104) has a long running Read lock on a cube User 2 (thread 11464) attempts to Delete the Cube User 2 enters a Wait (Wait:IXCur), the info message indicates the threadID that is In the jMeter capture, we can observe that the thread 10104 has been granted a Read Only lock on the Cube1 Cube, and that thread 11464 is requesting an IX lock in an attempt to delete the cube from the TM1 server. The blocking thread 11464, will remain in a Wait:IXCur state, until the Read lock is released. Scenario Update user is querying a TM1 Cube, which in turn forces a Read lock on . The Read Lock is acquired to ensure that a different thread cannot delete/modify the Meanwhile, a second user attempts to create a Rule on the same Before the Rule can be applied to the Cube, an IX lock must be requested and granted sting the IX will remain in a blocked (Wait) state until the Read lock The blocking condition would play out in the following manner, and we observe the information in TM1 Monitoring tool. Read lock on Cube, user attempts to create a Rule, or modify a Rule or delete a Rule User 1 (thread 10104) has a long running Read lock on a cube User 2 (thread 11464) attempts to create a Rule on the Cube User 2 enters a Wait (Wait:IXCur), the info message indicates the threadID that is blocking 16 IBM Confidential simple interaction that would typically occur in a given day. A user is querying a TM1 Cube, which in turn forces a Read lock on Cube. A second user the following dicates the threadID that is In the jMeter capture, we can observe that the thread 10104 has been granted a Read Only an IX lock in an attempt to e blocking thread 11464, will remain in a Wait:IXCur user is querying a TM1 Cube, which in turn forces a Read lock on the hat a different thread cannot delete/modify the second user attempts to create a Rule on the same Before the Rule can be applied to the Cube, an IX lock must be requested and granted. sting the IX will remain in a blocked (Wait) state until the Read lock The blocking condition would play out in the following manner, and we observe the a Rule or delete a Rule User 2 enters a Wait (Wait:IXCur), the info message indicates the threadID that is blocking
  17. 17. Lock Contention Management Playbook In the jMeter capture, we can observe that the thread 10104 has been granted a Read Only lock on the Cube1 Cube, and that thread 11464 is update the cube from the TM1 server. The blocking thread 11464, will remain in a Wait:I state, until the Read lock is released. been in a Wait state for 3 seconds. Dimension Operations Dimension locks are common occurrences in a TM1 operational environment. This scenario demonstrates what happens when a lock running query, accessing a cube, conflicts with another thread attempting to change a Dimension structure, by adding a new element. User 1 (thread 12608) has a long running query a Cube1 User 2 (thread 15912) adds a new element to a dimension User 2 enters a Wait (Wait:IXCur) There are other Dimension scenarios that can cause lock conflicts. These will be covered in the next update to this document. Turbo Integrator Operation In this scenario, a user is executing a Turbo Integrator (TI) process, which forces a Read lock on TI process. A secondary user attempts to delete the TI process. similar to the Cube deletion described previously. requesting the deletion of a TM1 object (TI process), will require an IX lock before proceeding to the destruction of the object. User 1 (thread 10104) has a long running User 2 (thread 11464) attempts to User 2 enters a Wait (Wait:IXCur), the info message indicates the threadID that is blocking Lock Contention Management Playbook IBM Confidential Meter capture, we can observe that the thread 10104 has been granted a Read Only lock on the Cube1 Cube, and that thread 11464 is requesting an IX lock in an attempt to update the cube from the TM1 server. The blocking thread 11464, will remain in a Wait:I state, until the Read lock is released. In this example, we can observe that thread 11464 has been in a Wait state for 3 seconds. Dimension locks are common occurrences in a TM1 operational environment. This scenario demonstrates what happens when a lock running query, accessing a cube, conflicts with thread attempting to change a Dimension structure, by adding a new element. ) has a long running query a Cube1 ) adds a new element to a dimension Cur) are other Dimension scenarios that can cause lock conflicts. These will be covered in to this document. Operation In this scenario, a user is executing a Turbo Integrator (TI) process, which forces a Read lock on TI process. A secondary user attempts to delete the TI process. This scenario is very etion described previously. Essentially, the user/thread that is requesting the deletion of a TM1 object (TI process), will require an IX lock before proceeding to the destruction of the object. User 1 (thread 10104) has a long running TI process hread 11464) attempts to delete the TI process (whilst the TI process is executing) User 2 enters a Wait (Wait:IXCur), the info message indicates the threadID that is blocking 17 IBM Confidential Meter capture, we can observe that the thread 10104 has been granted a Read Only an IX lock in an attempt to update the cube from the TM1 server. The blocking thread 11464, will remain in a Wait:IXCur In this example, we can observe that thread 11464 has Dimension locks are common occurrences in a TM1 operational environment. This scenario demonstrates what happens when a lock running query, accessing a cube, conflicts with thread attempting to change a Dimension structure, by adding a new element. are other Dimension scenarios that can cause lock conflicts. These will be covered in In this scenario, a user is executing a Turbo Integrator (TI) process, which forces a Read lock This scenario is very that is delete the TI process (whilst the TI process is executing) User 2 enters a Wait (Wait:IXCur), the info message indicates the threadID that is blocking
  18. 18. Lock Contention Management Playbook Turbo Integrator In this scenario, a user is executing a TI process, Integrator process. A secondary user wants to apply changes to the TI logic (whilst the TI process is executing). This scenario is similar to the (previously described). User 1 (thread 4820) has a long running TI process User 2 (thread 6168) attempts to modify the TI process User 2 (thread 6168) enters a Wait (Wait:IXCur), the info message indicates the threadID that is blocking Lock Contention Management Playbook IBM Confidential In this scenario, a user is executing a TI process, which forces a Read lock on a Turbo secondary user wants to apply changes to the TI logic (whilst the TI process is executing). This scenario is similar to the Cube Operation Scenario Update long running TI process User 2 (thread 6168) attempts to modify the TI process User 2 (thread 6168) enters a Wait (Wait:IXCur), the info message indicates the threadID 18 IBM Confidential rces a Read lock on a Turbo secondary user wants to apply changes to the TI logic (whilst the TI Scenario Update User 2 (thread 6168) enters a Wait (Wait:IXCur), the info message indicates the threadID
  19. 19. Lock Contention Management Playbook Chore Integrator Read lock on Chore, user attempts to de User 1 (thread 10104) has a long running Read lock on a cube User 2 (thread 11464) attempts to create a Rule on the Cube User 2 enters a Wait (Wait:IXCur), the info message indicates the threadID that is blocking Logon It is possible (and used quite often by large customers) to have the use CAM as an authentication source. CAM interface, to return the User and Group information specific to that When a CAM enabled user connects into TM1 for the first ti information that was returned by CAM, and update the TM1 metadata specific to that user. In order to gain update/write acc Logon will request an IX lock. If the IX lock can be immediately granted, occur immediately. When the IX lock cannot be granted immediately, enter a Wait state, and to the end user, Here’s an example of such a scenario. We have a new user that has never logged into TM1 server. On a particular day, the user logs into TM1. At the point of logon, another thread has a Read lock on one or some o TM1 Control Cubes/Dimensions ( User 1 (thread 11012) has a long running process that has a Read lock on the }ClientGroups cube User 2 (thread 14268) is attempting to log in, and after a few moments, repor session appears to be hung Lock Contention Management Playbook IBM Confidential Read lock on Chore, user attempts to de-activate the Scheduling User 1 (thread 10104) has a long running Read lock on a cube User 2 (thread 11464) attempts to create a Rule on the Cube User 2 enters a Wait (Wait:IXCur), the info message indicates the threadID that is blocking It is possible (and used quite often by large customers) to have the TM1 server configured to use CAM as an authentication source. When connected to CAM, the TM1 server will query the CAM interface, to return the User and Group information specific to that user (at logon time). When a CAM enabled user connects into TM1 for the first time, the TM1 server will ingest information that was returned by CAM, and update the TM1 metadata (control cubes) In order to gain update/write access to the TM1 Control Cubes, the Logon will request an IX lock. If the IX lock can be immediately granted, the update will IX lock cannot be granted immediately, the logon request enter a Wait state, and to the end user, the TM1 connection may appear to be “hung”. Here’s an example of such a scenario. We have a new user that has never logged into TM1 server. On a particular day, the user logs into TM1. At the point of logon, another thread has a Read lock on one or some o TM1 Control Cubes/Dimensions (}Clients, }ClientGroups, }ClientProperties, …) User 1 (thread 11012) has a long running process that has a Read lock on the }ClientGroups 14268) is attempting to log in, and after a few moments, reports that their 19 IBM Confidential User 2 enters a Wait (Wait:IXCur), the info message indicates the threadID that is blocking configured to When connected to CAM, the TM1 server will query the user (at logon time). server will ingest the (control cubes), ess to the TM1 Control Cubes, the the update will request will be “hung”. We have a new user that has never logged into TM1 server. On a particular day, the user logs into TM1. At the point of logon, another thread has a Read lock on one or some of the User 1 (thread 11012) has a long running process that has a Read lock on the }ClientGroups ts that their
  20. 20. Lock Contention Management Playbook The TM1 Administrator, looks at the Top information, and can see that a User (???) is “hung” attempting to login. The TM1 Administrator can also observe that user ??? is attempting to acquire an IX lock on the }ClientGroups cube can quickly identify who and what is blocking other users in the TM1 server. In the case of a Logon, it may not be as easy to detect Administrator will need to find the underlying reason for the blockage. If the proper TM1 loggers are enabled, the Administrator If the loggers were not enabled Logoffs Under certain conditions, TM1 Logouts or disconnects can surface lock conflicts. The details of this scenario will be covered in the next update to this document. Lock Contention Management Playbook IBM Confidential The TM1 Administrator, looks at the Top information, and can see that a User (???) is “hung” attempting to login. The TM1 Administrator can also observe that user ??? is attempting to lientGroups cube. In the previous scenarios, the Administrator can quickly identify who and what is blocking other users in the TM1 server. In the case of a it may not be as easy to detect. To achieve a level of insight required, the TM1 to find the underlying reason for the blockage. If the proper TM1 enabled, the Administrator can to look in the tm1server.log file to find the d previously, the available information will be limited. Under certain conditions, TM1 Logouts or disconnects can surface lock conflicts. The details of this scenario will be covered in the next update to this document. 20 IBM Confidential The TM1 Administrator, looks at the Top information, and can see that a User (???) is “hung” attempting to login. The TM1 Administrator can also observe that user ??? is attempting to In the previous scenarios, the Administrator can quickly identify who and what is blocking other users in the TM1 server. In the case of a , the TM1 to find the underlying reason for the blockage. If the proper TM1 to look in the tm1server.log file to find the cause. ited.
  21. 21. Lock Contention Management Playbook What do I need to capture/proceed? Collect the information using the tools m Have TM1Top gathering Ensure proper TM1 loggers are enabled Analyze the information Remedy (where possible) Have TM1Top Gathering In a production environment, it is strongly encouraged to have a TM1Top session running silently in the background, continuously collecting/gathering locking information. Th that TM1Top has collected can be further analysis (after the fact). consumed/analyse Lock activity in real time TM1 Loggers Careful enabling TM1.Locks logger, this logger will provide very detailed logging of all locks acquired, converted and released in the system. In production environment, it’s more sensible to use the TM1.Lock.Exception logger. This logger only writes out to the log file, when a locking exception occurs. Please refer to the following document that describes all the available TM1 loggers. https://www.ibm.com/developerworks/community/wikis/home/wiki/Wc8dd794ce663_464f_89 d9_5472bde75168/page/TM1 Server Logging The tm1s-log.properties file should reside in the same folder/directory location as the tm1s.cfg file. The tm1s-log.properties file manages the information that is written to the tm1server.log file. You should be careful to not enable have an impact on TM1 server performance. log4j.logger.TM1.Lock.Exception=DEBUG log4j.logger.TM1.CAMSecurity=DEBUG log4j.logger.TM1.Login=DEBUG log4j.logger.TM1.TM1Top=DEBUG Sample output from each logger is provided further down. Lock Contention Management Playbook IBM Confidential t do I need to capture/proceed? Collect the information using the tools mentioned above Ensure proper TM1 loggers are enabled In a production environment, it is strongly encouraged to have a TM1Top session running background, continuously collecting/gathering locking information. Th can be consumed as input into the TM1 Server Monitor Plug further analysis (after the fact). The TM1 Server Monitor Plug-in can also be used to nsumed/analyse Lock activity in real time. Careful enabling TM1.Locks logger, this logger will provide very detailed logging of all locks acquired, converted and released in the system. In production environment, it’s more TM1.Lock.Exception logger. This logger only writes out to the log file, en a locking exception occurs. Please refer to the following document that describes all the available TM1 loggers. https://www.ibm.com/developerworks/community/wikis/home/wiki/Wc8dd794ce663_464f_89 d9_5472bde75168/page/TM1 Server Logging should reside in the same folder/directory location as the log.properties file manages the information that is written to the tm1server.log file. You should be careful to not enable overly detailed loggers, as this will act on TM1 server performance. log4j.logger.TM1.Lock.Exception=DEBUG log4j.logger.TM1.CAMSecurity=DEBUG log4j.logger.TM1.Login=DEBUG log4j.logger.TM1.TM1Top=DEBUG Sample output from each logger is provided further down. 21 IBM Confidential In a production environment, it is strongly encouraged to have a TM1Top session running background, continuously collecting/gathering locking information. The data TM1 Server Monitor Plug-in for can also be used to Careful enabling TM1.Locks logger, this logger will provide very detailed logging of all locks acquired, converted and released in the system. In production environment, it’s more TM1.Lock.Exception logger. This logger only writes out to the log file, Please refer to the following document that describes all the available TM1 loggers. https://www.ibm.com/developerworks/community/wikis/home/wiki/Wc8dd794ce663_464f_89 should reside in the same folder/directory location as the log.properties file manages the information that is written to the detailed loggers, as this will
  22. 22. Lock Contention Management Play The Lock.Exception logger provides d example, if we had two users competing to access a TM1 resource User 1 has a long running TI process that has a Read lock on a cube. User 2 attempts to create a Rule on the same Cube. We can observe th Lock Contention Management Playbook IBM Confidential The Lock.Exception logger provides detailed information when a lock exception occurs. For example, if we had two users competing to access a TM1 resource User 1 has a long running TI process that has a Read lock on a cube. attempts to create a Rule on the same Cube. We can observe the following in Top 22 IBM Confidential etailed information when a lock exception occurs. For e following in Top
  23. 23. Lock Contention Management Playbook With the LockException enabled, we can observe the following in the tm1server.log file 2124 [6] DEBUG 2015-01-19 23:23:32.748 TM1.Lock.Exception Lock conflict acquiring 'IX' lock. Thread '11688' holds 'IX' lock. Object Enabling the log4j.logger.TM1.CAMSecurity=DEBUG would provide information similar to the following. When authenticating with CAM, the following can be very useful in isolating an issue. 2015-01-19 23:20:48.750 TM1.CAMSecurity Sy 2015-01-19 23:20:48.752 TM1.CAMSecurity SystemServerConnectGetClientWithCAMPassport 2015-01-19 23:20:48.752 TM1.CAMSecurity SystemServerConnectGetClientWithCAMPassport connect to http://tpdalyj7.canlab.ibm.com:9300/p2pd/servlet/dispatch 2015-01-19 23:20:48.752 TM1.CAMSecurity SystemServerConnectGetClientWithCAMPassport Object. Attempt: 1 2015-01-19 23:20:48.788 TM1.CAMSecurity SystemServerConnectGetClientWithCAMPassport in TM1 2015-01-19 23:20:48.788 TM1.CAMSecurity SystemServerConnectGetClientWithCAMPassport 2015-01-19 23:20:48.788 TM1.CAMSecurity SystemServerConnectGetClientWithCAMPassport retrieved 2015-01-19 23:20:48.788 TM1.CAMSecurity SystemServerAssignCAMID Enabling TM1.Login=DEBUG will provide information simil 13848 [4] DEBUG 2015-01-19 23:42:54.729 TM1.Login Login Success: User CAMID("maple:u:31") Enabling TM1.TM1Top=DEBUG will provide information similar to the following 13452 [6] DEBUG 2015-01- created. Number of connections: 1 This allows us to know at any point in time, how many TM1Top (also counts for OpsConsole and jMeter) are currently connected. When a TM1Top session disconnects from the server, the corresponding count is decremented. Lock Contention Management Playbook IBM Confidential With the LockException enabled, we can observe the following in the tm1server.log file 19 23:23:32.748 TM1.Lock.Exception Lock conflict acquiring 'IX' lock. Thread '11688' holds 'IX' lock. Object 'Cube1' , type 'Cube'. Enabling the log4j.logger.TM1.CAMSecurity=DEBUG would provide information similar to the following. When authenticating with CAM, the following can be very useful in isolating an 19 23:20:48.750 TM1.CAMSecurity SystemServerConnectGetClientWithCAMPassport – Enterin 19 23:20:48.752 TM1.CAMSecurity SystemServerConnectGetClientWithCAMPassport - Loaded CAM Dll 19 23:20:48.752 TM1.CAMSecurity SystemServerConnectGetClientWithCAMPassport - Attemptin http://tpdalyj7.canlab.ibm.com:9300/p2pd/servlet/dispatch 19 23:20:48.752 TM1.CAMSecurity SystemServerConnectGetClientWithCAMPassport - Creating CAM User 19 23:20:48.788 TM1.CAMSecurity SystemServerConnectGetClientWithCAMPassport - Lookup CAM User 19 23:20:48.788 TM1.CAMSecurity SystemServerConnectGetClientWithCAMPassport - Client found TM1.CAMSecurity SystemServerConnectGetClientWithCAMPassport - }Clients dimension 19 23:20:48.788 TM1.CAMSecurity SystemServerAssignCAMID - entering. Querying CAM Properties Enabling TM1.Login=DEBUG will provide information similar to the following 19 23:42:54.729 TM1.Login Login Success: User CAMID("maple:u:31") Enabling TM1.TM1Top=DEBUG will provide information similar to the following -19 23:46:04.745 TM1.TM1Top TM1Top connection created. Number of connections: 1 This allows us to know at any point in time, how many TM1Top (also counts for OpsConsole and jMeter) are currently connected. When a TM1Top session disconnects from the server, is decremented. 23 IBM Confidential With the LockException enabled, we can observe the following in the tm1server.log file 19 23:23:32.748 TM1.Lock.Exception Lock conflict acquiring Enabling the log4j.logger.TM1.CAMSecurity=DEBUG would provide information similar to the following. When authenticating with CAM, the following can be very useful in isolating an Enterin Loaded CAM Dll Attempting to Creating CAM User Lookup CAM User Client found }Clients dimension entering. Querying CAM Properties 19 23:42:54.729 TM1.Login Login Success: User CAMID("maple:u:31") TM1Top connection This allows us to know at any point in time, how many TM1Top (also counts for OpsConsole and jMeter) are currently connected. When a TM1Top session disconnects from the server,

×