Neo4j Wiki から
 Monitoring via JMX
 Using JConsole
For easy monitoring, you can connect to a running Neo4j instance via JConsole. To connect, just start it with
and connect to the Neo4j server:
 Enabling the JMX agent
If the Neo4j JMX attributes don't show up in JConsole, you may need to enable the JMX agent manually.
In short, you can do this by adding the
-Dcom.sun.management.jmxremote system property when starting
your application or the Neo4j REST server etc. When using the standalone Neo4j rest server, the property
can be set in the
conf/wrapper.conf file. This is how the setting looks in that case:
For further information, see: Enabling the JMX Agent
 JMX Attributes
The most important attributes are listed below, for a full list, refer to our JMX Reference.
 Node and Relationship cache size
By looking into these values, you can get hints for if heap size is good enough. When using the soft reference based LRU cache (default) low node and relationship count in caches (during load) means that the application running on top of Neo4j is consuming too much memory and the heap size should be increased.
 Number of adverted deadlocks
This value can be monitored to see if there are problem with concurrent transaction competing to update the same resources. If you have a high number of deadlocks and can see that the value is increasing during load it would be a good idea to make use of an event driven messaging system somewhere in your application (let single threads with one transaction batch up work to isolated work on specific parts of the graph). This can also indicate that the graph layout needs to change on certain "hot spot" nodes or relationships (think "parent nodes" that gets updated in every transaction run - this can be replaced using lock-striping techniques letting a node distribute the child work by adding one more layer of parent/childs).
To see the information in JConsole, double click like this:
Attributes of a memory pool:
Each store has a PersistenceWindowPool and monitoring that information runtime can reveal misconfiguration problems and general health/speed of the system. The parameters include (for each store file):
- the name of the pool/store file
- the amount of memory available for the specific store file
- how much memory is actually in use
- the size of each window in the pool
- cache hit count (increases for every time we do not have to go down to disk but can read from memory)
- cache miss count (every time we have to read from disk)
- out of memory count (if more memory have been assigned in memory mapped mode than the machine has this value will increase)
Per session monitoring of:
- opened transactions
- committed transactions
- rolledback transactions
- peak number of concurrent transactions
By monitoring the number of concurrent open transactions and peak concurrent transactions you can compare this to the number of for example the current number of web requests you may reveal some interesting information regarding your application.
 Primitive count
ObjectName: org.neo4j:instance=kernel#0,name=Primitive count
These values can be used to get an estimated number of how many nodes, relationships, relationship types and properties that exists in the store.