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

• MarkLogic Blog: How MarkLogic Supports ACID Transactions
• MarkLogic Knowledgebase: How to use diagnostic trace events
• MarkLogic Knowledgebase: Gathering information to troubleshoot long-running queries
• MarkLogic Documentation: Trace Events
• MarkLogic Documentation: Understanding the Locking and Journaling Database Settings for Bulk Loads
• MarkLogic Knowedgebase: How do updates work in MarkLogic Server?
• MarkLogic Documentation: Understanding Transactions in MarkLogic Server
• David Cassel Blog: Queries and Updates