Here are listed some procedures to extract information of a running Nuxeo instance. These information can be requested by the support team. Please always compress files before uploading them to your JIRA ticket.
To dump your server configuration and status run
./bin/nuxeoctl showconf ./bin/nuxeoctl status
You can use GUI tools like Java Mission Control or VisualVM to introspect these metrics, but if you want to dump all of them to report a problem you can use jmxterm (using the same JVM and user as your Nuxeo):
# download jmxterm wget http://sourceforge.net/projects/cyclops-group/files/jmxterm/1.0-alpha-4/jmxterm-1.0-alpha-4-uber.jar/download -O /tmp/jmxterm-1.0-alpha-4-uber.jar # list metrics beans and create a script echo -e "domain metrics\nbeans" | java -jar /tmp/jmxterm-1.0-alpha-4-uber.jar -l localhost:1089 -n | sed -e "s,^,get -b ,g" -e "s,$, \*,g" > /tmp/metrics-script.txt # get metrics info (date +'%Y-%m-%d %H:%M:%S:%3N'; java -jar /tmp/jmxterm-1.0-alpha-4-uber.jar -l localhost:1089 -n -i /tmp/metrics-script.txt) > /tmp/metrics.txt 2>&1
And attach the
metrics.txt file to your JIRA ticket.
The garbage collector attempts to reclaim memory used by objects that are no longer in use by the application.
The garbage collector is monitored by default since Nuxeo 6.0, the log file is located here:
In case of problem think to save this file before restarting because the file is overridden on start. If you see many full GC in the file try to run a JVM heap histo.
To see what objects are present in the heap
jcmd Bootstrap GC.class_histogram > /tmp/heap-histo.txt
A thread dump is useful to understand what code is running at time t. It is always better to create 2 or 3 thread dumps with few seconds of pause between them. It makes possible to pinpoint stuck code, you should also take capture of the thread activity.
The first step is to log in as same user as the Nuxeo JVM then use either
jcmd Bootstrap Thread.print > /tmp/nuxeo.tdump
- Get the PID of the Nuxeo JVM, running command and look at a Bootstrap process id.
jstack <PID> > /tmp/nuxeo.tdump
If you have errors try again with the force option:
jstack -F <PID>.
It is also interesting to correlate the code path given by a thread dump with the CPU activity:
top -bcH -n1 -w512 > /tmp/top-thread.txt
If you use the Oracle JVM you can activate this option in the
JAVA_OPTS=$JAVA_OPTS -Dcom.sun.management.jmxremote.autodiscovery=true -Dcom.sun.management.jdp.name=Nuxeo -XX:+UnlockCommercialFeatures -XX:+FlightRecorder
Then to record JVM activity for 1 minute use the following command:
jcmd Bootstrap JFR.start duration=60s filename=/tmp/record-01.jfr
When the JVM is stuck, in addition to thread dump and before restarting, a core dump can give more context information,
If you have
gdb installed, you can generate a core dump without killing the application:
sudo gdb --pid=<PID> --batch -ex generate-core-file -ex detach
If the problem is related to Elasticsearch access (initialization or bad health status), please list:
- the non default
- the non default Elasticsearch configuration options (especially the discovery)
And report the output of the following commands, assuming that Elasticsearch is on localhost and that the HTTP protocol is open on port 9200:
curl "localhost:9200" curl "localhost:9200/_cat/health?v" curl "localhost:9200/_cat/nodes?v" curl "localhost:9200/_cat/indices?v"
In addition If the problem is related to unexpected search results or errors, follow this procedure: Reporting Settings and Mapping
Measure the round trip between Nuxeo and the database:
ping -s 8192 <database IP>
Use mtr to discover what is between the Nuxeo server and the database, report any firewall or known hardware.
Look at the number of errors reported by
netstat -s , as a large number of errors may indicate a network problem.
A network capture can be helpful at some point:
# Capture all eth0 traffic sudo tcpdump -i eth0 -w /tmp/out.tcpdump # Capture http traffic to port localhost:8080 sudo tcpdump -i lo -A host localhost and tcp port 8080 -w /tmp/out.tcpdump
You can report a Linux configuration using the aspersa summary script:
wget http://aspersa.googlecode.com/svn/trunk/summary && bash summary
To monitor the system the sysstat utilities are a collection of performance monitoring tools for Linux that is easy to setup.
You can monitor the system activity like this:
sar -d -o /tmp/sysstat-sar.log 5 720 >/dev/null 2>&1 &
This will monitor the activity every 5s during 1h.
Very useful also is to have a process monitoring, this can be done with atop running as root:
atop -w /tmp/atop.log 5 720 >/dev/null 2>&1 &
If you think you've found a security issue, please report it privately to [email protected].