DBMS Metrics, Query/Transaction Listings, Logs, GC/JVM Evidence, Page Cache, and Operating-System Signals

AtlasMart receives “Neo4j is slow” tickets every afternoon. One engineer proposes a larger heap, another wants more indexes, and a third blames the network. None has yet shown whether the slow requests are running, waiting on locks, faulting pages, blocked in the driver pool, or spending time outside Neo4j. This lesson replaces opinion with an evidence plane: observe the transaction, plan, logs, JVM/memory, host, driver, and result together before changing anything.

Learning outcomes

Reproducible lab baseline

1. Monitoring is a multi-plane model

2. Build a reversible observation fixture

The fixture is isolated from the course’s Customer/Product/Order graph. It creates 120 synthetic customers, 1,200 items, a small set of observed relationships, and one deliberately hot inventory node for later lock tests. The counts are intentionally modest: the goal is reproducibility, not to force a workstation into distress.

CYPHER 25
CREATE CONSTRAINT obs_customer_id IF NOT EXISTS
FOR (c:ObsCustomer) REQUIRE c.obsId IS UNIQUE;
CREATE CONSTRAINT obs_item_id IF NOT EXISTS
FOR (i:ObsItem) REQUIRE i.obsId IS UNIQUE;
CREATE CONSTRAINT obs_inventory_id IF NOT EXISTS
FOR (x:ObsInventory) REQUIRE x.obsId IS UNIQUE;

UNWIND range(1,120) AS n
MERGE (c:ObsCustomer {obsId:'OC-' + toString(n)})
SET c.segment = n % 12,
    c.region = CASE n % 4 WHEN 0 THEN 'west' WHEN 1 THEN 'east' WHEN 2 THEN 'north' ELSE 'south' END;

UNWIND range(1,1200) AS n
MERGE (i:ObsItem {obsId:'OI-' + toString(n)})
SET i.segment = n % 12,
    i.price = 10.0 + (n % 100),
    i.active = n % 10 <> 0;

MATCH (c:ObsCustomer), (i:ObsItem)
WHERE toInteger(substring(c.obsId,3)) % 40 = 0
  AND toInteger(substring(i.obsId,3)) % 120 = 0
MERGE (c)-[:OBS_VIEWED]->(i);

MERGE (x:ObsInventory {obsId:'INV-HOT-18'})
SET x.available = 1000, x.reserved = 0, x.version = 0;

3. Read active transactions before guessing

SHOW TRANSACTIONS replaces the old “list queries” mental model because a query executes inside a transaction. Current output can expose current query text/status, elapsed and lock-wait time, lock counts and blocker metadata, estimated heap/direct memory, page hits/faults, runtime, indexes, and status details. Some values can be null when unavailable; CPU tracking in particular has edition/configuration requirements.

CYPHER 25
SHOW TRANSACTIONS
YIELD transactionId, username, database, currentQuery, currentQueryStatus,
      elapsedTime, waitTime, currentQueryElapsedTime, currentQueryWaitTime,
      activeLockCount, resourceInformation,
      currentQueryAllocatedBytes, allocatedDirectBytes, estimatedUsedHeapMemory,
      pageHits, pageFaults, currentQueryPageHits, currentQueryPageFaults,
      indexes, runtime, statusDetails
RETURN *
ORDER BY currentQueryElapsedTime DESC;

4. Inspect configuration, not folklore

Before saying “heap is 8 GB” or “page cache is automatic,” ask the server. SHOW SETTINGS reports current, startup and default values on the executing self-managed server. It is not available on Aura, and dynamic changes are an Enterprise capability even though settings can be listed for inspection.

CYPHER 25
SHOW SETTINGS
YIELD name, value, isDynamic, isExplicitlySet
WHERE name IN [
  'server.memory.heap.initial_size',
  'server.memory.heap.max_size',
  'server.memory.pagecache.size',
  'dbms.memory.transaction.total.max',
  'db.memory.transaction.total.max',
  'db.memory.transaction.max',
  'db.tx_log.rotation.size',
  'db.tx_log.rotation.retention_policy'
]
RETURN name, value, isDynamic, isExplicitlySet
ORDER BY name;

5. Logs answer different questions

6. JVM/GC and operating-system evidence

GC pauses only explain latency if their timestamps align with the slow window. Likewise, high CPU is useful only when paired with workload and queueing evidence. Start with a cross-platform Docker snapshot and the server’s own memory recommendation, then add host-native counters when Neo4j runs directly.

# Portable container-level snapshot (Docker Desktop / Linux / macOS):
docker stats --no-stream atlasmart-neo4j

# Neo4j store/index sizing guidance from inside the official image:
docker exec atlasmart-neo4j neo4j-admin server memory-recommendation

# Linux host examples when Neo4j runs directly (not Docker Desktop VM):
# ps -o pid,%cpu,%mem,rss,vsz,etime -p <neo4j_pid>
# ls /proc/<neo4j_pid>/fd | wc -l
# iostat -xz 1
# ss -s

# Windows host examples for a directly running Neo4j process:
# Get-Process neo4j | Select-Object Id,CPU,WorkingSet64,PrivateMemorySize64,HandleCount
# Get-Counter '\\PhysicalDisk(*)\\Avg. Disk sec/Read','\\Network Interface(*)\\Bytes Total/sec'

7. Page cache is not “Neo4j memory” as a whole

Page cache caches graph-store pages and native indexes; heap holds Java objects and much query/transaction state; native memory includes direct buffers and other off-heap structures. A cold page cache after startup naturally produces more faults and disk reads until the active working set warms. That is not a reason to clear caches in production to make a benchmark “fair.”

8. Baseline worksheet

Production judgment

Summary and next step

You now have the evidence map. Lesson 2 separates the memory and host-resource planes precisely so AtlasMart stops treating every memory symptom as a heap-sizing problem.

Authoritative references

• Current Neo4j versions — Current Neo4j 2026.07.1 and 5.26.30 LTS release snapshot.
• Monitoring overview — Current monitoring surfaces: logs, metrics, query/transaction management, connections, jobs, and reports.
• Metrics — Enterprise metrics architecture and supported export surfaces.
• Essential metrics — Server, Neo4j, cluster, and workload signals that require correlation rather than single-metric tuning.
• Metrics reference — Current page-cache, JVM, CPU, file-descriptor, transaction and store metric names.
• Logging — Current neo4j/debug/http/gc/query/security log behavior and edition boundaries.
• Show and terminate transactions — Current SHOW TRANSACTIONS fields for locks, wait time, memory, page hits/faults, runtime, indexes, and status.
• Manage queries — Current query visibility through transaction management rather than legacy dbms.listQueries().
• Memory configuration — Heap, page cache, native memory, transaction limits, and memory-recommendation guidance.
• Disks, RAM and other tips — Page-cache warmup, disk behavior, and operating-system considerations.
• Performance — Performance topics spanning memory, disks, statistics, execution plans, Bolt threads, and filesystem tuning.
• Show configuration settings — Current SHOW SETTINGS syntax and self-managed server scope.
• Transaction logs — Transaction-log location, rotation, retention, pruning, and capacity implications.
• Query tuning and PROFILE — Execution-plan evidence for rows, database hits, memory, access paths, and operator shape.
• Python driver performance — Driver-side timing, database selection, result consumption, and application/database boundary considerations.