Solutions

MarkLogic Data Hub Service

Fast data integration + improved data governance and security, with no infrastructure to buy or manage.

Learn More

Learn

Stay On Top Of Everything MarkLogic

Be the first to know! News, product information, and events delivered straight to your inbox.

Sign Me Up

Community

Stay On Top Of Everything MarkLogic

Be the first to know! News, product information, and events delivered straight to your inbox.

Sign Me Up

Company

Stay On Top Of Everything MarkLogic

Be the first to know! News, product information, and events delivered straight to your inbox.

Sign Me Up

 
Knowledgebase:
Understanding the "Lock Trace" diagnostic trace event
23 May 2017 06:50 PM

Introduction

A common problem that is often encountered is when code which otherwise worked fine in a development environment is deployed to production and suddenly begin to show apparent signs of performance degredation. There could be many reasons for this, but a common cause to check for is whether any queries are unnecessarily running in update mode.  This Knowledgebase article will cover a strategy for diagnosing a situation where other operations are being held back whilst waiting for updates to complete.  

Write Locks in MarkLogic: why they can cause performance issues

A transaction obtains a write lock when it wants to update a document. Read locks held by other transactions block write locks, as do other write locks. Write locks are also known as exclusive locks because they block all other transactions from accessing a document. Only one transaction can hold a write lock on a document at a time.

See: https://developer.marklogic.com/blog/how-marklogic-supports-acid-transactions

Enabling the Lock Trace diagnostic trace event to identify write locks

MarkLogic Server contains a useful trace event that will generate content in your ErrorLog.txt that can provide an indication as to whether the root cause of the performance issue is due to write locks.

You can configure trace events at the group level using the admin GUI on port 8001:

1. Go to Configure > Groups > [Group Name] > Diagnostics

2. Ensure that trace events activated is set to true and enter Lock Trace into the input field as demonstrated below:

Interpreting the Log entries

When you experience the performance issue, look in the Error Log for output from the Lock Trace event; you should see something like this:

2015-04-28 10:02:05.068 Info: [Event:id=Lock Trace]
forest=Documents
uri=#2105214633188652281
waiting=3970525320932039109
holding=300259500568275128
The items listed in the log output can be interpreted as follows:
uri
This is the URI Key
waiting
This is the id of the query that is waiting for the lock to be released
holding
This is the id of the query that is holding the lock

These will be written to ErrorLog.txt file if the Lock Trace diagnostic trace event is enabled.

Disable when done: 

Since the Lock Trace event is fairly verbose, we recommend that you remove this trace event or disable trace events when you complete your testing or diagnostics. 

Further reading

(1 vote(s))
Helpful
Not helpful

Comments (0)