Lock Contention Management Playbook 6 2 - IBM · 2015-05-12 · Lock Contention Management Playbook...

Lock Contention Management

ProductArea of

Tip or Technique

Lock Contention Management Playbook

Product(s): IBM TM1 Area of Interest: Infrastructure

Lock Contention Management


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 typographicexist. 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 traCorporation in the United States, other countries, or both.


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 PracticesYou can send comments, suggestions, and additions to [email protected]

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. [email protected].

demarks of Microsoft


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


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


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


IBM Confidential

...............................................................................................

ELETE ....................................................................................

PDATE ...................................................................................

................................................................................................

.........................................................................................

................................................................................................

................................................................................................

.....................................................................................

.....................................................................................

PTURE/PROCEED? ...........................................................

...............................................................................................

..............................................................................................................

4

IBM Confidential

............................... 16

.................... 16

................... 16

.................................. 17

......................... 17

........................................ 18

........................................ 19

..................... 19

..................... 20

........................... 21

............................... 21

.............. 21


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 SamplesIBM 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 resultand 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_89d9_5472bde75168/page/Determining%20TM1%20Server%20Version


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


https://www.ibm.com/developerworks/community/wikis/home/wiki/Wc8dd794ce663_464f_89d9_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”


https://www.ibm.com/developerworks/community/wikis/home/wiki/Wc8dd794ce663_464f_89


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


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


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



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


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



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 othat 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 appobject. 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 resourcon 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 theblocked until the lock is released by the holding thread.

Lock Requested Lock Currently Held NoneNone yes Read yes ReadOnly yes IXNC yes IX yes Write yes

Note

IX and R locks are compatible; howeverwait (but not rollback/retry).


IBM Confidential


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


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.1the Commit would occur. The options are, end of each TI processMode, 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)


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.


Contention Types (Lock states)The TM1 server surfaces (when queried) various contention types. The contentdepend 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 aobject. 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 arequesting 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 cubeHeld a short time, but will be blocked by other users trying to read or modify the same cube

CubeCellSpread - IX locks the target cubeMay hold IX lock for a long time depending on volume of data being modified

ViewArrayConstruct - Read locks the cubes involvedMay hold read locks which block contribution depending on computation complexity


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


Views that use Dynamic SubsetsChanges to data and metadata invalidate dynamic subsets.when their contents need to be computed, causing contentionbe 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 requiresSaveDataAll schedule should be determined in relation to organization require

Symptoms of Lock Contention

Contention on locks may lead to degradedqueries 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 binlonger 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


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 cancommit 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


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


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


IBM Confidential


Shows how long they have been running

Does not show what object they are contending on

Easiest to configure, and startup quickly



Can only be used in Real time mode, not historical

The following is a sample screen capture of TM1Top

11

IBM Confidential



OpsConsole

OpsConsole is included in the TM1 server install kit

The user interface is browser based




Shows what object they are contending (

Can schedule capture (snapshot) of


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


y are performing


what object they are contending (Beginning in 10.1.1)

apture (snapshot) of locking information (to a file) in the background


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


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 tweb site.

Runs inside jMeter framework (which is Java based), and can run on any Java supported environment




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 PlugApache JMeter


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



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


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 Plugin for Apache JMeter tool would be suited for this type of work.


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 Plugin 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-


Contention on Object Locks

It is possible for the performance of multiobject 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 canalyzed using internal tools as well


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


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 cubeT2. User 2 (thread 11464) attempts to Delete the Cube T3. User 2 enters a Wait (Wait:IXCur), the info message inblocking

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. Thstate, 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 tcube while it is referenced. Meanwhile, acube. Before the Rule can be applied to the Cube, an IX lock must be requested and grantedThe 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 cubeUser 2 (thread 11464) attempts to create a Rule on the CubeUser 2 enters a Wait (Wait:IXCur), the info message indicates the threadID that is blocking


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


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:Istate, 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 Cube1User 2 (thread 15912) adds a new element to a dimensionUser 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


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:Istate, 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)


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


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 processUser 2 (thread 6168) attempts to modify the TI processUser 2 (thread 6168) enters a Wait (Wait:IXCur), the info message indicates the threadID that is blocking


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


Chore Integrator

Read lock on Chore, user attempts to de

User 1 (thread 10104) has a long running Read lock on a cubeUser 2 (thread 11464) attempts to create a Rule on the CubeUser 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 thatWhen a CAM enabled user connects into TM1 for the first tiinformation that was returned by CAM, and update the TM1 metadataspecific to that user. In order to gain update/write accLogon 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 oTM1 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, reporsession appears to be hung


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 oTM1 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


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


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 cubecan 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 detectAdministrator 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.


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.


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. Ththat 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_89d9_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=DEBUGlog4j.logger.TM1.CAMSecurity=DEBUGlog4j.logger.TM1.Login=DEBUGlog4j.logger.TM1.TM1Top=DEBUG

Sample output from each logger is provided further down.


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 Plugfurther 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.


https://www.ibm.com/developerworks/community/wikis/home/wiki/Wc8dd794ce663_464f_89d9_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,


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

Lock Contention Management Play

The Lock.Exception logger provides dexample, 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


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


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 Sy2015-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/dispatch2015-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.


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 – Enterin19 23:20:48.752 TM1.CAMSecurity SystemServerConnectGetClientWithCAMPassport - Loaded CAM Dll19 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 foundTM1.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,

Lock Contention Management Playbook 6 2 - IBM · 2015-05-12 · Lock Contention Management Playbook...

Documents

Transcript of Lock Contention Management Playbook 6 2 - IBM · 2015-05-12 · Lock Contention Management Playbook...