MarkLogic 10 and Data Hub 5.0

Latest MarkLogic releases provide a smarter, simpler, and more secure way to integrate data.

Read Blog →


Stay On Top Of Everything MarkLogic

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

Sign Me Up →

Tactics to diagnose locking problems in MarkLogic
19 May 2020 12:49 AM


Locking can have serious performance implications in unoptimized application code. This knowledgebase article will list various tactics to determine if locking is the main driver for performance degradation of your application.

If you would like to better understand locking in MarkLogic, please refer to the materials given below:

Tactic 1:

In MarkLogic 8 and earlier, enable the "Lock Trace" diagnostic trace event. The following KB article explains this strategy in detail: Understanding the "Lock Trace" diagnostic trace event

Diagnostic trace events can be particularly useful in situations where you need access to more internal diagnostic information than is available in the standard MarkLogic ErrorLog.txt files or in the operating system logs. The host/cluster can be configured to output trace events, at which point the server will write information to the ErrorLog.txt files every time the diagnostic event is encountered.

Please note that you should not be running normally with the “Lock Trace” trace event enabled. It is intended to be turned on for brief periods to analyze locking issues, then disabled.

Tactic 2:

From MarkLogic 9, instead of using a trace event to diagnose locking issues, you can use built-in functions.

To find transactions that are holding and waiting for locks, run three nested loops:

To find the request status for a host and transaction, run two nested loops:

Which tactic is preferable?

In general, trace events cause MarkLogic to incur the overhead of logging additional information, which may slow things down when turned on for extended periods or when trace events are especially verbose (as in the case of "Lock Trace"). The problem of verbose trace events is particularly acute in busy systems, where a large number of operations are in-flight at the same time, making it difficult to spot meaningful locking patterns. Consequently, tactic 2's use of built-in functions is much preferred, if you're working with MarkLogic 9 or later.

Related knowledgebase articles

KB - Gathering information to troubleshoot long-running queries

(1 vote(s))
Not helpful

Comments (0)