Understanding the "Lock Trace" diagnostic trace event
23 May 2017 06:50 PM
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.
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:
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.